ICANN Logo

.NET Application Form


RFP Part 1: General Applicant Information

1. Name and Address fields

The full legal name, principal address, telephone and fax numbers, and e-mail address of the applicant, and the URL of its principal World Wide Web site. Additionally, each applicant must provide the Application Deposit Receipt Number issued to the applicant upon ICANN's receipt of the wired funds for the application deposit.

Organization Name:
Sentan Registry Services, Inc., 
Address:
C/O JPRS
Chiyoda First Building
East 13F, 3-8-1 Nishi-Kanda Chiyoda-Ku
Tokyo, Japan 101-0065
Telephone:
TBD
Fax:
TBD
Email:
inquiries@sentanregistry.net
Confirm Email:
inquiries@sentanregistry.net
URL:
www.sentanregistry.net
Application Deposit Receipt Number:
[RESPONSE IS CONFIDENTIAL]
   

2. Applicant's Business and Other Associated Activities

Provide a general description of the applicant's business and other activities currently or expected to be associated with the services described in this RFP.

SENTAN REGISTRY SERVICES, INC  
 "Sentan" means "advanced" or "leading edge" in Japanese. Sentan Registry 
Services (Sentan) will be the world's most advanced registry by providing truly 
global support and responsibly introducing technology that enhances the 
stability and security of .NET while complying with, and accelerating adoption 
of all ICANN policies and processes.

Sentan, which will be focused on operating the .NET gTLD, is a private, for-
profit joint venture of NeuLevel, Inc. (70% ownership) and Japan Registry 
Services Co., Ltd. (30% ownership), two of the world's leading registry 
services providers. Sentan is incorporated in the United States (Delaware) and 
will be headquartered in Tokyo, Japan. 

Sentan will have overall responsibility for .NET and all front office functions 
including marketing, registrar support, policy, finance, administration, and 
management of subcontractors. To ensure the timely transition of .NET, as well 
as ongoing security and stability, Sentan will subcontract all technical 
registry services and responsibility for the transition to NeuLevel. Sentan 
will also subcontract with NeuLevel for registrar relations and customer 
support in the Americas. JPRS will provide infrastructure in Japan to support 
geographic diversity and disaster recovery capability under a subcontract with 
Sentan. JPRS will also provide technology research and development in new and 
emerging technologies such as Internationalized Domain Names (IDN), IPv6, and 
DNSSEC. 

Sentan's staff will draw experienced registry professionals for key positions 
from JPRS and NeuLevel, as well as new hires. Although the transition is 
completely addressed with existing resources, recruiting firms have already 
been engaged in Tokyo and Rome and have initiated searches to fill the open 
front office positions. Sentan has been incorporated, elected its own Board of 
Directors, appointed its officers including the CEO, and has been fully funded 
by its parent companies.  (Details in Part 2:4)

THE PARTNERSHIP - Although JPRS and NeuLevel are each individually qualified to 
operate the .NET registry, the two companies recognized that their 
complementary capabilities, when combined, would create an ideal solution for 
meeting and exceeding the ICANN criteria for .NET.  Following are some of the 
powerful reasons why such a partnership is the ideal solution for .NET. 

· Over 80% of .NET hosts (.NET machines connected to the Internet) are located 
in Japan (21%) and the United States (60%).

· NeuLevel's registry infrastructure, combined with JPRS ability to provide a 
third SRS disaster recovery site in Japan provides a significant improvement in 
the geographic diversity and stability of .NET.

· NeuLevel and JPRS' complimentary geographic perspectives and ability to 
communicate ICANN policy on a more global basis brings internationalization and 
improved policy compliance to .NET. 

· JPRS is a world-class expert in the development, deployment, and operational 
aspects of IDNs, an area of considerable importance to non-English-speaking 
users of the Internet.

· JPRS' extensive research and development expertise in DNSSEC and IPv6 
complements NeuLevel's ability to successfully implement new technologies in an 
operational environment. 

· A JPRS and NeuLevel partnership enhances global competition through 
substantive equity and operational diversity by a registry that does not 
currently operate in the gTLD market.

· Backing from two experienced, fully capable, and financially strong 
registries enables an ideal business continuity solution.

Both NeuLevel and JPRS realized an organization focused on .NET with the proven 
registry infrastructure of NeuLevel, geographic diversity, and global 
perspective of its parent companies would best meet and exceed the needs 
of .NET. Hence, we formed "Sentan Registry Services, Inc." 

COMMITTED TO POLICY COMPLIANCE - Sentan draws upon its parent companies' ICANN 
policy experience, history of compliance and involvement, and inputs from 
different regions of the world to bring a more global perspective to .NET. 
Sentan will not only comply with and accelerate adoption of all ICANN policies; 
it will actively participate in the development of these policies and 
processes. Sentan's staff includes a dedicated Vice President for Policy and 
Compliance who will participate in ICANN policy process and ensure compliance 
with ICANN policies. 

ENSURING EQUIVALENT REGISTRAR ACCESS - The ideal .NET registry provider should 
be completely impartial in its dealings with registrars and should seek to 
avoid even the appearance of favoritism. Importantly, and unlike many gTLD 
registry operators, Sentan can state unequivocally that it is not controlled 
by, nor does it have any ownership in, any current or prospective .NET TLD 
registrar. Sentan is fully committed to providing equivalent access to 
registrars. 

Like its parents, Sentan will operate under a stringent code of conduct to 
ensure that all ICANN-accredited registrars have equivalent access to registry 
services.  Sentan will take the extra step of submitting to an annual 
compliance audit by a mutually agreed third-party auditor, at Sentan's expense 
to ensure strict adherence with the proposed code of conduct. 

WORLD CLASS REGISTRY SERVICES - The .NET registry, DNS, and associated systems 
are mission-critical Internet infrastructure. With this in mind, Sentan 
leverages the highly scalable, stable and secure infrastructure and geographic 
diversity of its parents to deliver a world-class registry for .NET including 
the following:

· Primary and secondary SRS sites, each fully redundant and geographically 
diverse, with a third disaster recovery SRS site in Tokyo, Japan.

· 24 geographically diverse DNS sites using both Anycast and Unicast routing 
including 4 hot standby ("dark") sites ready to be activated in minutes.

· Three geographically diverse WHOIS sites with proposed service enhancements. 

· Dynamic update capability to propagate DNS and WHOIS changes within 10 
minutes.

· An IDN solution that is fully compliant with all IETF standards and ICANN 
policies and processes.

· SRS support for both RRP and EPP to ease registrar transition to an EPP thick 
registry model.

· Experienced operations and engineering personnel with a proven track record 
developing, implementing, operating, and transitioning gTLD registry services.

The robust and highly scalable registry architecture described in our proposal 
enables Sentan to significantly exceed the availability and performance service 
levels in the current .NET Agreement. Importantly, Sentan's technical registry 
operator owns and operates its own DNS constellation, providing diversity from 
the .COM and .ORG DNS, thus improving overall Internet stability and security. 

The joint venture will enable Sentan to leverage the combined global reach and 
experience of its parents to establish 3 multilingual Regional Support Centers. 
Sentan will provide 24/7/365 support from regional support offices in: Tokyo, 
Japan; Sterling, Virginia, U.S.A.; and Rome, Italy. Customer support 
representatives will initially support nine primary languages and over 100 
additional languages through our translation services partner. Some registrar 
reference materials will also be provided in 12 languages. In Phase I, we will 
provide these registrar reference materials in English, Chinese (simplified and 
traditional), French, Spanish, Japanese, Korean, German, and Italian.  In Phase 
II, we will also offer some registrar reference materials in Arabic, 
Portuguese, and Russian. 

TECHNICAL LEADERSHIP - Sentan will make .NET the world's most advanced domain 
name registry by responsibly introducing technology that enhances the stability 
and security of .NET while complying with all ICANN policies and processes. To 
meet this objective, Sentan combines the capability of 2 of the world's leading 
registry technology innovators.  In addition to the ongoing research and 
development conducted by its parent companies, Sentan will contract with JPRS 
to conduct R&D activities focused on areas of critical importance to 
registries, registrars, and Internet users.  A number of candidate projects 
have already been identified including: IDN, DNSSEC, DDoS, and DNS health. 

PROACTIVE TRANSITION AND MIGRATION PLAN - Sentan's technical registry operator, 
NeuLevel, has already begun transition related activities in advance of the 
selection to ensure .NET is transitioned on schedule in June 2005.  For 
example, NeuLevel has already developed and launched an RRP test environment. 
NeuLevel already has operating relationships with registrars representing 98% 
of the current .NET registrations, and has already launched a program to 
proactively reach out to the remaining 2% in advance of the ICANN selection.  
With a highly reliable and secure registry infrastructure in place, and over 
500 highly qualified personnel to draw upon, Sentan is the ideal choice to 
ensure a secure, stable, and on schedule transition of .NET in June 2005. 

FINANCIAL STRENGTH - Sentan has access to more than adequate financing and a 
solid business plan based on conservative assumptions. This is especially true 
given Sentan has the full backing of its parent companies who have made, and 
will continue to make, the necessary capital investments required for the 
registry infrastructure. Although the current funding is more than adequate, as 
detailed in this proposal, Sentan has access to additional financial resources 
required to fulfill its obligations under the ICANN agreement. Sentan's 
proposed pricing strikes the right balance between reduction in the 
current .NET pricing and responsible funding of registry operations. 

SUBCONTRACTORS

NEULEVEL, INC.

Full Legal Name:	NeuLevel, Inc.
Principal Address: 	46000 Center Oak Plaza, Sterling, Virginia 20166 USA
Telephone number:	+1-571-434-5400
Facsimile number: 	+1-571-434-5786
Email address: 	        jeff.neuman@neulevel.biz
URL:			www.neulevel.biz

Sentan will subcontract global registry operations, transition support, 
research and development and registrar support in the Americas region to 
NeuLevel, including the following:

· SRS Services including primary, back-up, and disaster-recovery location and 
IPv6 support;

· DNS services with dynamic update and IPv6 support;

· WHOIS including an IRIS option;

· Support for ICANN-compliant IDN;

· Wholesale billing;

· Website development and hosting;

· Reporting;

· Americas registrar relations and customer support; and

· Transition support services including RRP and EPP testing environments.

Transition support services include all of the technical, operations and 
registrar support required to complete the timely transition of .NET to Sentan.

COMPANY OVERVIEW - NeuLevel Inc. is the registry operator for the .BIZ gTLD and 
is the exclusive international registry gateway for the .CN and .TW TLDs. 
NeuLevel is a joint venture between NeuStar, Inc. (90% ownership) and Melbourne 
IT, Ltd. (10% ownership). 

. BIZ gTLD REGISTRY- NeuLevel has operated the registry for .BIZ since 2001. It 
was selected by ICANN from among 40 respondents during a worldwide, competitive 
procurement for new generic TLDs. Since launching .BIZ in 2001, NeuLevel has 
grown the number of .BIZ registrations to over 1 million domain names, 
including German language IDNs. .BIZ is truly a global name space with 50% 
of .BIZ names registered outside the United States and registrants in 212 
countries.

. CN and .TW REGISTRY GATEWAYS - Registry Gateway services enable country ccTLD 
registries to rapidly extend their reach to registrars worldwide by leveraging 
NeuLevel's network of registrar connectivity and support. With this Registry 
Gateway service, NeuLevel receives registrations from registrars and provides 
comprehensive support and wholesale billing.  

In 2002, after evaluating all gTLD registries, China Internet Network 
Information Center (CNNIC), the country code registry for .CN domain names, 
entered into an exclusive strategic arrangement with NeuLevel. In 2003, Taiwan 
Network Information Center (TWNIC) selected NeuLevel in a competitive 
procurement and also entered into an exclusive partnership with NeuLevel to 
launch .TW to registrars worldwide.  CNNIC and NeuLevel officially launched 
Chinese-language .CN domain names via the Registry Gateway in January 2005.  
NeuLevel and TWNIC will launch .TW Chinese language worldwide in March 2005. 

NeuLevel is 90% owned by NeuStar, Inc.. NeuStar is the world's leading neutral 
third-party provider of mission-critical interoperability clearinghouse and 
directory services to the telecommunications and Internet industries 
worldwide.  NeuStar was founded as a business unit within Lockheed Martin IMS 
and became a private company in 1999.

Over 150 domain name registrars and every telecommunications service provider 
in North America currently rely upon NeuStar Addressing, Interoperability, and 
Infrastructure services. The following highlights a few of the many essential 
services provided by NeuStar.

.US REGISTRY ADMINISTRATOR - In 2002, NeuStar was selected by the United States 
Department of Commerce to administer the .US ccTLD. NeuStar's solution was 
chosen from a field of competitors to transition .US from VeriSign and to 
enhance and improve upon the services being provided by the incumbent.  

Since the transition NeuStar has introduced second-level registrations and has 
grown the number of .US registrations from less than 17,000 in 2003 to over 
900,000 today. The introduction of second-level names included a live "land 
rush" process in which NeuStar processed over 90,000 registrations in the first 
6 hours of operation. 

IP TRAFFIC EXCHANGE - In 2003, NeuStar introduced a routing service to enable 
Internet Protocol services providers to exchange traffic. The service is DNS-
based and utilizes the ENUM protocol standard, which NeuStar played a major 
role in developing (co-chairing the IETF working group). Today, NeuStar IP 
Traffic Exchange is utilized by mobile carriers, including two of the largest 
mobile operators in the U.S., to route inter-carrier mobile messages.   

NORTH AMERICAN NUMBER PORTABILITY (NPAC) - NeuStar developed and operates the 
routing registry for North America that allows customers to keep their existing 
phone numbers when changing telecommunications service providers. As the 
industry designated NPAC, NeuStar coordinates the porting of local telephone 
numbers between carriers in North America. The industry's recent renewal of 
NeuStar's contract through 2011 is testimony to NeuStar's quality of service 
and responsiveness. 

NUMBER ADMINISTRATION - NeuStar also administers and operates the telephone 
numbering registry for the North American Numbering Plan, serving 
telecommunications service providers throughout the United States, Canada, 
Bermuda, and the Caribbean Islands. NeuStar's contract for this service was 
recently renewed through 2008.

JAPAN REGISTRY SERVICES CO., LTD. (JPRS)

Full Legal Name:	Japan Registry Services Co., Ltd. (JPRS)
Principal Address:      Chiyoda First Building, 
                        East 13F 3-8-1 Nishi-Kanda              
                        Chiyoda-Ku, Tokyo, Japan 101-0065
Telephone number:       +81-3-5215-8451
Facsimile number: 	+81-3-5215-8452
Email Address: 	        hotta@jprs.co.jp
URL: 			http://jprs.co.jp/(Japanese); 
                        http://jprs.jp/en (English)

Sentan will subcontract the following services to JPRS:

· Disaster recovery SRS data center facility;
· DNS sites in Japan;
· WHOIS site(s) in Japan; and
· Research & Development.

JPRS was incorporated as a private company on December 26, 2000, to carry 
out .JP ccTLD domain name registration and management, and to undertake 
operation of the .JP ccTLD domain name system (DNS). JPRS commenced its 
business operations in February 2001 and successfully completed the phased 
transition of management and administration responsibility for .JP ccTLD from 
Japan Network Information Center (JPNIC) by April 2002. The service was 
officially authorized by the ccTLD Sponsorship Agreement executed between JPRS 
and ICANN on February 28, 2002 and now supports over 600 registrars with over 
600,000 .JP names under management.  The primary mission of JPRS as the 
registry for the .JP ccTLD domain is to provide registry services that 
contribute to society by continuously improving the value of the .JP ccTLD. 

JPRS has a track record of technology leadership in areas of critical 
importance to the Internet community and relevance to .NET including:
· IDN;
· Anycast;
· IPv6; and
· DNSSEC.

IDN - In May 2001, JPRS started a test bed service of DNS resolution using 
registered Japanese .JP domain names, after active involvement in IDN 
standardization activities in IETF. To ensure the usability of Japanese domain 
names, JPRS launched a new service for enabling the use of Japanese domain 
names in August 2001. JPRS actively participated in and contributed to the 
standardization and introduction of IDN technology and usage through its 
involvement in related activities of the IETF (including contributions to 
the "Internet-Draft" regarding IDN), the Japanese Domain Names Association 
(JDNA), and Joint Engineering Team (JET). In July 2003, JPRS introduced the 
registration and DNS resolution of IETF RFC-compliant Japanese domain names, 
following the ICANN Guidelines for Implementation of IDNs. 

ANYCAST - In February 2004, JPRS became one of the first ccTLD registries in 
the world to adopt Anycast routing technology. Anycast improved .JP DNS 
stability, enhanced JPRS' ability to support higher loads, and improved 
survivability.  

IPv6 - JPRS began accepting DNS queries of IPv6 transport for .JP DNS name 
servers in July 2004. It worked with other registries and IANA to make IPv6 
applicable to address (AAAA) records in root zone from both logical and 
experimental aspects. ICANN recognized JPRS' achievements in its 2004 Kuala 
Lumpur meeting.

DNS SECURITY EXTENSIONS (DNSSEC) - The introduction of DNSSEC has the potential 
to enhance the security of the DNS and the Internet as a whole. JPRS has been 
involved in efforts to facilitate the deployment of DNSSEC. For example, JPRS 
is a member of the DNSSEC Deployment Working Group. In 2004, JPRS completed a 3-
year, US$1M, government-funded, DNSSE research and development project.

JPRS has a history of ICANN support and responsible compliance with ICANN 
policies and procedures. In February 2002, JPRS became one of the first ccTLD 
registries to sign the "ccTLD Sponsorship Agreement" with ICANN and continues 
to actively participate in ICANN related activities.

3. Directors, Officers and other Key Staff

Provide the full names, positions and the qualification and experience of each of the following persons:

(i) the person or persons who will have direct responsibility for the business operations of the registry,
Richard J. Tindal 
As Chief Executive Officer, Mr. Tindal will be responsible for the overall 
executive management of the Sentan registry. He has over 15 years of commercial 
and government experience with independent international channel management, 
business development, marketing, and sales, including 7 years in the registrar-
registry business.

In his current role as Vice President, Registry Services at NeuLevel, Mr. 
Tindal is responsible for establishing strong technical, operational, 
contractual, and billing relationships with accredited registrars to promote, 
sell, and support .BIZ, .US, .CN, and .TW domain names.
(ii) each person in the chain of command with decision making authority from that person or persons to the principal executive officer of the applicant,
Richard K. Wilhelm

As CTO / COO of Sentan, Mr. Wilhelm, will be responsible for the overall 
operations and technology of the Sentan registry.  In this capacity, he will 
direct the NeuLevel and JPRS team that provides technology operations 
services.  In addition, Mr. Wilhelm also has lead responsibility for the 
transition of .NET.  As Vice President, Software Engineering of NeuLevel, he 
was a principal architect of the NeuLevel/NeuStar registry services platform 
during its construction for the .BIZ gTLD, directed its enhancement and 
deployment for the .US ccTLD transition, and has managed its ongoing technical 
operations.  

Wilhelm's background includes over 15 years of positions of increasing 
responsibility in technology consulting, private equity, and software 
development.  During his tenure at Accenture (then Andersen Consulting), he was 
an active participant in the ANSI X3J16 committee for C++ standardization.

Atsushi Endo

Mr. Endo will assume the role of Vice President, Policy and Compliance Officer 
for Sentan.  Mr. Endo has been with JPRS for 4 years.  His primary 
responsibilities at JPRS include corporate planning, external affairs, and 
public relations of JPRS.  Mr. Endo has also been involved in "Internet Next 
Generation" activity in Asia Pacific Region including his role of vice-chair of 
5th Asia Pacific Next Generation Camp, which was hosted by Asia Pacific 
Networking Group (APNG). He is co-founder of JPING (Japan Internet Next 
Generation).   

Ivor Sequeira

Mr. Sequeira will assume the role of Vice President, Registrar Support for 
Sentan.  At NeuLevel he is responsible for registrar relations and customer 
support on a worldwide basis.  He is currently responsible for building and 
maintaining strategic channel relationships with existing and new registrars 
across North America, Europe, Africa and the Middle East. He also designs and 
oversees all channel marketing and sales programs for global registrar 
partners, and seeks out new products and services that leverage current channel 
relationships and add value to the company's registry offerings.

Keith Drazek

Mr. Drazek will assume the role of Regional Director, Europe/Middle East/Africa 
for Sentan.  He has worked at NeuLevel as a member of the Registry Relations 
Team, and is proficient in customer relationship management, having worked as a 
sales manager at a leading registrar prior to joining NeuLevel.  He was 
instrumental in the .BIZ gTLD launch and has significant experience working in 
the domain name business, including participation in numerous ICANN meetings. 

Shinta Sato

In his role as Director R&D, Stability, and Security Projects, Mr. Sato will 
support projects associated with stability and security advances, including 
support for the initial transition of .NET under a JPRS research and 
development subcontract with Sentan. He was an employee of JPNIC from 1999 to 
2001.  There he was responsible for DNS and Registry Systems and continues in 
this role at JPRS.   He was a team member of implementation of IPv6 and Anycast 
technologies to JP DNS.  

Yoshiro Yoneya

In his role as Director of R&D, Internationalized Domain Names, Mr. Yoneya will 
support IDN-related projects under a JPRS research and development subcontract 
with Sentan.  Mr. Yoneya joined JPNIC's IDN Task Force in 1999, and was chair 
of the TF from 2000 to 2002.  He led JPNIC's opensource IDN toolkit (aka 
idnkit) development team and made contributions to IETF IDN WG.  He was also a 
core member of Joint Engineering Team (JET) and deeply involved in development 
of the JET IDN registration guideline.
 
(iii) the top two financial officers of the applicant,
Jeffrey Babka

As the Treasurer for Sentan, Mr. Babka is responsible for overseeing all 
financial aspects of the company.  As the Chief Financial Officer, his current 
responsibilities at NeuStar include financial planning, reporting and analysis, 
accounting/financial systems and processes, taxation, investor relations, 
fiduciary controls, business development/acquisition analysis, and 
facilities/purchasing.  Mr. Babka's 30-year career includes a wide variety of 
financial and operational management and executive positions with a 
concentration in telecommunications, including a long tenure at AT&T, Lucent 
Technologies, and Concert. He joined NeuStar in April 2004.

Brian Robins

In addition to acting as the Deputy Treasurer of Sentan, Mr. Robins leads 
Financial Planning & Analysis and Treasury teams in his role as NeuLevel and 
NeuStar's Treasurer and Vice President of Finance and has a primary focus on 
financial operations, cash management, process improvement, negotiations and 
fundraising. He is experienced with the structuring, legal review and schedule 
preparation for debt/equity transactions, short- and long-term cash management, 
bank/vendor lease financing, the development of annual operating and capital 
budgets, and mergers and acquisitions (M&A) activity.
(iv) the person with the principal technical responsibility for the operation of the registry,
Richard K. Wilhelm - Chief Technical Officer/Chief Operating Officer, Sentan 
Registry Services (see above) 
(v) each other executive or management person of the applicant who will have significant policy making or operational influence regarding the registry operations,
REGISTRY OPERATIONS

Mark Foster

Mr. Foster is the Senior Vice President and Chief Technology Officer of 
NeuStar.  In this role, he is responsible for strategy, advanced services 
research and development, strategic initiatives, and the technology behind 
NeuStar's mission-critical clearinghouse services. Prior to co-foundering 
NeuStar in 1996, Mr. Foster invented local number portability (LNP) in 1994-95, 
which is now used widely in North America and throughout the world. He 
subsequently led the design and implementation of NeuStar's Number Portability 
Administration Center (NPAC) system. He also led strategy and technology for 
NeuStar's numbering administration, Internet registry, convergent OSS 
clearinghouse, IP directory clearinghouse (ENUM), and identity management 
businesses.

Susumu Sano

Mr. Sano is CTO of JPRS, and is responsible for operation of DNS, registry 
system of .JP and other systems. Since the mid-1980's, he has been engaged in 
research and deployment of the Internet. He is a specialist in Internet 
security and DNS operation and security. Prior to joining JPRS, he was a member 
of Internet Systems Research Labs of NEC Corporation. He serves as Trustee of 
JPNIC and Director of JPCERT/CC. He is also a Board Member of Widely Integrated 
Distributed Environment (WIDE) Project. 

Steven J. Cory 

Mr. Cory is responsible for the management and operation of NeuLevel and 
NeuStar's Information Technology infrastructure and services, including network 
operations, systems and database administrations, applications support, network 
and applications monitoring and information security. These mission-critical 
components provide the platform for the company's database, clearinghouse and 
registry services. 

Thomas G. McGarry  

As Vice President of Strategic Technical Initiatives of NeuLevel and NeuStar, 
Mr. McGarry has more than 18 years of experience in network engineering, 
network and technology planning, and telecommunications management, as well as 
significant experience in the Internet and registry-related technology.  He 
represents NeuLevel and NeuStar as Subject Matter Expert (SME) Manager on 
Internet and domain name space initiatives and drives the development of 
industry standards for voice over IP technologies.  He interacts directly with 
regulators around the world regarding numbering policy and provides technical 
support on telecommunications numbering issues.

POLICY/LEGAL

Hirofumi Hotta 

In his role as Director, Japan Registry Services, Co., Ltd., Mr. Hotta is 
responsible for corporate planning and business development of JPRS. He is also 
a Council Member of ICANN ccNSO. Before joining JPRS, he engaged in research 
and development of products and services at NTT. He served as a council member 
of ICANN Domain Name Supporting Organization (DNSO), a member of ICANN IDN 
Registry Implementation Committee and Chair of APIA (Asia & Pacific Internet 
Association). 

Martin K. Lowen 

As Vice President and General Counsel for NeuStar, Mr. Lowen is responsible for 
the oversight of all legal matters, the strategic development of policy and 
business development initiatives. Mr. Lowen is a member of the bar in the 
District of Columbia and New York. He is also Secretary of the Board of 
Directors at NeuStar.

Jeffrey J. Neuman 

In his role as NeuLevel's Director of Law and Policy, Mr. Neuman is responsible 
for the oversight of intellectual property law and policy development matters, 
as well as information technology licensing. He is the current chairperson of 
ICANN's gTLD Registry Constituency, as well as the external liaison with the 
Domain Name Supporting Organization of ICANN, the gTLD Registry Constituency of 
ICANN and the Intellectual Property Constituency.  Further, Mr. Neuman is 
responsible for the protection of intellectual property assets, domain name 
disputes, and Internet-related matters. He is a frequent speaker on issues 
involving intellectual property, domain names, online dispute resolution, and 
the introduction of new generic top-level domain names.
(vi) all directors or persons with equivalent positions for non-corporate entities, and
SENTAN REGISTRY SERVICES, INC. - BOARD OF DIRECTORS

Michael Lach
 
As President and Chief Operating Officer, Mr. Lach is responsible for the day-
to-day management of NeuStar and NeuLevel's operating plan. Over his 20-year 
career, he has held senior executive management positions with major 
telecommunications companies and has been responsible for operations, 
engineering, information technology, business integration, sales, customer 
service, and marketing.


Joseph Franlin

As Senior Vice President of Customer Relations, Mr. Franlin is responsible for 
NeuStar Customer and Industry Relations. He and his staff are industry and 
customer advocates within NeuStar. His organization is responsible for customer 
loyalty and for building lasting relationships founded upon the delivery of 
operational excellence and high-value products and services.  A founder of 
NeuStar, Mr. Franlin has over 30 years of telecommunications experience in 
functional areas including customer service, program management, sales, 
marketing, contract negotiations, business development, and operations.
Jeffrey Babka - Chief Financial Officer NeuStar (See above)
Hirofumi Hotta - Director, Japan Registry Services, Co., Ltd. (See above)

Please note:  A fifth, mutually agreed, Independent Director will be elected to 
the Board.  Sentan's preference is for a qualified Board Member from Europe, 
Africa, Latin America, or the Middle East.

SENTAN REGISTRY SERVICES - CORPORATE OFFICERS
Richard J. Tindal - Chief Executive Officer, Sentan Registry Services (See 
above)

Martin K. Lowen - Secretary (See above)
Jeffrey J. Neuman - Assistant Secretary (see above)
Jeffrey Babka - Treasurer (See above)

NEULEVEL - BOARD OF DIRECTORS

Jeffrey Ganek

As Chairman and Chief Executive Officer, Mr. Ganek is responsible for overall 
executive management for NeuStar.  Mr. Ganek has more than 20 years of 
experience in telecommunications, and has held senior management positions in 
operations, finance, marketing, and business development. He has been with 
NeuStar since its inception as the independent Communications Industry Services 
(CIS) division of Lockheed Martin.

Mike Lach - President and COO, NeuStar (See above)

Jeff Babka - Chief Financial Officer, NeuStar (See above) 

Richard Tindal, CEO, Sentan Registry Services, Inc. (See above)

Andrew Field 

Mr. Field has more than 13 years experience in the finance and IT industries, 
and holds degrees in both Accounting and IT.  He is responsible for the 
effective financial management of Melbourne IT. To this end, he works closely 
with all parts of the business ensuring that the company achieves a better than 
average return from its investments. Prior to Melbourne IT, the majority of Mr. 
Field's career was spent in the financial management of IT companies. 

JAPAN REGISTRY SERVICES CO., LTD. (JPRS) - BOARD OF DIRECTORS

Koki Higashida 

As President, Mr. Higashida is responsible for overall management of JPRS. He 
has over 15 years of experience in the administration of .JP. Before being the 
President of JPRS, he was Associate Professor at Tokyo University of Science. 
He also served as Vice President and Secretary General of Japan Network 
Information Center (JPNIC) when it was the registry of .JP. 

Susumu Sano (See above)

Tetsuo Watanabe 

Mr. Watanabe is a JPRS Director and is responsible for JPRS general affairs.  
Before the establishment of JPRS, he was the Manager of General Affairs of 
JPNIC.  Prior to joining JPNIC, he was in Bank of Tokyo-Mitsubishi, one of the 
major banks in Japan. 
 
Hirofumi Hotta - Director (See above)
(vii) identify any persons or entities who own or will own or otherwise control, directly or indirectly, 5% or more of the outstanding voting power held by all persons or entities entitled to participate in the election (or other selection) of the applicant’s board of directors or other governing body.
SENTAN REGISTRY SERVICES, INC.
NeuLevel, Inc. 
Japan Registry Services Co., Ltd. 

NEULEVEL, INC.
NeuStar, Inc. 
Melbourne IT, Ltd. 

NEUSTAR, INC.
Warburg Pincus LLC
ABS Capital Partners

JAPAN REGISTRY SERVICES, CO., LTD.
Japan Network Information Center (JPNIC)
Koki Higashida
Susumu Sano
Employees Stock Ownership Program
Japan Registry Services Co., Ltd. (Treasury Stock)


The independent evaluators may seek additional information from applicants regarding the qualifications of personnel if deemed necessary.

   

4. Applicant Organization Type

Provide the applicant's type of entity (e.g., corporation, partnership, etc.) and law (e.g., Denmark) under which it is or will be organized. Please state whether the applicant is for-profit or non-profit. If it is non-profit, please provide a detailed statement of its mission. Applicants should be prepared to submit articles of incorporation, or other similar organizational documents later in the evaluation process.

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). 
   

5. Number of Employees

Provide the number of employees currently employed by the applicant or to be employed concurrently with a selection as the successor registry operator.

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

6. Contact Person

Provide the name, telephone and fax number, and e-mail address of person to contact for additional information regarding this application. If there are multiple contacts, please list all their names, telephone and fax numbers, and e-mail addresses and describe the areas as to which each should be contacted.

[RESPONSE IS CONFIDENTIAL]
   

RFP Part 2: Technical and Financial Information

The criteria by which the applicants will be evaluated are set forth below. Each criterion is labeled as either absolute or relative. Diagrams, charts and other similar material may be submitted in response to specific provisions where so indicated in the RFP as posted.

1. ICANN Policy Compliance

Criteria: The successor .NET registry operator must comply with all existing consensus policies of ICANN and must agree to comply with all future consensus policies of ICANN. This is an absolute criterion.

Describe in detail your method for implementing ICANN's Inter-Registrar Transfer Policy.

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.
   

2. Equivalent Access for Registrars

Criteria: All ICANN-accredited registrars must be allowed to qualify to register names in .NET. The registry operator must treat all registrars that have qualified to operate as .NET registrars equivalently. This is an absolute criterion (except as described below regarding languages).

(a) Describe in detail your 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 multiple time zones and multiple languages. Please include in your description the languages that you agree to support if you are selected as the .NET registry operator. Support in English is an absolute criterion. Support in additional languages is a relative criterion. 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 into for other unsponsored TLDs (e.g., .biz, .com, .info, .name, .org and .pro).

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. 

(b) VeriSign, Inc., the current operator of the .NET 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 .NET to another protocol has already been completed by that time). In addition, the selected successor operator will be required to implement support for Version 1.0 of the Extensible Provisioning Protocol as specified in RFC's 3730, 3731, 3732, 3733, 3734, and 3735. Provide a detailed description of your plan for supporting RRP at the time of transition, for supporting EPP 1.0, and for providing registrars with a smooth, low-cost migration path from RRP to EPP.

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.
   

The applicant's response to Part 2, Section 3 will remain confidential to ICANN and the independent evaluators. ICANN will use reasonable efforts to avoid publication or release of this information, but in no circumstance will ICANN's liability for any release of this information exceed the amount of the application fee.

3. Registry Operations

Criteria: The successor .NET registry operator must provide name registration within the time specified in the Appendix D to the existing .NET registry operator agreement. This is an absolute criterion. The ability to provide additional registry services and/or the ability to provide name registration faster than the specifications on Appendix D are relative criteria. An assessment of this ability will include the evaluators’ assessment of the factors described below.

(a) Provide a full description of all registry services you propose to provide and demonstrate your technical and legal ability to provide them, including your prior experience offering these or similar services. If you propose to offer any registry services that you believe are not now offered, include for such services your assessment of the benefits and burdens associated with such new services, as those benefits and burdens apply to registrants and registrars. In addition, describe the technical components and aspects of the planned registry services, and how you will support the same.

[RESPONSE IS CONFIDENTIAL]

(b) To enable the evaluators to assess your capability (both technical and financial) to deliver the registry services you propose to provide, please include the following information:

(i) A detailed description of your current business operations, including (A) core capabilities in registry/database and Internet related operations and (B) the services and products you currently offer, with data on how long you have offered them on the current scale. To the extent this description does not fully capture your ability to provide the registry services you propose to offer, add the appropriate supplementary information to fully describe that ability.

[RESPONSE IS CONFIDENTIAL]
(ii) Whether you currently provide any domain name registration services and describe such services.

[RESPONSE IS CONFIDENTIAL]
(iii) A description (including location) of facilities (including available network capacity) available to house staff and equipment necessary to operate the registry.

[RESPONSE IS CONFIDENTIAL]
   

4. Revenue and Pricing Model; Financial Strength and Stability

Criteria: Each applicant must demonstrate sufficient financial strength and stability, based upon its existing financial condition and its proposed business model for operation of the registry, to provide reasonable certainty that it will be able to fulfill its obligations over the life of the .NET registry agreement. This is an absolute criterion. In building their financial and pricing models, applicants should assume that the following fees will be payable: (i) an annual fee to ICANN of US$132,000 for the first year, increasing by no more than 15% each year thereafter and (ii) registry-level transaction fees totaling non-refundable amounts of US$0.75 for each annual increment of an initial domain name registration and US$0.75 for each annual increment of a domain name re-registration registered by a registrar (in addition to preexisting fee obligations payable annually by registrars to ICANN), to be allocated equally to the following three purposes: (a) a special restricted fund for developing country Internet communities to enable further participation in the ICANN mission by developing country stakeholders, (b) a special restricted fund to enhance and facilitate the security and stability of the global Internet’s system of unique identifiers, and (c) general operating funds to support ICANN's mission to ensure the stable and secure operation of the global Internet's systems of unique identifiers. The per-name price charged to registrars is a relative criterion, with lower committed prices being preferable to higher prices.

All applicants should note that registration fees paid to VeriSign prior to the actual transfer of operational responsibility will not be transferred to a subsequent registry operator.

(a) Provide the following financial statements for the applicant (or, if the applicant is a wholly owed subsidiary of another entity, for the applicant and such other entity on a consolidated basis): three years of financial statements (including balance sheet, income statement, cash flow statement and statement of stockholders’ equity), audited by an independent accounting firm and prepared in accordance with either U.S. generally accepted accounting principles or the International Accounting Standards. Applicants who do not have such audited financial statements may substitute such other information and statements about their operations that are reasonably equivalent to such financial statements. The independent evaluators will be responsible for determining whether such information and statements are sufficiently equivalent to allow the evaluators to conduct an evaluation of the applicant’s financial strength comparable to the evaluation conducted on those applicants who do submit the requested financial statements.

[RESPONSE IS CONFIDENTIAL]

(b) Provide the applicant's business plan for the operation of the registry, including:

(i) a detailed description of all revenue or commercial benefit to be derived from or related to your operation of the registry, including but not limited to details of the expected or anticipated revenue and the assumptions about prices charged for services to be offered, and anticipated demand for those services at high, medium and low levels;

[RESPONSE IS CONFIDENTIAL]
(ii) staffing model, showing the number and types of employees needed at the various levels of demand and the expenses associated with that staff. Include information on (A) applicant’s hiring policy and training programs (for both new and continuing staff), (B) staffing level to handle both expected and unexpected volume levels, and react to unplanned outages, infrastructure vulnerabilities and security breaches and (C) customer service staff to support on a 24 hour basis in multiple languages;

[RESPONSE IS CONFIDENTIAL]
(iii) expense model, incorporating both the staffing expenses described above and all other anticipated expenses of the operating the registry;

[RESPONSE IS CONFIDENTIAL]
(iv) property, plant and equipment budget;

[RESPONSE IS CONFIDENTIAL]
(v) a projection for the sources and uses of cash, showing the applicant's current cash available and the sources of cash available to applicant in the future to fund operating and capital expenditures.
[RESPONSE IS CONFIDENTIAL]
   

5. Technical Competence

Criteria: The .NET registry operator must meet the specifications of the current .NET registry contained in the following sections of the current .NET registry agreement listed below (if a “thick registry” model is being proposed by applicant, the specifications for the current .org agreement, rather than the current .NET agreement, shall apply in the case of Appendices O, P and Q). This is an absolute criterion. The degree to which applicant’s proposal commits applicant to exceed these specifications shall be relative criteria:

Appendix C.4, Name server Functional Specifications

Nameserver operations for the.net Registry shall comply with RFC 1034, 1035, 
2182, 2870, 3258, and 3901.

Appendix C.5, Patch, Update, and Upgrade Policy

The .NET registry may issue periodic patches, updates or upgrades to the 
Software, EPP or APIs ("Licensed Product") licensed under the Registry-
Registrar Agreement (the "Agreement") that will enhance functionality or 
otherwise improve the Shared Registration System under the Agreement. For the 
purposes of this Part 5 of Appendix C, the following terms have the associated 
meanings set forth herein. (1) A "Patch" means minor modifications to the 
Licensed Product made by the .NET registry during the performance of error 
correction services. A Patch does not constitute a Version. (2) An "Update" 
means a new release of the Licensed Product which may contain error 
corrections, minor enhancements, and, in certain circumstances, major 
enhancements, and which is indicated by a change in the digit to right of the 
decimal point in the version number of the Licensed Product. (3) An "Upgrade" 
means a new release of the Licensed Product which involves the addition of 
substantial or substantially enhanced functionality and which is indicated by a 
change in the digit to the left of the decimal point in the version of the 
Licensed Product. (4) A "Version" means the Licensed Product identified by any 
single version number. Each Update and Upgrade causes a change in Version. 
Patches do not require corresponding changes to client applications developed, 
implemented, and maintained by each registrar. Updates may require changes to 
client applications by each registrar in order to take advantage of the new 
features and/or capabilities and continue to have access to the Shared 
Registration System. Upgrades require changes to client applications by each 
registrar in order to take advantage of the new features and/or capabilities 
and continue to have access to the Shared Registration System.

The .NET registry, in its sole discretion, will deploy Patches during scheduled 
and announced Shared Registration System maintenance periods.

For Updates and Upgrades, the .NET registry will give each registrar notice 
prior to deploying the Updates and Upgrades into the production environment. 
The notice shall be at least sixty (60) days, except that if ICANN's registry 
agreements with all other unsponsored TLDs provide that the operators of those 
TLDs will provide at least ninety (90) days' notice, then the .NET registry 
will provide at least ninety (90) days' notice. Such notice (whether 60 or 90 
days) will include an initial thirty (30) days' notice before deploying the 
Update that requires changes to client applications or the Upgrade into the 
Operational Test and Evaluation ("OT&E") environment to which all registrars 
have access. The .NET registry will maintain the Update or Upgrade in the OT&E 
environment for at least thirty (30) days, to allow each registrar the 
opportunity to modify its client applications and complete testing, before 
implementing the new code in the production environment.

Appendix D, Performance Specifications

1. Introduction. The attached (Exhibit D-1) Performance Specification Matrix 
("Matrix") provides a list of performance specifications as they apply to the 
three Core Services provided by the Registry: SRS, Nameserver, and WHOIS 
services.

2. Definition. Capitalized terms used herein and not otherwise defined shall 
have the meaning ascribed to them in the Registry Agreement.

2.1 "Core Internet Service Failure" refers to an extraordinary and identifiable 
event beyond the control of Registry Operator affecting the Internet services 
to be measured pursuant to Section 3.6 of this Appendix D. Such events include 
but are not limited to congestion, collapse, partitioning, power grid failures, 
and routing failures.

2.2 "Core Services" refers to the three core services provided by the Registry -
 SRS, Nameserver, and WHOIS Services.

2.3 "Performance Specification" refers to the specific committed performance 
service levels as specified herein.

2.4 "Performance Specification Priority" refers to the Registry's rating system 
for Performance Specifications. Some Performance Specifications are more 
critical to the operations of the Registry than others. Each of the Performance 
Specifications is rated as C1-mission critical, C2-mission important, C3-
mission beneficial, or C4-mission maintenance.

2.5 "Registrar Community" refers to all of the ICANN-Accredited Registrars who 
have executed Registry-Registrar Agreements with Registry Operator for the 
Registry TLD.

2.6 "SRS" refers to the Shared Registration System; the service that the 
Registry provides to the Registrar community. Specifically, it refers to the 
ability of Registrars to add, modify, and delete information associated with 
domain names, nameserver, contacts, and Registrar profile information. This 
service is provided by systems and software maintained in coactive redundant 
data centers. The service is available to approved Registrars via an Internet 
connection.

2.7 "Nameserver" refers to the nameserver function of the Registry and the 
nameservers that resolve DNS queries from Internet users. This service is 
performed by multiple nameserver sites that host DNS resource records. The 
customers of the nameserver service are users of the Internet. The nameservers 
receive a DNS query, resolve it to the appropriate address, and provide a 
response.

2.8 "Service Level Measurement Period" refers to the period of time for which a 
Performance Specification is measured. Monthly periods are based on calendar 
months, quarterly periods are based on calendar quarters, and annual periods 
are based on calendar years.

2.9 "WHOIS" refers to the Registry's WHOIS service. The Registry will provide 
contact information related to registered domain names and nameserver through a 
WHOIS service. Any person with access to the Internet can query the Registry's 
WHOIS service directly (via the Registry website) or through a Registrar.

3. Performance Specifications. Registry operator shall use commercially 
reasonable efforts to provide Registry Services for the Registry TLD. The 
Performance Specifications defined below establish the basis for the Service 
Level Exception Credits ("SLE Credits") provided for in Appendix E to this 
Registry Agreement. These Performance Specifications also set forth Registry 
Operator's obligations directly to ICANN under Subsection 3.3 of the Registry 
Agreement.

3.1 Service Availability. Service Availability is defined as the time, in 
minutes, that the Registry's Core Services are responding to its users. Service 
is unavailable when a service listed in the Matrix is unavailable to all users, 
that is, when no user can initiate a session with or receive a response from 
the Registry ("Unavailability"). Service Availability is a C1 priority level.

3.1.1 Service Availability is measured as follows:
Service Availability % = {[(TM - POM) - UOM] / (TM - POM)}*100 where:
TM = Total Minutes in the Service Level Measurement Period (#days*24 hours*60 
minutes)

POM = Planned Outage Minutes (sum of (i) Planned Outages and (ii) Extended 
Planned Outages during the Service Level Measurement Period)

UOM = Unplanned Outage Minutes (Difference between the total number of minutes 
of Unavailability during the Service Level Measurement Period minus POM).
Upon written request, and at the sole expense of the requesting Registrar(s), 
Registry Operator will retain an independent third party (to be selected by 
Registry Operator with the consent of the Registrar(s) to perform an 
independent calculation of the UOM). The frequency of this audit will be no 
more than once yearly during the term of the agreement between Registry 
Operator and the Registrar.

This calculation is performed and the results reported for each calendar month 
for SRS and WHOIS availability and for each calendar year for Nameserver 
availability. 

3.1.2 Service Availability--SRS. Service Availability as it applies to the SRS 
refers to the ability of the SRS to respond to Registrars that access and use 
the SRS through the EPP protocol defined in Appendix C. SRS Unavailability will 
be logged with the Registry Operator as Unplanned Outage Minutes. The committed 
Service Availability for SRS is 99.95% and the Service Level Measurement Period 
is monthly.

3.1.3a Service Availability--Nameserver service. Service Availability as it 
applies to the Nameserver refers to the ability of the Nameserver to resolve a 
DNS query from an Internet user. Nameserver Unavailability will be logged with 
the Registry Operator as Unplanned Outage Minutes. The committed Service 
Availability for Nameserver is 100% and the Service Level Measurement Period is 
annually.

3.1.3b Total Nameserver Availability. In addition, no less than 80% of our 
nameserver sites will be available at any given time. For purposes of this 
Appendix, "nameserver site" shall mean distinct locations that host a .NET 
nameserver(s). For example Sterling, VA, USA and Tokyo, Japan are 2 nameserver 
sites.
 
3.1.4 Service Availability--WHOIS = 100%. Service Availability as it applies to 
WHOIS refers to the ability of users to access and use the Registry's WHOIS 
service. WHOIS Unavailability will be logged with the Registry Operator as 
Unplanned Outage Minutes. The committed Service Availability for WHOIS is 100% 
and the Service Level Measurement Period is monthly.

3.2 Planned Outage. High volume data centers like the Registry require downtime 
for regular maintenance. Allowing for regular maintenance ("Planned Outage") 
ensures a high level of service for the Registry. Planned Outage Performance 
Specifications are a C4 priority level.

3.2.1 Planned Outage Duration. The Planned Outage Duration defines the maximum 
allowable time, in hours and minutes, that the Registry Operator is allowed to 
take the Registry Services out of service for regular maintenance. Planned 
Outages are planned in advance and the Registrar community is provided warning 
ahead of time. This Performance Specification, where applicable, has a monthly 
Service Level Measurement Period. The Planned Outage Duration for the Core 
Services is as follows:

(i) Planned Outage Duration - SRS = 8 hours (480 minutes) per month, can be 
split between 2 days;

(ii) Planned Outage Duration - Nameserver = (no planned outages allowed); and

(iii) Planned Outage Duration - WHOIS = (no planned outage allowed).

3.2.2 Planned Outage Timeframe. The Planned Outage Timeframe defines the hours 
and days in which the Planned Outage can occur. The Planned Outage Timeframe 
for the Core Services is as follows:

(i) Planned Outage Timeframe - SRS = 0500-1300 UTC Sunday;

(ii) Planned Outage Timeframe - Nameserver = (no planned outages allowed); and

(iii) Planned Outage Timeframe - WHOIS (no planned outages allowed).

3.2.3 Planned Outage Notification. The Registry Operator must notify all of its 
Registrars of any Planned Outage. The Planned Outage Notification Performance 
Specification defines the number of days prior to a Planned Outage that the 
Registry Operator must notify its Registrars. The Planned Outage Notification 
for the Core Services is as follows:

(i) Planned Outage Notification Timeframe - SRS = 7 days;

(ii) Planned Outage Notification Timeframe - Nameserver = (no planned outages 
allowed); and

(iii) Planned Outage Notification Timeframe - WHOIS (no planned outages 
allowed).

3.3 Extended Planned Outage. In some cases such as software upgrades and 
platform replacements an extended maintenance timeframe is required. Extended 
Planned Outages refers to additional hours that can be added to a monthly 
planned outage. Extended Planned Outages will occur less frequently than 
Planned Outages. Extended Planned Outage Performance Specifications are a C4 
priority level.

3.3.1 Extended Planned Outage Duration. The Extended Planned Outage Duration 
defines the maximum allowable time, in hours and minutes, that the Registry 
Operator is allowed to take the Registry Services out of service for extended 
maintenance. Extended Planned Outages are planned in advance and the Registrar 
community is provided warning ahead of time. Extended Planned Outage periods 
are in addition to any Planned Outages during any Service Level Measurement 
Period. This Performance Specification, where applicable, has a Service Level 
Measurement Period based on a calendar year. The Extended Planned Outage 
Duration for the Core Services is as follows:

(i) Extended Planned Outage Duration - SRS = 8 hours (480 minutes) per calendar 
year;

(ii) Extended Planned Outage Duration - Nameserver = (no planned outages 
allowed); and

(iii) Extended Planned Outage Duration - WHOIS (no planned outages allowed).

3.3.2 Extended Planned Outage Timeframe. The Extended Planned Outage Timeframe 
defines the hours and days in which the Extended Planned Outage can occur. The 
Extended Planned Outage Timeframe for the Core Services is as follows:

(i) Extended Planned Outage Timeframe - SRS = 0100 - 1700 UTC Saturday or 
Sunday;

(ii) Extended Planned Outage Timeframe - Nameserver = (no planned outages 
allowed); and

(iii) Extended Planned Outage Timeframe - WHOIS (no planned outages allowed).

3.3.3 Extended Planned Outage Notification. The Registry Operator must notify 
all of its Registrars of any Extended Planned Outage. The Extended Planned 
Outage Notification Performance Specification defines the number of days prior 
to an Extended Planned Outage that the Registry Operator must notify its 
Registrars. The Extended Planned Outage Notification for the Core Services is 
as follows:

(i) Extended Planned Outage Notification - SRS = 28 days;

(ii) Extended Planned Outage Notification - Nameserver =(no planned outages 
allowed); and

(iii) Extended Planned Outage Notification - WHOIS (no planned outages allowed).

3.4 Processing Time. Processing Time is an important measurement of transaction-
based services like the Registry. Processing Time measures the quality of that 
service.

Processing Time refers to the time that the Registry Operator receives a 
request and sends a response to that request. Since each of the Registry 
Services has a unique function,the Performance Specifications for Processing 
Time are unique to each of the Registry Services. For example, a Performance 
Specification for the Nameserver is not applicable to the SRS and WHOIS, etc. 
Processing Time Performance Specifications are a C2 priority level.
Processing Time Performance Specifications have a monthly Service Level 
Measurement Period and will be reported on a monthly basis. The Registry 
Operator will log the processing time for all of the related transactions, 
measured from the time it receives the request to the time that it returns a 
response.

3.4.1 Processing Time--Add, Modify, Delete = 1000 milliseconds for 95%.

(i) Processing Time - Add, Modify, and Delete is applicable to the SRS as 
accessed through the EPP protocol defined in Appendix C. It measures the 
processing time for add, modify, and delete transactions associated with domain 
names, nameservers, contacts, and Registrar profile information.

(ii) The Performance Specification is 1000 milliseconds for 95% of the 
transactions processed. That is, 95% of the transactions will take 1000 
millisecond or less from the time the Registry Operator receives the request to 
the time it provides a response.

3.4.2 Processing Time--Query Domain

(i) Processing Time - Query Domain is applicable to the SRS as accessed through 
the EPP protocol defined in Appendix C. It measures the processing time for an 
availability query of a specific domain name.

(ii) The performance specification is 500 milliseconds for 95% of the 
transactions. That is, 95% of the transactions will take 500 milliseconds or 
less from the time the Registry Operator receives the query to the time it 
provides a response as to the domain name's availability.

3.4.3 Processing Time--WHOIS Query.

(i) Processing Time - WHOIS Query is only applicable to the WHOIS. It measures 
the processing time for a WHOIS Query.

(ii) The Performance Specification is 1000 milliseconds for 95% of the 
transactions. That is, 95% of the transactions will take 1000 milliseconds or 
less from the time the WHOIS receives a query to the time it responds.

3.4.4 Processing Time--Nameserver Resolution.

(i) Processing Time - Nameserver Resolution is only applicable to the 
Nameserver. It measures the processing time for a DNS query.

(ii) The Performance Specification is 250 milliseconds for 95% of the 
transactions. That is, 95% of the transactions will take 250 milliseconds or 
less from the time Nameserver receives the DNS query to the time it provides a 
response.

3.5 Update Frequency. There are two important elements of the Registry that are 
updated frequently and are used by the general public; Nameserver and WHOIS. 
Registrars generate these updates through the SRS. The SRS then updates the 
Nameserver and the WHOIS. These will be done on a batch basis. Update Frequency 
Performance Specifications are a C3 priority level.

The committed Performance Specification with regard to Update Frequency for 
both the Nameserver and the WHOIS is 10 minutes for 95% of the transactions. 
That is, 95% of the updates to the Nameserver and WHOIS will be effectuated 
within 10 minutes. This is measured from the time that the registry confirms 
the update to the Registrar to the time the update appears in the Nameserver 
and WHOIS. Update Frequency Performance Specifications have a monthly Service 
Level Measurement Period and will be reported on a monthly basis.

3.5.1 Update Frequency--Nameserver = 10 minutes for 95%.

3.5.2 Update Frequency--WHOIS = 10 minutes for 95%.

3.6 Cross-Network Nameserver Performance Requirements. Nameserver round-trip-
time and packet loss from the Internet are important elements of the quality of 
service provided by the Registry Operator. These characteristics, however, are 
affected by Internet performance and therefore cannot be closely controlled by 
Registry Operator. Accordingly, these requirements are not matters subject to 
Service Level Exceptions and credits under the Service Level Agreement 
(Appendix E), but they are Registry Operator obligations under Section 3.3 of 
the Registry Agreement.

The committed Performance Specification for cross-network nameserver 
performance is a measured round-trip time (RTT) of under 300 ms and measured 
packet loss of under 10%. Cross-network nameserver performance measurements 
will be conducted by ICANN at times of its choosing, in the following manner:
3.6.1 The measurements will be conducted by sending strings of DNS request 
packets from each of four measuring locations to each of the .NET nameservers 
and observing the responses from the .NET nameservers. (These strings of 
requests and responses are referred to as a "CNNP Test".) The measuring 
locations will be 4 locations (on the US East Coast, US West Coast, Asia, and 
Europe).

3.6.2 Each string of request packets will consist of 100 UDP packets at 10 
second intervals requesting ns records for arbitrarily selected .NET second-
level domains, preselected to ensure that the names exist in the Registry TLD 
and are resolvable. The packet loss (i.e. the percentage of response packets 
not received) and the average round-trip time for response packets received 
will be noted.

3.6.3 To meet the packet loss and round-trip-time requirements for a particular 
CNNP Test, all measured RTTs must be less than 300 ms and these must be less 
than 10% packet loss.

3.6.4 Any failing CNNP Test result obtained during an identified Core Internet 
Service Failure shall not be considered.

3.6.5 To ensure a properly diverse testing sample, Registry Operator will 
contract with a third party to perform the test and provide the results to 
ICANN and the Registry Operator. The CNNP Tests at varying times (i.e. at 
different times of the day, as well as on different days of the week). Registry 
operator will be deemed to have failed to meet the cross-network nameserver 
performance requirement only if the .NET nameservers persistently fail (see 
Section 3.6.3 above) the CNNP Tests with no less than three consecutive failed 
CNNP Tests to be considered to have persistently failed.

3.6.6 In the event of persistent failure of the CNNP Tests, ICANN will give 
Registry Operator written notice of the failures (with backup data) and 
Registry Operator will have sixty days to cure the failure.

3.6.7 If, following that opportunity to cure, the .NET nameservers continue to 
persistently fail CNNP Tests and Registry Operator fails to resolve the problem 
after thirty days notice of the continuing failures, Registry Operator will be 
deemed not to have met its obligations under Subsection 3.3 of the Registry 
Agreement.

3.6.8 Sixty days prior to the commencement of testing under this provision, 
ICANN will provide Registry Operator with the opportunity to evaluate the 
testing tools and procedures to be used by ICANN. In the event that Registry 
Operator does not approve of such tools and procedures, ICANN will work 
directly with Registry Operator to make necessary modifications.

4. Responsibilities of the Parties.

4.1 Except in the case of nameserver performance measurements, Registry 
Operator will perform monitoring from internally located systems as a means to 
verify that the availability and performance measurements in this document are 
being met.

4.2 Beginning no later than 90 days post Commencement-of-Service Date, the 
Registry Operator will publish preliminary weekly system performance and 
availability reports. Registry operator will use best efforts to finalize these 
reports no later than 30 days after the preliminary reports are provided.

4.3 The Registry Operator will provide the WHOIS Service as specified in 
Appendices C and O.

4.4 The Registry Operator will use commercially reasonable efforts to restore 
the critical systems of the Core Services within 24 hours after the termination 
of a force majeure event and restore full system functionality within 48 hours 
after the termination of a force majeure event. Outages due to a force majeure 
will not be considered Service Unavailability.

5. Miscellaneous.

5.1 This Appendix is not intended to replace any term or condition in the 
Registry Agreement.

5.2 Dispute Resolution will be handled pursuant to the terms of Subsection 5.9 
of the Registry Agreement. 


Appendix E, Service-Level Agreement

1. Definitions. Capitalized terms used herein and not otherwise defined shall 
have the definitions ascribed to them in Appendix D to the Registry Agreement 
or the Registry-Registrar Agreement.

2. Credits. If Registry Operator fails to meet the Performance Specifications 
defined in Appendix D to the Registry Agreement ("Service Level Exception" 
or "SLE"), Registry Operator shall pay in the aggregate to the Registrar 
Community a credit according to the tables provided below ("Applicable 
Credit"). Each Registrar shall only be entitled to a fraction of the Applicable 
Credit. Such fractions of the credit specified in the tables to be paid to any 
individual Registrar will be calculated based upon the number of domain names 
that such Registrar added to the Registry during the Service Level Measurement 
Period compared to the total number of domain names added to the Registry by 
all Registrars during the Service Level Measurement Period in which the SLE 
occurred. The credit due to Registrar may be paid as an offset to registrations 
and other fees owed to Registry Operator by Registrar. All credits shall be 
paid in U.S. Dollars. The following Credit Lookup Matrix indicates the 
corresponding credit table for which the credits defined in this Appendix will 
be levied.

Note: The cross-network nameserver performance requirement is a subject of 
Registry Operator's obligations under Subsection 3.3 of the Registry Agreement 
but is not a subject of this Service Level Agreement (Appendix E).

If one or more SLEs occurs as the direct result of a failure to meet a 
Performance Specification in a single credit class, Registry Operator shall be 
responsible only for the credit assessed for the credit class which is the 
proximate cause for all directly related failures.

The following tables identify total Registrar Community credits due for SLEs in 
the four credit classes C1 - C4. Notwithstanding the credit levels contained in 
these tables, the total credits owed by Registry Operator under this Agreement 
shall not exceed $ 50,000 USD monthly and $ 400,000 USD annually. The credits 
contained in Tables C1a-C4 represent the total credits that may be assessed in 
a given SLE category in one Service Level Measurement Period.

2.1 C1 Credit Class-If availability of C1 Credit Class components or systems 
does not meet C1 Performance Specifications in any given Service Level 
Measurement Period described in the Performance Specification Matrix in 
Appendix D of the Registry Agreement, Registry Operator will credit the 
Registrar Community according to the tables (which amount will be credited to 
the Registrar on a proportional basis as set forth above).

Table C1a
SLE         < 2 min.'s	2-10 min.'s	10-30 min.'s	over 30 min.'s
--------------------------------------------------------------------------------
Monthly        
Credit to     $ 3,750    $ 5,000           $ 7,500         $10,000
Registrar 
Community				

C1a Availability Example: In a given measurement period, assume the SRS 
Availability is 99.87%, which equates to 52 minutes of unplanned downtime. The 
Registry Operator's Performance Specification for SRS Availability is 99.95%, 
or approximately 22 minutes of downtime. The Service Level Exception, 
therefore, is 30 minutes (52-22 minutes), the difference between the 
Performance Specification and the actual measured performance. From the Credit 
Lookup Matrix, we see the relevant SLA is found in Table C1a. In Table C1a, the 
time interval (2-10 minutes) has a corresponding credit of $7,500 USD to be 
paid to the Registrar Community.

Table C1b 
SLE	< 10 min.'s 10-30 min.'s	 30-60 min.'s  1-2 hrs  2-4 hrs	over 4 
hrs
--------------------------------------------------------------------------------
Annual 
Credit    $7,500      $15,000      $25,000      $35,000   $50,000   $75,000
to Registrar 
Community						

C1b Availability Example: In a given Service Level Measurement Period, the 
measured Nameserver Availability is 99.990% over a twelve (12) month period, 
which equates to 52 minutes of downtime. The Registry Operator's Performance 
Specification for Nameserver Availability is 100%, or 0 minutes of downtime per 
calendar year. The Service Level Exception, therefore, is 52 minutes (52-0 
minutes), the difference between the Performance Specification and the actual 
measured performance. From the Credit Lookup Matrix, we see the relevant SLA is 
found in Table C1b. In Table C1b, the time interval (30-60 minutes) has a 
corresponding credit of $25,000 USD to be paid to the Registrar Community.

2.2 C2 Credit Class-If processing time for C2 Credit Class services does not 
meet C2 Service Levels in any given Service Level Measurement Period, Registry 
Operator will credit the Registrar Community according to the following table 
(which amount will be credited to the Registrars on a proportional basis as set 
forth above).

Table C2 
SLE	< 2 sec.'s	2-10 sec.'s	10-20 sec.'s	> 20 sec.'s
-------------------------------------------------------------------------
Monthly 
Credit to     $500        $1,000           $5,000          $7,500
Registrar 
Community				

C2 Processing Example: The Performance Specification for Processing Time for 
Add, Modify, and Delete is 1 second or less for 95% of the transactions. In a 
given Service Level Measurement Period 7% of the transactions are greater than 
1 second. The 5% of those transactions with the longest processing times are 
not subject to the SLE calculation (1 second for 95%). The SLE is calculated 
using the average processing time for the 2% of the transactions that are 
subject to the SLE. If there were 1,000 transactions and they took a total of 
4,000 seconds the average is 4 seconds. That generates an SLE of 3 seconds (4 
seconds - 1 seconds). From the Credit Lookup Matrix, we see the relevant SLA is 
found in Table C2. In Table C2, the SLE time interval (2-5 seconds) has a 
corresponding credit of $1,000 USD to be paid to the Registrar Community.

2.3 C3 Credit Class-If update frequency measurements of C3 Credit Class 
components or systems do not meet C3 Service Levels in any given Service Level 
Measurement Period as described in the Performance Specification Matrix in 
Appendix D of the Registry Agreement, Registry Operator will credit the 
Registrar Community according to the following tables (which amount will be 
credited to the Registrars on a proportional basis as set forth above).

Table C3
SLE    < 30 sec's  30-60 sec's  1-2 min's  2-10 min's 10-30 min's  > 30 min's
----------------------------------------------------------------------------
Monthly 
Credit to  $250     $500         $1,000     $1,500      $2,000     $3,000
Registrar 
Community						

C3 Update Frequency Example: In a given Service Level Measurement Period, 95% 
of the updates to the Nameserver take 24 minutes or less to complete. The 
corresponding Registry Operator's Performance Specification is 10 minutes for 
95% of the updates. The SLE, therefore, is 14 minutes. From the Credit Lookup 
Matrix, we see the relevant SLA is found in Table C3. The SLE time interval (10-
30 minutes) has a corresponding credit of $2,000 USD to be paid to the 
Registrar Community.

2.4 C4 Credit Class-If Registry Operator fails to comply with C4 Credit Class 
category Performance Specifications, Registry Operator will credit the 
Registrar Community according to the following tables (C4a and C4b) (which 
amount will be credited to the Registrars on a proportional basis as set forth 
above).

Table C4a 
SLE	          Any
------------------------
Monthly 
Credit to        $1,000
Registrar 
Community	

C4a Planned Outage Notification Example: In each instance the Registry Operator 
fails to meet the Performance Specifications for Notification and Timeframe 
related to Planned Outages and Extended Planned Outages, the Registry Operator 
is subject to the credit in Table C4a. For example, the Registry Operator 
informs the Registrar Community that it will initiate a Planned Outage of the 
SRS on the next calendar Sunday (five (5) days advance notice). The 
corresponding Registry Operator's Performance Specification is 28 days notice. 
From the Credit Lookup Matrix, we see the relevant SLA is found in Table C4a. 
This results in a credit of $500 USD to be paid to the Registrar Community.

Table C4b 
SLE	< 1 hour	    1-4 hours	4-6 hours    6-10 hours    >10 hours
-------------------------------------------------------------------------
Monthly 
Credit to  $500      $1,000      $1,500       $ 5,000       $ 7,500
Registrar 
Community					

C4b Extended Planned Outage Example: In a given Service Level Measurement 
Period, the actual duration of a planned outage is 11 hours and 20 minutes for 
the SRS. The corresponding Registry Operator's Performance Specification is 8 
hours per month for the SRS. The SLE, therefore, is 3 hours and 20 minutes. 
From the Credit Lookup Matrix the relevant SLA is found in Table C4b. The SLE 
time interval (2-4 hours) has a corresponding credit of $1,500 USD to be paid 
to the Registrar Community.

3. Receipt of Credits. In order for Registrars to claim credits, the following 
procedure must be followed:

3.1 Registry operator shall perform the required measurements in order to 
obtain the total credits associated with the applicable Service Level 
Measurement Period. Such measurements and associated documentation shall be 
delivered by email to each of the Registrars in the Registrar Community. Such 
notice shall also include the total credit (if any) to be paid to the Registrar 
Community as a result of any outages.

3.2 Receipt of Credit - When the above steps have been completed, the Registry 
Operator shall enter in each Registrar's account balance the amount of credit 
(if applicable) that can be used immediately toward registrations in the 
Registry.

4. Obligations.

4.1 Except in the case of cross-network nameserver performance (which is not a 
subject of this Service Level Agreement), Registry Operator will perform 
monitoring from internally located systems as a means to verify that the 
conditions of the SLA are being met.

4.2 Upon written request, and at the sole expense of the requesting Registrar
(s), Registry Operator will retain an independent third party to be selected by 
Registry Operator with the consent of the Registrar(s). The Registrar may, 
under reasonable terms and conditions, audit the reconciliation records for the 
purposes of verifying measurements of the Performance Specifications. The 
frequency of these audits will be no more than once yearly during the term of 
the agreement between Registry Operator and the Registrar.

4.3 With the exception of Name Service Availability as defined in Section 
3.1.3.1 of Appendix D, Registry Operator's obligations under this SLA (Appendix 
E) are waived during the first 90 days after the Commencement-of-Service Date.  
For  violations of 3.1.3.a of Appendix D, the SLA credits shall not be so 
waived.

4.4 A Registrar must report each occurrence of alleged occasion of 
Unavailability of Core Services to the Registry Operator customer service help 
desk in the manner required by the Registry Operator (i.e., email, fax, 
telephone) in order for an occurrence to be treated as Unavailable for purposes 
of the SLE.

4.5 In the event that the Core Services are unavailable to an individual 
Registrar, Registry Operator will use commercially reasonable efforts to re-
establish the affected Core Services for such Registrar as soon as reasonably 
practicable. In the event that the Unavailability of Core Services affects all 
Registrars, the Registry Operator is responsible for opening a blanket trouble 
ticket and immediately notifying all Registrars of the trouble ticket number 
and details.

4.6 Both Registrar and the Registry Operator agree to use reasonable commercial 
good faith efforts to establish the cause of any alleged Core Services 
Unavailability. If it is mutually determined to be a Registry Operator problem, 
the issue will become part of the Unplanned Outage minutes.

4.7 Registry operator will use best efforts to publish system performance and 
availability reports no later than 30 days after the end of each month.

4.8 The Registry Operator will use commercially reasonable efforts to restore 
the critical systems of the Core Services within 24 hours after the termination 
of a force majeure event and restore full system functionality within 48 hours 
after the termination of a force majeure event. Outages due to a force majeure 
will not be considered Service Unavailability.

4.9 Incident trouble tickets must be opened within a commercially reasonable 
period of time.

5. Miscellaneous.

5.1 This Service Level Agreement is independent of any rights, obligations or 
duties set forth in the Registry Agreement. In the event of any conflict 
between the terms and conditions of this Agreement and the Registry Agreement, 
the Registry Agreement shall control.


Appendix O*, Whois Specification – Public Whois

WHOIS Specification--Public WHOIS 
The WHOIS service is compliant with RFC 3912 (formerly 954). The primary WHOIS 
services substantially consist of:
· Port 43 WHOIS services (thick registry)
· Port 43 WHOIS services (thin registry)
· Port 43 WHOIS services (Modified thick registry) -- If approved by ICANN.
· Web-based WHOIS services (thin, thick and modified thick registries)

The primary WHOIS services are described in more detail below.

Sentan Registry Services, Inc.'s (Sentan) WHOIS service is the authoritative 
WHOIS service for all second-level Internet domain names registered in the .NET 
gTLD and for all hosts registered using these names. This service is available 
to anyone. It is available via port 43 and through the Sentan website. 

In order to smoothly and seamlessly transition .NET registry operations and to 
minimize the burden on existing registrars, Sentan will initially operate 
the .NET registry WHOIS in a manner consistent with a "thin" registry, similar 
to its operation by the incumbent, and as further detailed in the 
specifications below.  Upon conclusion of the Transition Process (Appendix J), 
Sentan proposes to go to a "modified thick" WHOIS display that displays 
selected WHOIS data, but allows individual registrars to run their own public 
WHOIS. If accepted by ICANN, the modified thick display will contain all of the 
information in a thin registry plus the name, organization and postal address 
of the registrant. The modified thick display will provide a central, openly 
accessible system for information regarding a particular second level domain 
name registration in the .NET gTLD.  In the event ICANN desires Sentan to 
operate a fully thick registry, including the WHOIS display, it shall do so 
post transition. 

The WHOIS system has been designed for durability, availability, and 
performance. Provisions for detection of abusive usage, i.e. excessive numbers 
of queries from one source, have been taken into account, and other 
countermeasures against abuse will be activated if necessary.

Sentan will initially provide at least 3 geographically distributed operational 
WHOIS sites.  All WHOIS servers will run a dynamic update process. For WHOIS 
servers at the main data center, the update application will only be accessible 
from the internal network. External WHOIS sites, will utilize a secure 
communication channel for these updates. An update approach such as described 
above ensures that the WHOIS data is secure, accurate, and optimizes bandwidth 
usage.

This Appendix is subject to change by agreement of Sentan and ICANN during the 
design process as well as during the IETF standards process.

The WHOIS service is described in more detail below.

1. PORT 43 WHOIS SERVICE (THICK/MODIFIED THICK REGISTRY)
· The format of responses will follow a semi-free text format outlined below, 
preceded by a mandatory disclaimer specifying the rights of the registry 
operator, and of the user querying the database.

· Each data object shall be represented as a set of key/value pairs, with lines 
beginning with keys, followed by the colon as a delimiter, followed by the 
value.

· All WHOIS data will be in the ASCII character set, which has encoding 
compatible with UTF-8 for easy transition to including internationalized data, 
and as per the IETF's recommendations on i18n in Internet protocols. For fields 
where more than one value exists, multiple key/value pairs with the same key 
shall be allowed (e.g. to list multiple nameservers). The first key/value pair 
after a blank line should be considered the start of a new record.  It should 
be considered as identifying that record and is used to group data together, 
such as hostnames and IP addresses, or a domain name and registrant information.

· All record and key types shall be specified in a publicly available 
description on the Sentan's website. The record types and key names should 
change as infrequently as possible.

2. PORT 43 WHOIS SERVICE (THIN REGISTRY)
· The format of responses for thin registry output will be similar to the 
guidelines listed above for thick-registry WHOIS.

· The WHOIS contact information will indicate that the WHOIS information for 
this domain is not authoritative and indicate a URL to the WHOIS server of the 
registrar responsible for providing the domain WHOIS information. The 
administrative and technical contact blocks will be used to communicate this 
information. See 7.3 below for the output fields.

· All WHOIS data will be in the ASCII character set, which has encoding 
compatible with UTF-8 for easy transition to including internationalized data, 
and as per the IETF's recommendations on i18n in Internet protocols. For fields 
where more than one value exists, multiple key/value pairs with the same key 
shall be allowed (e.g. to list multiple nameservers). The first key/value pair 
after a blank line should be considered the start of a new record.  It should 
be considered as identifying that record, and is used to group data together, 
such as hostnames and IP addresses, or a domain name and registrant information.

· All record and key types shall be specified in a publicly available 
description on the Sentan's website. The record types and key names should 
change as infrequently as possible.

3. WEB-BASED WHOIS SERVICE (THICK, THIN AND MODIFIED THICK REGISTRY)
Sentan will make available a WHOIS interface on its website which can also be 
accessed by each ICANN-Accredited Registrar that is a party to a Registry-
Registrar Agreement with Sentan. The information available in the WHOIS 
database will be returned as a results page on the website.  An example of the 
fields contained in the returned data, which are identical to the Port 43 thick 
or modified thick registry WHOIS, can be found in the WHOIS output fields 
section below.  When thick (or modified thick) registry WHOIS information is 
unavailable, the registry shall provide thin registry WHOIS information, as 
specified in the WHOIS Output Fields section.

4. MINIMUM DATA UPDATE FREQUENCY
The update frequency of WHOIS data is specified in Appendix D Section 4.2.

5. PROTOCOLS THROUGH WHICH ACCESS IS PROVIDED 
Access to the WHOIS data is provided through the WHOIS protocol, supporting 
exact queries for domain names, contact IDs, registrar name, nameserver 
hostname and nameserver ip-address. The WHOIS data will also be accessible 
through the Sentan web interface as described above. Bulk access to the WHOIS 
data will be made available as specified in Appendix P and Appendix Q.

6. SECURITY
General security measures such as password aging policy, firewalls, Intrusion 
Detection Systems (IDS) and network traffic monitoring systems will be provided 
for the WHOIS services, as further described in the Appendix C Security section.

The WHOIS output in the thick registry model, which will be the only supported 
model at the completion of the Transition Plan as set forth in Appendix J, will 
be returned with the respective key/value pairs. This eliminates the need for 
registrars to maintain their own WHOIS information. They can link to the 
registry and present it to end users. The proposed capability will also ensure 
that end users will view the same information no matter which registrar they 
use to retrieve WHOIS data. 

7. QUERY AND OUTPUT FOR REPORTS DELIVERED BY WEB PAGE AND PORT 43

7.1 WHOIS Queries

For all WHOIS queries, the client provides a character string for which 
information is desired and optionally, the object type and interpretation 
control parameters to limit the search. If the object type and interpretation 
control parameters are not specified, WHOIS searches for the character string 
in the Name fields of the Domain object. Object type controls are available to 
limit the search to just data in the specified object. Interpretation controls 
are available to limit the search to just the ID field of an object, or to 
specify partial keyword matching or to provide full or summary output.
Queries can be made as either an "exact search" or a "partial search", both of 
which are insensitive to the input string case.  An exact search specifies the 
full string to search for in the database field. An exact match between the 
input string and the field value is required. For example: "sentanregistry.net" 
will only match with "sentanregistry.net".  A partial search specifies the 
start of the string to search for in the database field. Every record with a 
search field that starts with the input string will be considered a match. For 
example: "sentanregistry.net" will match with "sentanregistry.net" as well 
as "sentanregistry.net, Inc."

By default, if multiple matches are found for a query, then a summary of all 
the matching results is presented. A second query is required to retrieve the 
specific details of one of the matching records.  If only a single match is 
found, then full details will be provided. Full detail consists of the data in 
the matching object as well as the data in any associated objects. For example, 
a query that results in a domain object will include the data from the 
associated nameserver and contact objects. Additional information and samples 
of the various types of WHOIS result records are available in the WHOIS Output 
Fields and Sample WHOIS Output sections below.

7.2 Query Controls
WHOIS query controls fall into two categories: those that specify the type of 
field and those that modify the interpretation of the input or determine the 
type of output to provide.

Object Type Control

The following keywords restrict a search to a specific object type:

Domain: Search only domain objects. The input string is searched in the Name 
field.

Host: Search only nameserver objects. The input string is searched in the Name 
field and the IP Address field.

Contact:	Search only contact objects. The input string is searched in 
the ID 
field.

Registrar: Search only registrar objects. The input string is searched in the 
Name field.

By default, if no object type control is specified, then the Name field of the 
Domain object is searched.

Interpretation Control

The following keywords modify the interpretation of the input or determine the 
level of output to provide:

partial	All records matching string are returned
.	Same as partial keyword
full	Displays entire detail associated with each returned record
=	Same as full keyword
summary	Displays summary
$	Same as summary keyword
help	Displays help text 
?	Same as help keyword

By default, if no interpretation control keywords are used, the output will 
include full details if a single record is found and a summary if multiple 
matches are found.

7.3 WHOIS Output Fields
This section describes the output fields provided for each type of object. 
Sentan will not be required to post WHOIS Output Fields that are not required 
for posting in the Registrar Accreditation Agreement.

Domain Record
A WHOIS query that results in domain information will return the following 
fields from the Domain object and the associated data from Host and Contact 
objects. This set of data is also referred to as the Domain Record.

a) Transition Period Display (First 9-months)
Domain Name
Domain ID
Sponsoring Registrar
Registrar IANA ID
Domain Status
Nameservers associated with this domain
Domain Registration Date
Domain Expiration Date
Domain Last Updated Date
WHOIS Server
Referral URL

b) Display after Transition Period 
Domain Name
Domain ID
Sponsoring Registrar
Registrar IANA ID
Domain Status
Registrant, Administrative, Technical and Billing Contact Information including:
   Contact ID
   Contact Name
   Contact Organization
   Contact Address, City, State/Province, Country
   Contact Postal Code
   Contact Phone, Facsimilie (optional), Email
Nameservers associated with this domain
Domain Registration Date
Domain Expiration Date
Domain Last Updated Date
WHOIS Server
Referral URL
Created by Registrar
Last Updated by Registrar

Note: For domains on PendingDelete Status, the registry's front-end web 
interface will provide an additional explanation of the status as follows:

Up to 30 days after deletion: PendingDelete (Restorable)
More than 30 days after deletion:	PendingDelete (Scheduled for release)

Nameserver Record

A WHOIS query that results in nameserver information will return the following 
set of information referred to as the Nameserver Record or Host Record.

Nameserver Host Name
Nameserver ID
Nameserver IP Addresses if applicable Sponsoring Registrar
Nameserver Creation Date
Nameserver Last Updated Date
WHOIS Server
Referral URL
Nameserver Status
Created by Registrar
Sponsoring Registrar

Contact Record (Post 9-month Transition Period)

A WHOIS query that results in contact information will return the following set 
of information referred to as the Contact Record.

Contact ID
Sponsoring registrar
Contact Name
Contact Organization
Contact Address, City, State/Province, Country
Contact Postal Code
Contact Phone, Facsimile, Email
Contact Registration Date
Contact Last Updated Date
WHOIS Server
Referral URL
Last Updated by Registrar
Created by Registrar
Contact Status

Note: Under modified thick registry, if approved by ICANN, we will not display 
administration, technical, and billing contacts.  We also will not display 
contact phone, facsimile, or email.

Registrar Record
A WHOIS query that results in registrar information will return the following 
set of information referred to as the Registrar Record.

Registrar ID (conforms to IANA registrar-ids registry)
Registrar Name
Registrar Address, City, State/Province, Country
Registrar Postal Code
Registrar Phone, Facsimile, Email 
Registrar Administrative Contacts
Registrar Technical Contacts
Registrar Billing Contacts
Registrar URL (registration services) 
Registrar Creation Date 
Registrar Last Updated Date
WHOIS Server
Referral URL

8. Extensible-Field Capability
Sentan reserves the right to introduce the ability for registrars to use EPP, 
to add customized fields to a record in the registry database. These fields 
will appear in an "additional information" section of the WHOIS data. The 
maximum number of custom fields allowed per record is yet to be determined.

Appendix P*, Whois Data Specification – Independent Whois Provider

WHOIS Provider Data Specification
Registry Operator will provide bulk access to up-to-date data concerning domain 
name and nameserver registrations maintained by Registry Operator in connection 
with the Registry gTLD on a daily schedule, only for purposes of providing free 
public query-based access to up-to-date data concerning domain name and 
nameserver registrations in multiple gTLDs, to a party designated from time to 
time in writing by ICANN (the "Designated Recipient").

The procedures for providing access, and the specification of the content and 
format of this data, will be as stated below, until changed according to the 
Registry Agreement. This Appendix is subject to change by agreement of Registry 
Operator and ICANN during the design process as well as during the IETF 
standards process.  Accordingly, the following provides the target architecture 
and initial functionality.

A. Procedures for Providing Access

The Registry Operator will prepare (i) full data sets for one day of each week 
(the day to be designated by ICANN) and (ii) incremental data sets for all 
seven days of each week. Full and incremental data sets shall be up-to-date and 
coherent as of 1200 UTC on the day to which they relate. Until a different day 
is designated by ICANN, the full data sets will be prepared for Sundays. (Note 
that on the ICANN-designated day both an incremental and a full data set are 
prepared.)

1. Preparation of Files Containing Data Sets. Each full and incremental data 
set consists of an XML document meeting the content and format requirements of 
Parts B and C of this document. Once the XML document is generated, the 
following preparation steps will be performed:

a. The XML document will be placed in a file named according to the following 
convention:

For full data sets: "wfYYMMDD" where "YYMMDD" is replaced with the date 
(YY=last two digits of year; MM=number of month; DD=day; in all cases a single-
digit number should be left-padded with a zero).

For incremental data sets: "wiYYMMDD" where "YYMMDD" follows the same format.

b. The Registry Operator may optionally split the document using the Unix SPLIT 
command (or equivalent) to produce files no less than 1GB each (except the 
final file). If files are split, an MD5 file (produced with MD5SUM or 
equivalent) must be included with the resulting files to isolate errors in case 
of transfer fault. The Registry Operator may optionally compress the document 
using the Unix GZIP command (or equivalent) to reduce the file size.

c. The file(s) will then be encrypted and signed using PGP, version 6.5.1 or 
above, with a key of DH/DSS type and 2048/1024-byte length. (Note that PGP 
compresses the escrow file in addition to encrypting it.) The Data Recipient's 
public key will be used for the encryption and the Registry Operator's private 
key will be used for the signature. Public keys will be exchanged between the 
Registry Operator and the Designated Recipient by email, physical delivery of 
floppy diskettes, or other agreed means.

2. Transmission of Full Data Sets. Once prepared, full data sets will be 
provided either by the procedures for incremental data sets described in item A
(3) below or, at the option of either the Registry Operator or the Designated 
Recipient, by writing the full data set to DAT tape (or other media mutually 
agreed by Registry Operator and the Designated Recipient) and sending it to the 
Designated Recipient by expedited delivery service (such as FedEx or DHL). If 
sent by expedited delivery service, the full data set will be scheduled for 
arrival no later than the second calendar day following the day to which the 
full backup relates.

3. Transmission of Incremental Data Sets. To permit the transmission of 
incremental data sets, the Registry Operator will make them available for 
download by the Designated Recipient by Internet File Transfer Protocol. 
Incremental data sets will be made available for download no later than 20:00 
UTC on the day to which they relate.

B. Content
The data sets, whether full or incremental, will consist of four types of 
objects:

1. Domain objects. One type of object is the domain object, which corresponds 
to a single Registered Name. Each domain object includes the following data:

Domain ID
Domain Name
Sponsoring Registrar (IANA-assigned identifier)
Domain Status
Registrant, Administrative, Technical and Billing Contact Information including
   Contact ID
   Contact Name
   Contact Organization
   Contact Address, City, State/Province, Country
   Contact Postal Code
   Contact Phone, Facsimile, Email
Name Servers associated with this domain
Created by Registrar (IANA-assigned identifier)
Last Updated by Registrar (IANA-assigned identifier)
Last Transferred Date
Additional fields (registrar specified)
Domain Registration Date
Domain Expiration Date
Domain Last Updated Date
WHOIS Server
Referral URL

2. Nameserver objects. A second type of object is the nameserver object, which 
corresponds to a single registered nameserver. The nameserver object includes 
the following data:

Nameserver ID
Nameserver Name
IP Addresses associated 
Sponsoring Registrar(IANA-assigned identifier)
Created by Registrar (IANA-assigned identifier)
Name Server Last Updated by Registrar (IANA-assigned identifier)
Last Transferred Date
Nameserver Status
WHOIS Server
Referral URL

3. Contact objects. A third type of object is the contact object, which 
corresponds to a single contact (whether registrant, administrative, technical 
or billing contact). The contact object includes the following data:

Contact ID
Contact Name
Contact Organization
Contact Address, City, State/Province, Country
Contact Postal Code
Contact Phone, Facsimile, Email
Contact Registration Date
Contact Last Updated Date
Contact Status
Sponsoring Registrar (IANA-assigned identifier)
Created Registrar (IANA-assigned identifier)
Last Updated by Registrar
WHOIS Server
Referral URL

4. Registrar object. The final type of object corresponds to a single 
registrar. It includes the following data:

Registrar ID (conforming to the IANA registrar-ids registry)
Registrar Name
Registrar Status
Registrar Address, City, State/Province, Country
Registrar Postal Code
Registrar Phone, Facsimile, Email
Registrar Administrative Contacts
Registrar Billing Contacts

5. Objects Contained in Full and Incremental Data Sets. Full data sets include 
one domain object for each Registered Name within the Registry gTLD; and 
nameserver, contact, and registrar objects for each nameserver, contact, and 
registrar referred to in any domain object. Incremental data sets consist of 
(a) those of the objects constituting a full data set that have been added or 
updated since the last incremental data set and (b) notations of deletion of 
any objects since the last incremental data set.

C. Format
Full and incremental data sets will be XML version 1.0, UTF-8 encoded documents 
conforming to the following document type definition:

<?xml version="1.0" encoding="UTF-8"?>

<schema targetNamespace="urn:sentan:whoisdb-1.0"
   xmlns:whoisdb="urn:sentan:whoisdb-1.0"
   xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
   xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
   xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
   xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
   xmlns:host="urn:ietf:params:xml:ns:host-1.0"
   xmlns="http://www.w3.org/2001/XMLSchema"
   elementFormDefault="qualified">

<!--
Import EPP Element Types
-->
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0"  schemaLocation="eppcom-
1.0.xsd"/>
<import namespace="urn:ietf:params:xml:ns:epp-1.0"     schemaLocation="epp-
1.0.xsd"/>
<import namespace="urn:ietf:params:xml:ns:contact-1.0" schemaLocation="contact-
1.0.xsd"/>
<import namespace="urn:ietf:params:xml:ns:domain-1.0"  schemaLocation="domain-
1.0.xsd"/>
<import namespace="urn:ietf:params:xml:ns:host-1.0"    schemaLocation="host-
1.0.xsd"/>

<annotation>
   <documentation>
      XML Schema for WHOIS Data Escrow From Sentan
   </documentation>
</annotation>

<!--
Child Element
-->
<element name="whois-data" type="whoisdb:whoisDbType"/>

<complexType name="whoisDbType">
   <choice>
      <element name="full"        type="whoisdb:fullsetType"/>
      <element name="incremental" type="whoisdb:partialType"/>
   </choice>
   <attribute name="tld"  type="whoisdb:tldType" use="required"/>
   <attribute name="date" type="dateTime"        use="required"/>
</complexType>
<simpleType name="tldType">
   <restriction base="string">
      <enumeration value="net"/>
   </restriction>
</simpleType>
<complexType name="fullsetType">
   <sequence>
      <element name="contact"       type="contact:infDataType"     
minOccurs="0" maxOccurs="unbounded"/>
      <element name="domain"        type="domain:infDataType"      
minOccurs="0" maxOccurs="unbounded"/>
      <element name="host"          type="host:infDataType"        
minOccurs="0" maxOccurs="unbounded"/>
      <element name="registrar"     type="whoisdb:registrarType"   
minOccurs="0" maxOccurs="unbounded"/>
   </sequence>
</complexType>
<complexType name="partialType">
   <sequence>
      <element name="contact"       type="contact:infDataType"     
minOccurs="0" maxOccurs="unbounded"/>
      <element name="domain"        type="domain:infDataType"      
minOccurs="0" maxOccurs="unbounded"/>
      <element name="host"          type="host:infDataType"        
minOccurs="0" maxOccurs="unbounded"/>
      <element name="registrar"     type="whoisdb:registrarType"   
minOccurs="0" maxOccurs="unbounded"/>
      <element name="del-contact"   type="contact:sIDType"         
minOccurs="0" maxOccurs="unbounded"/>
      <element name="del-domain"    type="domain:sNameType"        
minOccurs="0" maxOccurs="unbounded"/>
      <element name="del-host"      type="host:sNameType"          
minOccurs="0" maxOccurs="unbounded"/>
      <element name="del-registrar" type="whoisdb:registrarIDType" 
minOccurs="0" maxOccurs="unbounded"/>
   </sequence>
</complexType>
<complexType name="registrarIDType">
   <sequence>
      <element name="registrar-id" type="eppcom:clIDType"/>
   </sequence>
</complexType>

<!--
Registrar Type derived from XRP Specification
-->
<complexType name="registrarType">
   <sequence>
      <element name="roid"         type="eppcom:roidType"/>
      <element name="registrar-id" type="eppcom:clIDType"/>
      <element name="name"         type="whoisdb:registrarNameType"/>
      <element name="address"      type="contact:addrType"/>
      <element name="referral-url" type="whoisdb:registrarWebUrlType" 
minOccurs="0"/>
      <element name="whois-server" type="whoisdb:registrarWebUrlType" 
minOccurs="0"/>
      <element name="iana-id"      type="whoisdb:registrarIanaIDType"/>
      <element name="contact"      type="whoisdb:registrarContactType" 
maxOccurs="5"/>
      <element name="crDate"       type="dateTime"/>
      <element name="upDate"       type="dateTime" minOccurs="0"/>
   </sequence>
</complexType>
<simpleType name="registrarNameType">
   <restriction base="string">
      <minLength value="1"/>
      <maxLength value="128"/>
   </restriction>
</simpleType>
<simpleType name="registrarWebUrlType">
   <restriction base="string"/>
</simpleType>
<simpleType name="registrarIanaIDType">
   <restriction base="string"/>
</simpleType>
<complexType name="registrarContactType">
   <simpleContent>
      <extension base="eppcom:roidType">
         <attribute name="type" use="required">
            <simpleType>
               <restriction base="string">
                  <enumeration value="administrative"/>
                  <enumeration value="billing"/>
                  <enumeration value="technical"/>
               </restriction>
            </simpleType>
         </attribute>
      </extension>
   </simpleContent>
</complexType>
<simpleType name="registrarStatusType">
   <restriction base="string">
      <enumeration value="active"/>
      <enumeration value="suspended"/>
      <enumeration value="defunct"/>
   </restriction>
</simpleType>
</schema>


Appendix Q*, Whois Data Specification – ICANN

Whois Data Specification--ICANN

Registry Operator will provide bulk access to ICANN to up-to-date data 
concerning domain name and nameserver registrations maintained by Registry 
Operator in connection with the Registry TLD on a daily schedule, for purposes 
of verifying and ensuring the operational stability of Registry Services, the 
DNS, and the Internet.

The procedures for providing access, and the specification of the content and 
format of this data, will be as stated below, until changed according to the 
Registry Agreement. This Appendix is subject to change by agreement of Registry 
Operator and ICANN during the design process as well as during the IETF 
standards process. Accordingly, the following represents the target 
architecture and initial functionality.

A. Procedures for Providing Access

The Registry Operator will prepare a full data set once each week (the day to 
be designated by ICANN). Full data sets shall be up-to-date and coherent as of 
1200 UTC on the day to which they relate. Until a different day is designated 
by ICANN, the full data sets will be prepared for Sundays.

1. Preparation of Files Containing Data Sets. Each full data set consists of an 
XML document meeting the content and format requirements of Parts B and C of 
this document. Once the XML document is generated, the following preparation 
steps will be performed:

a. The XML document will be placed in a file named according to the following 
convention: "wfYYMMDD" where "YYMMDD" is replaced with the date (YY=last two 
digits of year; MM=number of month; DD=day; in all cases a single-digit number 
should be left-padded with a zero).

b. Registry Operator may optionally split the document using the Unix SPLIT 
command (or equivalent) to produce files no less than 1GB each (except the 
final file). If files are split, an MD5 file (produced with MD5SUM or 
equivalent) must be included with the resulting files to isolate errors. The 
Registry Operator may optionally compress the document using the Unix GZIP 
command (or equivalent) to reduce the filesize.

c. The file(s) will then be encrypted and signed using PGP, version 6.5.1 or 
above, with a key of DH/DSS type and 2048/1024-byte length. (Note that PGP 
compresses the escrow file in addition to encrypting it.) An ICANN public key 
will be used for the encryption and the Registry Operator's private key will be 
used for the signature. Public keys will be exchanged between the Registry 
Operator and ICANN by e-mail, physical delivery of floppy diskettes, or other 
agreed means.

2. Transmission of Full Data Sets. Once prepared, full data sets will be 
provided according to paragraph a below or, at Registry Operator's option, 
according to paragraph b below:

a. Registry Operator will make full data sets available for download by ICANN 
by Internet File Transfer Protocol (FTP). (FTP access will be password 
protected and limited to prespecified IP ranges.) The data sets will be made 
available for download beginning no later than 2000 UTC on the day to which 
they relate and until the next full data set becomes available for download.

b. Registry Operator will write the full data set to DAT (DDS-4) tape (or other 
media specified by ICANN) and send it to ICANN by expedited delivery service 
(such as FedEx or DHL). The full data set will be scheduled for arrival at 
ICANN no later than the fourth calendar day following the day to which the data 
set relates.

B. Content

The full data sets will consist of the objects and contents described for full 
data sets in Part B of Appendix P.

C. Format

Full data sets will be XML version 1.0, UTF-8 encoded documents conforming to 
the schema/document type declaration set forth in Part C of Appendix P.

Appendix R, Data Escrow Specification

Data Escrow Schedule, Content, Format, and Procedure
This Appendix to the Registry Agreement consists of four of the five exhibits 
to the Service Level Agreement that constitutes Appendix S to the Registry 
Agreement:
Exhibit A-Schedule for Escrow Deposits
Exhibit B-Escrow Deposit Format Specification
Exhibit C-Escrow Transfer Process
Exhibit D-Escrow Verification Procedures

The fifth exhibit (Exhibit E) to Appendix S, which sets forth the escrow 
agent's fees, is subject to negotiation between Registry Operator and the 
escrow agent.

Exhibit A-Schedule for Escrow Deposits

1. Procedures for Providing Access. The Registry Operator will prepare (i) full 
data sets for one day of each week (the day to be designated by ICANN) and (ii) 
incremental data sets for all seven days of each week. Full and incremental 
data sets shall be up-to-date and coherent as of 1200 UTC on the day to which 
they relate. Until a different day is designated by ICANN, the full data sets 
will be prepared for Sundays.

2. Preparation of Files Containing Data Sets. Each full and incremental data 
set consists of an XML document meeting the content and format requirements of 
Exhibit B of this document. Once the XML document is generated, the following 
preparation steps will be performed:
The XML document will be placed in a file named according to the following 
convention:

For full data sets: "wfYYMMDD" where "YYMMDD" is replaced with the date 
(YY=last two digits of year; MM=number of month; DD=day; in all cases a single-
digit number should be left-padded with a zero).

For incremental data sets: "wiYYMMDD" where "YYMMDD" follows the same format.

3. Start Date for Escrow Procedures. Registry Operator and ICANN shall 
cooperate in resolving implementation issues, an escrow agent shall be 
selected, and an escrow agreement shall be entered into in time for escrow 
deposits to begin within ninety days after the Commencement-of-Service Date.

Exhibit B-Escrow Deposit Format Specification

This Appendix is subject to change by agreement of Registry Operator and ICANN 
during the design process as well as during the IETF standards process. 

The escrow data sets (whether full or incremental) will consist of four types 
of objects:
·	Domain object 
·	Nameserver object 
·	Contact object 
·	Registrar object 

Additionally, incremental data sets will contain notations of deletion of 
objects since the last incremental data set.

1. The Domain Object. The domain object which corresponds to a single 
registered name consists of the following elements:

Domain ID
Domain Name
Sponsoring Registrar
Domain Status
Registrant Identifier
Contact Identifiers for Administrative, Technical and Billing Contacts
Name Servers associated with this domain
Child Name Servers registered in this domain
Domain Created by Registrar
Domain Last Updated by Registrar
Domain Registration Date
Domain Expiration Date
Domain Last updated Date
Domain Last Transfer Date
Domain Authorization Information
Additional Fields (Registrar Specified)

2. The Name Server Object. The nameserver object which corresponds to a single 
registered nameserver consists of the following elements:
Name Server ID
Name Server Name
Name Server Status
Name Server Association Status
Name Server IP Addresses (if applicable) 
Sponsoring Registrar
Created by Registrar
Name Server Creation Date
Name Server Last Updated Date
Name Server Last Transfer Date
Additional fields (Registrar Specified)
Name Server Authorization Information

3. The Contact Object. The contact object, which corresponds to a single 
contact (whether registrant, administrative, technical or billing contact) 
consists of the following elements:
Contact ID
Contact Name
Contact Status
Contact Association Status
Contact Organization
Contact Address, City, State/Province, Country
Contact Postal Code
Contact Phone, Facsimile, Email
Sponsoring Registrar
Created by Registrar
Contact Creation Date
Contact Last Updated Date
Contact Last Transfer Date
Contact Authorization Information
Additional fields (Registrar Specified)

4. The Registrar Object. The registrar object, which corresponds to a single 
registrar consists of the following elements:
Registrar ID (registry specific)
Registrar Object Identifier (Unique object Identifier)
Registrar ID (conforming to the IANA registrar-ids registry)
Contact ID of Registrar
Registrar Name
Registrar Address, City, State/Province, Country 
Registrar Administrative Contacts
Registrar Technical Contacts
Registrar Billing Contacts
Registrar URL
Registrar Creation Date
Registrar Last Updated Date
Registrar Authorization Information
Registrar Account Information

Additionally, incremental data sets will contain notations of deletion of 
objects since the last incremental data set. These notations of object deletion 
are defined as follows:

Name of element	 Type of element
Del-domain	 domain:sNameType
Del-nameserver	 host:sNameType
Del-contact	 contact:sIDType
Del-registrar	 whoisdb:registrarIDType

Objects Contained in Full and Incremental Data Sets. Full data sets include one 
domain object for each Registered Name within the Registry TLD; and nameserver, 
contact, and registrar objects for each nameserver, contact, and registrar 
referred to in any domain object. Incremental data sets consist of:(a) those of 
the objects constituting a full data set that have been added or updated since 
the last incremental data set and (b)notations of deletion of any objects since 
the last incremental data set.

Format. Full and incremental data sets will be XML version 1.0, UTF-8 encoded 
documents. 

The XML Schema definition for the objects and their notations of deletion will 
be specified after discussions between ICANN and Registry Operator. The format 
will be based on the WHOIS provider format specified in Appendix P, Section 
C "Format", but will be augmented to include all data elements reasonably 
necessary to permit operation of the Registry Services for the Registry TLD in 
the event the escrow data is released. In the event, that ICANN and Registry 
Operator do not agree on the escrow format, ICANN shall reasonably specify that 
format.

Exhibit C-Escrow Transfer Process

Deposit Transfer Process. Registry Operator shall prepare and transfer the 
Deposit file by the following steps, in sequence:

1. The file(s) making up the Deposit will first be created according to the 
format specification. (See Exhibit B above, "Escrow Deposit Format 
Specification"). The resulting file shall be named according to the following 
format: "netSEQN", where "SEQN" is a four digit decimal number that is 
incremented as each report is prepared.

2. Next, the Deposit file will be processed by a program (provided by ICANN) 
that will verify that it complies with the format specification and contains 
reports of the same date/time (for a Full Deposit), count the number of objects 
of the various types in the Deposit, and append to the file a report of the 
program's results.

3. Registry Operator may optionally split the resulting file using the Unix 
SPLIT command (or equivalent) to produce files no less than 1 GB each (except 
the final file). If Deposit files are split, an MD5 file (produced with MD5SUM 
or equivalent) must be included with the resulting files to isolate errors.

4. The file(s) will then be encrypted and signed using a method mutually agreed 
by the Registry Operator and the Designated Data Recipient.

5. Transmission of Full Data Sets. Once prepared, full data sets will be 
provided either by the procedures for incremental data sets described in item C
(6) below or, at the option of either the Registry Operator or the Designated 
Recipient, by writing the full data set to DAT tape (or other media mutually 
agreed by Registry Operator and the Designated Recipient) and sending it to the 
Designated Recipient by expedited delivery service (such as FedEx or DHL). If 
sent by expedited delivery service, the full data set will be scheduled for 
arrival no later than the second calendar day following the day to which the 
full backup relates.

6. Transmission of Incremental Data Sets. To permit the transmission of 
incremental data sets, the Registry Operator will make them available for 
download by the Designated Recipient by Internet file transfer protocol. 
Incremental data sets will be made available for download no later than 2000 
UTC on the day to which they relate.

Exhibit D-Escrow Verification Procedures

Verification Procedures. Escrow Agent will verify the format and completeness 
of each Deposit by the following steps:

1. At the conclusion of the deposit window, all Deposit files will be moved to 
a not-publicly-accessible directory and the existence and size of each will be 
noted.

2. The file(s) will then be decrypted using a method mutually agreed by the 
Registry Operator and the Escrow agent.

3. If there are multiple files, they will be concatenated in sequence.

4. Escrow Agent will run a program on the Deposit file (without report) that 
will split it into its constituent reports (including the format report 
prepared by the Registry Operator and appended to the Deposit) check its 
format, count the number of objects of each type, and verify that the data set 
is internally consistent. This program will compare its results with the 
results of the Registry-generated format report, and will generate a Deposit 
format and completeness report.

5. The decrypted Deposit file will be encrypted by the program using a method 
mutually agreed by the Registry Operator and the Escrow agent.

6. The decrypted Deposit file will be destroyed to reduce likelihood of data 
loss to intruders in case of partial security failure.
Distribution Of Public Keys. Each of Registry Operator and Escrow Agent will 
distribute its public key to the other party (Registry Operator or Escrow 
Agent, as the case may be), confirm receipt by a method mutually agreed by both 
the parties.

Along with providing the information requested below, the applicant should include its own proposed versions of appendices C, D, E, O, P, Q, and R based on the current .NET registry agreement <http://www.icann.org/tlds/agreements/verisign/net-index.htm> which the applicant would be willing to have included in the subsequent .NET registry agreement. Applicants should ensure that their proposed versions of these appendices include any relevant subsequent updates to the RFCs referenced in these appendices. For example, RFC1035 as listed in Appendix C4 has been updated by RFC2845 and RFC3645, among other updates.

(a) Outline your technical capabilities. Provide a description of your technical capabilities, including information about key technical personnel (qualifications and experience), size of technical workforce and access to systems development tools. Outline any significant prior technical achievements.

WHY SENTAN
· Offers the strictest service level commitments to date for an ICANN 
accredited registry

· Highly secure and survivable infrastructure for protection against attacks

· Superior cost effective architecture supports significant capacity to meet 
high demand and allows for virtually unlimited horizontal scalability for SRS, 
WHOIS, and DNS

· Extensive use of Anycast to expand global coverage of .NET to 24 nameserver 
sites on 6 continents

· Nameserver sites which peer directly with Internet exchange points to enable 
the least amount of hops and reduced round trip time

· Staff of over 40 engineering, IT and operations personnel experienced in 
operating a domain name registry

· Engineering and operations tools customized specifically to meet the needs of 
a domain name registry

· Support of 2 parent companies with extensive domain name, security, and 
Internet experience - JPRS and NeuLevel

· Use of NeuLevel's proven SRS and DNS infrastructure architecture, and software

· A 3rd disaster recovery SRS site at JPRS provided site in Tokyo to enable the 
highest level of availability

· Fully integrated, best-of-breed network and systems monitoring capabilities

· 3 WHOIS sites including 2 in North America and 1 in Asia for global coverage 
and survivability

· Dynamic update for both DNS and WHOIS so the 2 are in synch

· Commitment to DNS and registry-related research and development to be 
performed by JPRS

· Improved IDN service utilizes a "1 language tag - 1 language table" solution 
to provide stricter adherence to local language requirements

· Deployment of an IRIS server in addition to WHOIS

1. INTRODUCTION
Sentan will leverage the technical capabilities and demonstrable record of 
performance of both parent companies to deliver the highest levels of service 
and appropriate technical innovation in operating the .NET registry for the 
Internet community. 

The successor .NET operator must possess outstanding technical qualifications 
and demonstrate extensive experience to ensure a seamless, stable transition, 
and ongoing stability and performance in the management of the .NET registry. 
The successor must have specific experience developing and managing systems to 
support all registry functions to provide the ICANN and the Internet community 
with the confidence that the domain will be properly managed and all registrars 
properly served. Sentan will leverage the technical capabilities and 
demonstrable record of performance of both parent companies, NeuLevel and JPRS, 
to deliver the highest levels of service and appropriate technical innovation 
in operating the .NET registry.

In order to support the rigorous technical demands of a gTLD such as .NET, the 
registry needs not only the right mix of people using the right tools, but also 
the ability to dynamically change in response to the evolving needs of the .NET 
gTLD. Our experience in TLD operations has allowed us to build an outstanding 
core team of professionals with the technical and organizational ability to 
support .NET in an exemplary manner. Over the same time period NeuLevel has 
developed a set of sound hiring practices that allow us to quickly acquire the 
right technical resources to respond to the diverse needs of supporting a gTLD. 
While NeuLevel as Sentan's primary technical operator will provide the 
technical back end support, Sentan will also rely on the technical expertise of 
JPRS, particularly in areas such as IDN and DNSSEC. 

Unmatched technical capabilities providing registry services 

While many organizations can talk about how they would manage .NET, NeuLevel 
has a history of applying our unmatched technical capabilities to provide 
registry services to .BIZ and .US. NeuLevel staff have operated the .BIZ gTLD 
and the .US ccTLD in a manner that has proven to be:

· Stable and Secure:  The .BIZ environment has stood against the never-ending 
and ever-changing attacks that have occur every day on the Internet.
· Scalable:  As the market has embraced .BIZ and .US, the supporting 
infrastructure has proven its elasticity in scaling up to meet and exceed the 
demands of the community.
· High Performance:  Our infrastructure has proven to continually function at a 
level of performance that fully supports the highly demanding environment of 
the international Internet community. 
· Standards-compliant: NeuLevel was an active participant in the IETF ProvReg 
WG to standardize EPP, was among the first to deploy the EPP 0.4 registrar 
interface, and was the first registry to implement the new EPP 1.0 standard in 
live production.
· Accountable:  Our TLD operations have consistently met or exceeded the most 
stringent set of SLAs in the registry community. 
· Equitable:  NeuLevel has ensured the functionality of and access to .BIZ has 
remained equivalent across all registrars regardless of size or geographic 
location. 

Both of Sentan's parent companies, JPRS and NeuLevel, also have formidable 
experience in some of the technologies that will be most crucial to the 
Internet's expansion and development in the near future. These include IDN, 
DNSSEC, and IPv6.

IDN   
· JPRS is a member of Joint Engineering Team (JET), which strongly influenced 
IDN standardization and service implementation. 
· JPRS joined IDN registration guidelines (JET guideline) documentation, which 
resulted in the publication of RFC3743, and are very active in ICANN IDN 
discussions. 
· NeuLevel implemented support for German-language international domain names 
(IDN) in October 2004, and in January 2005, launched support of .CN Chinese-
language domains in partnership with CNNIC. 
· NeuLevel is funding ISC's open source browser plug-in development, and has 
contracted the services of William Tan, a world-renowned IDN expert to assist 
them in their ongoing efforts to truly internationalize domain name 
registration. 

DNSSEC
· NeuLevel and JPRS actively participate in the DNSSEC Deployment Working 
Group. 
· NeuLevel completed a successful DNSSEC trial of the EPP extensions in 
November 2004. 
· As part of NeuLevel's registry staff, they employ Ed Lewis, a world-renowned 
DNS and DNSSEC expert who will lead NeuLevel's DNSSEC efforts
· JPRS completed a 3-year, $1M, government-funded DNSSEC research and 
development project.

IPv6 
· NeuLevel currently allows full IPv6 provisioning in the .BIZ SRS
· .JP IPv6 addresses of domain name servers are registered in IANA root servers 
and are accessible with IPv6, making the .JP domain the world's first Top Level 
Domain to fully support IPv6 technology.

2. SIZE OF TECHNICAL WORKFORCE / KEY TECHNICAL PERSONNEL
The NeuLevel technical team for the transition and operation of .NET is built 
upon the foundation of experience gained during the design, development, 
implementation, and ongoing operations of the .BIZ and .US TLDs. This 
exceptional pool of resources has proven to be intensely end user-focused and 
results-oriented. It embodies the Sentan commitment to deliver the highest 
levels of service and stability in an atmosphere of high security and 
confidentiality. The team includes over 40 individuals in the following groups: 
software development, quality assurance, information security, networking, 
systems administration, database administration, data warehousing, website 
management, financial systems, data center operations, and operations 
monitoring.

Our team is exceptionally experienced. For example, the software development 
staff averages over 15 years and the network administration team averages over 
14 years of professional/industry experience. While the information security, 
database administration, and system administration teams each average over 10 
years of professional/industry experience. Team members also hold a variety of 
professional certifications in disciplines such as networking, database 
administration, information security, and software development.

Our team contains seasoned individuals who exercise thought leadership in the 
industry. Team members have authored/co-authored IETF drafts, been inventors/co-
inventors on several patents, served as teachers in collegiate and professional 
education environments, presented at technical conferences, authored magazine 
articles, and served on a variety of national and international standards 
committees. While some organizations may be able to state similar 
qualifications for one or two members of a large group, we are proud to note 
that our experience is widely distributed within our organization, from staff 
to senior management.

While NeuLevel has an impressive pool of technical resources, we believe that 
excellence begins at the top and NeuLevel has a well-seasoned group at the top 
of the technical team: 

Richard K. Wilhelm, Sentan CTO/COO - Mr. Wilhelm will be responsible for the 
overall operations and technology of the Sentan registry. In this capacity, he 
will direct the NeuLevel team that provides technology operations services. As 
Vice President, Software Engineering of NeuLevel, he was a principal architect 
of the NeuLevel/NeuStar registry services platform during its construction for 
the .BIZ gTLD, directed its enhancement and deployment for the .US ccTLD 
transition, and has managed its ongoing technical operations. 

Thomas G. McGarry, Vice President, Strategic Technical Initiatives - Mr. 
McGarry has more than 20 years experience in network engineering, network and 
technology planning, as well as significant experience in the Internet and 
registry related technology. He represents NeuLevel on Internet and domain name 
space initiatives.

Jerry Chen Senior, Director, Enterprise Services - Mr. Chen is currently 
responsible for system/storage administration, Information Security and 
internal LAN/Help Desk. He has more than 19 years of experience in IT. 

Bob Strouts, Director, Information Technology and Services (IT&S) - Mr. Strouts 
manages the Network Engineering, Network Operations Center (NOC), Data Center, 
Network Management Systems (NMS) and Process. He has over 28 years of 
experience in IT.

Ed Lewis, Director and Member of Technical Staff - Mr. Lewis is responsible for 
strategic planning for Internet technologies.  Ed has over 20 years experience 
in computer and Internet technology and is a leading authority on DNS and 
DNSSEC.

Ronald H. Ferraro, Director, Systems Engineering  - Mr. Ferraro is responsible 
for managing the system development, testing and implementation of NeuLevel's 
registry services platform. He has over 12 years of management experience in a 
variety of technical areas, including microchip manufacturing.

Ben Apple, Senior Manager Information Security - Mr. Apple's background spans 
three decades as an active practitioner in information systems, IS Security and 
contingency planning.

Susumu Sano, CTO of JPRS, is responsible for operation of DNS, registry system 
of .JP and other systems.  Since the middle of 1980's, he has been engaged in 
research and deployment of the Internet.  He is a specialist of Internet 
security and DNS operation and security. He serves as Trustee of JPNIC and 
Director of JPCERT/CC.  He is also a Board Member of WIDE Project.

Yoshiro Yoneya joined JPNIC's IDN Task Force in 1999, and was chair of the TF 
from 2000 to 2002. He led JPNIC's opensource IDN toolkit (aka idnkit) 
development team and was a key participant in the IETF IDN WG with 
implementation experiences. He was also a core member of
Joint Engineering Team (JET) and deeply involved in development of JET IDN 
registration guideline.

Shinta Sato has been a chief architect of DNS and Registry Systems of .JP from 
1999. He led the implementation of IPv6 and Anycast technologies for JP DNS.

3. TECHNICAL ACHIEVEMENTS

NEULEVEL
NeuLevel's team of registry experts has been responsible for many noteworthy 
accomplishments. Of the 2 TLDs that NeuLevel administers, they support ongoing 
operations for over 150 registrars and manage over 2 million domain names for 
their customers.

In 2001, NeuLevel introduced .BIZ. NeuLevel was selected by ICANN among 40 
respondents as the result of the worldwide, competitive procurement for new 
gTLDs. Highlights of the .BIZ launch include:

· An internally developed registry platform that integrated SRS, DNS, and WHOIS.
· One of the first implementations of EPP.
· Over 70 registrars integrated at launch.
· Over 500,000 .BIZ domain name registrations during its first 45 days of 
availability.
· SRS performed flawlessly during the high volumes of the landrush period.

In 2002, the NeuLevel technical team transitioned the .US ccTLD from Verisign, 
opened the space to second-level registrations, and delivered improved 
administration of locality space operations. Highlights of the .US transition 
include:

· An aggressive transition timetable in which we transitioned responsibility 
for the .US legacy space from VeriSign, the incumbent operator, started the 
transition within 6 days of the contract award.

· Launched the 2nd-level space only 120 days after contract signature.

· Implemented all scheduled  transition deliverables on time, and in many 
instances early. Met all expectations for quality and service improvements.

· A successful real-time "landrush" process during which our SRS system handled 
approximately five million transactions in the first 24 hours.

In 2003, NeuLevel launched a first-of-its-kind Registry Gateway service with 
both CNNIC and TWNIC, opening ccTLD domain name registrations to .CN and .TW to 
all countries outside of China and Taiwan, respectively. This innovative system 
allows registrars to connect seamlessly with a ccTLD registry using a standard 
EPP interface and allows its registrar to leverage an existing business 
relationship, including customer support.

In 2004, the NeuLevel technical team rolled out a set of significant upgrades 
to its registry services platform. These include:

· Support for German-language IDNs in October 2004;
· The first registry to launch production deployment of the EPP 1.0 IETF 
standard (Oct. 2004);
· Full provisioning of IPv6 through the SRS in October 2004
· Performance improvements to dynamic DNS update in December 2004

In January 2005, the NeuLevel ccTLD registry gateway launched support for 
Chinese-language IDNs in cooperation with CNNIC. 

JPRS
In 2001, JPRS started its business of .JP domain name registration. Highlights 
of the activities include:

· New transaction-based SRS started to provide registration service
· Initiated a testbed for IDN resolution
· Launched a service for browsing Japanese JP domain names with a plug-in to 
Microsoft Internet Explorer 

In 2002, JPRS focused on the security of .JP domain name registration and DNS 
service among various engineering activities. Highlights of the activities 
include:

· Articulated access authorization for all the SRS operations
· Conducted a research project to solve failure problems caused by erroneous 
DNS setup
· Enhanced information protection in communicating with registrars through by 
PGP encryption

In 2003, JPRS enhanced the serviceability of .JP domain name registration 
services. Highlights of the activities include:

· Launched a Japanese .JP domain name registration and resolution service 
compliant with IETF RFCs and ICANN guidelines.
· Initiated full-scale dispersed operation of JP DNS in Tokyo and Osaka by 
adding Osaka as a DNS site.
· Developed and opened a web page with Japanese JP domain name resolution 
function for mobile Internet services

In 2004, JPRS made remarkable achievements in improving environment to adopt 
Japanese JP domain name, and in ensuring serviceability of JP DNS. Highlights 
of the activities include:

· Commenced "Nihongo (Japanese) JP Navi" service that resolved 8-bit DNS query
· Implemented IP Anycast Technology in JP DNS
· JP became one of the first TLDs whose IPv6 addresses of TLD nameservers are 
registered in the root zone file

4. SYSTEM DEVELOPMENT TOOLS
NeuLevel has demonstrated an ongoing commitment to employing best-of-breed 
tools for application development, infrastructure management, operations 
management, and information security.

The need for ongoing innovation in the services and functionality of a gTLD 
requires that the operator take a creative approach in the use of Development 
Tools and Languages. The following are examples of the tools NeuLevel has 
successfully applied to the support of TLD operations. 

· CASE Tools:  Purify, Insure++, Rational Rose, Make/ANT, TOAD, XMLSpy
· Development Environments:  JBuilder, Eclips, Together/J
· Security: OpenSSL, JSSE, RADIUS
· Web Tools: Apache, Tomcat, STRUTS, SOAP/Web Service (Axis), BEA WebLogic, 
Java Servlets, Java Server Pages, Cold Fusion, CGI-script, XML & XSL
· Languages:  Java, C, C++, PL/SQL, Perl
· Middleware:  IBM MQSeries, Tibco SmartSockets
· Testing:  Mercury Interactive TestDirector, JUnit
· Source Code Control:  CVS

The network required to support the .NET gTLD is a complex and demanding 
environment and as such demands constant management and monitoring. Our group 
professionals have at their disposal an extensive tool chest of network 
management and monitoring tools such as:

· Micromuse NetCool
· Concord eHealth
· TripWire
· HP OpenView
· CiscoWorks
· SysEDGE
· IBM Director
· Red Hat Management System
· EMC ECC Management System

The security and stability of any of the gTLD environments is critical to the 
continued functionality of the Internet. Therefore, we have expended a great 
deal of time and effort to assemble a sound set of information security tools 
for our information security professionals.

· Checkpoint Enterprise Smart Center
· CyberGuard Global Command Center
· Nokia Horizon Manager 
· Juniper Netscreen-Security Manager
· NFR Enterprise Console
· Leading open source tools including: Nmap, Nessus, and Ethereal

Our technical team is constantly engaged in evolving and improving its tool 
chest to take advantage of the ongoing improvements in systems development 
tools provided by vendors and the open source community.

(b) Technical plan and capabilities for the proposed registry operations. In certain sections of the web-based form, applicants are permitted to make non-textual submissions together with, and as part of, their application (e.g., graphs, flowcharts, models and diagrams). Present a technical plan and capabilities outline for the proposed registry operations. The technical plan should address the following factors:

(i) General description of proposed facilities and systems. Describe all system locations. Identify the specific types of systems being used, their capacity and interoperability, general availability and level of security of technical environment. Describe in appropriate detail buildings, hardware, software systems, environmental equipment and Internet connectivity.

WHY SENTAN
· Global presence in secure data center facilities

· 24 nameserver sites located on 6 continents

· 16 nameserver sites that peer directly with Internet Exchange Points

· 3 SRS locations including a disaster recovery SRS in Japan

· Proven secure registry systems and software for registration and resolution 
of domain names

· Highly scalable systems and architecture for the SRS, WHOIS, and DNS

· Significant Internet bandwidth to easily support high volumes

1. SYSTEM LOCATIONS
This section focuses on the registry facilities and systems. For a discussion 
of the administrative facilities and systems please refer to Part 2:3.b.iii. 

Internet registry facilities are required to support the three different 
functions of a registry; the DNS for resolution, the SRS for registrations, and 
the WHOIS to facilitate maintenance. This section details the systems for those 
three functions, including: software, hardware, security, and capacity.

In the Sentan architecture, the WHOIS servers are co-located at the SRS sites. 
The DNS servers are also co-located at each of the SRS sites as well as in many 
other remote sites. Both types of facilities require a high level of physical 
security and environmental support. This section presents a discussion of the 
SRS as well as DNS and WHOIS facilities; including their Internet connectivity, 
capacities, security, etc. 

SRS locations are:
· Primary SRS - Sterling, Virginia, USA
· Secondary SRS - Charlotte, North Carolina, USA
· Disaster Recovery SRS - Tokyo, Japan

Nameserver sites are located in:
Africa
· Johannesburg, South Africa
· Nairobi, Kenya

Asia
· Hong Kong
· Osaka, Japan
· Seoul, South Korea
· Singapore 1
· Singapore 2
· Singapore 3
· Tokyo, Japan

Australia/Oceania
· Wellington, New Zealand

Europe
· Amsterdam, the Netherlands
· London, UK 1
· London, UK 2
· Paris, France

North America
· Ashburn, Virginia, USA
· Charlotte, North Carolina, USA
· Los Angeles, California, USA
· Miami, Florida, USA
· New York City, New York, USA
· Palo Alto, California, USA
· San Jose, California, USA
· Seattle, Washington, USA
· Sterling, Virginia, USA

South America
· Sao Paolo, Brazil


2 SYSTEMS AND SOFTWARE

2.1 SRS SYSTEMS, SOFTWARE/HARDWARE, AND INTEROPERABILITY
The systems and software that the registry operates on are a critical element 
to providing a high quality of service. If the systems are of poor quality, if 
they are difficult to maintain and operate, or if the registry personnel are 
unfamiliar with them, the registry will be prone to outages. 

NeuLevel, the registry operator for Sentan, has been successfully operating a 
domain name registry for over 3 years; supporting over 150 registrars. They've 
built the infrastructure using best in breed systems and software. NeuLevel has 
also developed much of the application software that performs registry-specific 
operations and therefore is very familiar with its operations. 

They systems and software described in this section have interoperated with 
each other, as necessary, for 3 years. The SRS interoperates with the 
registrars' systems, the nameservers, and WHOIS servers to create a seamless 
registry infrastructure.

The architecture for both the SRS and the nameservers is highly scalable and 
can therefore provide the same high level of availability as volumes increase. 
The architecture combines load balancing technology and scalable server 
technology to provide a cost effective and efficient method for scaling (See 
Exhibit 5.b.i-1 for a table depicting systems and software used by SRS and 
WHOIS).

2.1.1 SRS AND WHOIS SYSTEM SECURITY
The WHOIS and SRS systems are protected on the front end and the backend by 
multiple layers of diverse high availability firewalls and boundary devices 
(switches and routers) that make use of detailed Access Control Lists (ACL). 
The systems themselves are hardened as per best practices for a bastion server. 
The core applications of The WHOIS and SRS environment are protected against 
tampering by an application (Tripwire) that monitors all core aspects of the 
environment. Tripwire is capable of alerting on unauthorized change and even 
executing a rollback to the approved configuration if a change is detected. The 
health of the WHOIS and SRS environment is monitored 7x24x365 by a centralized 
Network Operations Center (NOC). 

The boundary device (Cisco 3750 switch) passes WHOIS traffic to the front-end 
firewall. The firewall tests the traffic against a set of rules to ensure that 
only good traffic gets to the next level of the environment. Traffic approved 
by the firewall is passed to a Cisco CSS 11506 load balancer that is shared 
with the SRS traffic. The load balancer manages the allocation of traffic to 
the WHOIS server farm. The response to the WHOIS transaction is returned via 
the reverse of the route.

The same boundary device (Cisco 3750 switch) that is involved with a WHOIS 
transaction passes SRS traffic to the front-end firewall. The firewall tests 
the traffic against a set of rules to ensure that only good traffic gets to the 
next level of the environment. Traffic approved by the firewall is passed to a 
Cisco CSS 11506 load balancer that is shared with the WHOIS traffic. The load 
balancer manages the allocation of traffic to the SRS application servers. The 
SRS application servers communicate with a Cisco 7609 Router via the firewall 
module. The 7609 firewall passes APP requests to the APP servers via the Load 
balancer module. SRS transactions return via the reverse of the path.

2.2 NAMESERVER SYSTEMS AND SOFTWARE
Systems and software can be susceptible to attacks that are focused on known 
system or software vulnerabilities. For example, there could be a specific 
release of an operating system that has a known vulnerability. Hackers could 
search for those systems on the Internet and, once found, attack the 
vulnerability bringing the system down. If all nameservers for a specific 
domain used this release, the attacker could take down all of the nameservers 
and therefore, the entire domain served by those nameservers. 

The .NET nameserver architecture operates on diverse hardware, operating 
systems, and application software. The two versions of application software 
used are modified versions of BIND 8 and BIND 9. NeuLevel has started with the 
open source version of BIND and modified it significantly to make it more 
consistent with the needs of a TLD registry. Modifications include reducing the 
overhead, improving performance, and integrating performance statistic 
collection capabilities. Because BIND is the baseline application software, it 
is very simple to make it compatible with multiple versions of hardware and 
operating systems. 

The modified versions of BIND 8 and BIND 9 can be hosted on either of the 
following nameserver configurations.  For transaction capacity see Part 
2:5.b.xiv.

Configuration 1	
Hardware: IBM HS blade	
O/S: Redhat ES3.0	
Capacity/Avail: 2 CPU/2.5GB RAM (expandable to 8GB)
--------------------------------------------------

Configuration 2
Hardware: IBM x335
O/S: Redhat ES 3.0	
Capacity/Avail: 2 CPU/2.5GB RAM (expandable to 8GB)
--------------------------------------------------

Configuration 3
Hardware: Sun B100 blade
O/S: Solaris 9
Capacity/Avail: 1 CPU/2G RAM
-------------------------------------------------- 

2.2.1 NAMESERVER SYSTEM SECURITY
The nameserver system is protected by the implementation of a router that makes 
use of stringent ACL to allow only DNS packets access to the nameserver. The 
systems themselves are protected by the implementation of a hardened OS, (see 
Part 2:6.c for hardening details). On the internal facing side the nameserver 
systems are protected by a set of high availability firewalls and a boundary 
device (routers and switches) that make use of detailed ACLs. 

As with the SRS, system security, the critical core of the nameserver 
environment is protected against tampering by the Tripwire application. 

3. BUILDING FACILITIES

3.1 SRS BUILDING FACILITIES
At a high level, the .NET SRS performs the following functions:
· Provides the registrar interface to the registry database;
· Maintains the authoritative .NET database; and
· Updates DNS
· Updates WHOIS

The SRS is a more complex data center than the DNS sites. It requires onsite 
personnel to manage and maintain the systems and databases. Those same 
personnel work with registrars in the event of maintenance issues. Backups and 
escrow are performed at the SRS. The primary SRS is hosted in a NeuLevel data 
center, as opposed to being hosted in a hosting facility or outsourced to a 
third party. 

Because the SRS is such a complex system, there is typically only one SRS site. 
In addition to the primary SRS site major registries provide a failover SRS 
site in a geographically separate location - a secondary SRS site. The 
secondary SRS site is used if there is a major outage at the primary site. In 
the event of a failover of the registry the registrar connections will be 
transferred to the secondary site. The secondary site will then handle the 
transactions from the registrars and update the .NET database as well as 
dynamic updates of DNS WHOIS. Once the outage at the primary site is resolved 
and the platform is stable the registrar connections will be transferred back 
to the primary SRS. The secondary site can also be used if there is planned 
maintenance at the primary site. 

The disaster recovery SRS will be able to ensure a high level of availability 
in the event of a disaster. 

SRS locations are:
· Primary SRS - Sterling, Virginia, USA
· Secondary SRS - Charlotte, North Carolina, USA
· Disaster Recovery SRS - Tokyo, Japan

Each of these facilities shares similar environmental and security attributes 
required to meet stringent support and service level requirements. NeuLevel's 
SRS, WHOIS, and DNS data centers in Sterling, Charlotte, and Tokyo are operated 
and maintained on a full-time basis by dedicated NeuLevel personnel. The 
Sterling site also includes customer service, sales, and operations staff 
responsible for the management and day-to-day operations of the registry 
system. (For a detailed table see Exhibit 5.b.i-2)


3.1.1 SRS BUILDING SECURITY
NeuLevel vigilantly controls physical access to its facilities. Physical 
security mechanisms include security guards, closed circuit TV surveillance 
video cameras, and intrusion detection systems. Our NOC monitors access to all 
locations on a 24x7x365 basis.

At the SRS data center locations, employees must present badges to gain 
entrance and wear their badges at all times while in the facility. All visitors 
must register to gain entrance to any NeuLevel facility. Visitors must display 
visitor badges at all times while they are in the facility, and must be 
escorted when in the facility. Visitor registration records are maintained for 
a period of one year. 

Security personnel are on duty 24/7/365 to monitor closed-circuit television 
cameras placed strategically throughout the facilities. Security personnel are 
stationed at building-access points throughout normal working hours; at other 
times, employees must use authorized electronic key cards to gain access to the 
buildings. Further, any room housing sensitive data or equipment is equipped 
with a self-closing door that can be opened only upon activation of a hand 
geometry reader. Senior facility managers establish the rights of employees to 
access individual rooms, and ensure that each reader is programmed to pass only 
authorized individuals. The hand geometry readers compile and maintain an 
access record.

3.1.2 SRS INTERNET CONNECTIVITY
NeuLevel has deployed two ISP links from 2 different ISPs at the primary and 
secondary SRS data center to serve registry needs. Each link is an OC3 and has 
available capacity of 155MB for a total of 310MB at each data center. 

3.2 DNS BUILDING FACILITIES
The DNS has been designed so that there can be many nameserver sites. Each 
nameserver site has a duplicate copy of the zone file. It is common to host 
nameserver sites in hosting facilities. Hosting facilities are data center 
locations that are in the business of hosting other companies' systems. The 
hosting facility will provide access to Internet connectivity, power and back-
up power, fire suppression, facility security and monitoring, and HVAC. 

A hosting company however does not provide systems and applications 
engineering, nor maintenance and monitoring for the nameservers. In a hosting 
solution, the registry performs those functions themselves. 

NeuLevel has chosen to use multiple hosting company sites to create a 
constellation of 24 nameserver sites around the world. All but two of these 
locations are in the process of being implemented to support the .BIZ domain. 
They have ensured that all of these sites have the highest level of security 
and environmental equipment required for the secure stable operations of 
the .NET domain. 

The 24 additional nameserver hosting sites are maintained in stable and secure 
co-location facilities. All nameserver equipment in each of our 24 co-located 
nameserver sites is owned, engineered, and maintained by NeuLevel personnel.

Nameserver Facilities (All)

* Function: DNS
* Internet connectivity:	100MB - 2GB
* UPS: Yes
* Backup Generator: Yes
* Dedicated HVAC: Yes, N+1 redundancy
* Fire Detection: High sensitivity smoke detectors (HSSD) located under raised 
floor and in ceiling
* Fire Suppression: FM200 and dry-pipe pre-action sprinkler system
* Facilities Security:  24x7 onsite security personnel; electronic badge 
readers; closed-circuit television cameras; biometric scanners for secure 
access locations
* Facilities Monitoring:	Alarm monitoring system reports on electrical, 
mechanical, temperature, humidity, fire, security, access control and customer 
cabinet alarms. Also monitors power consumption of customer cabinets

We have deployed 24 sites distributed in key locations around the world. 
Sixteen of these sites are located in Internet exchange points. An Internet 
exchange point is a Layer 2 physical network facility where three or more 
Internet service providers (ISPs) interconnect for the purposes of exchanging 
traffic. This is called peering. If ISP A does not peer with ISP B then traffic 
between these two ISPs must go through another ISP that they do peer with. This 
adds another hop in the route. The more hops a packet takes the more likely 
that there will be lost packets and increased latency. ISPs peer with each 
other at Internet exchange points to improve performance for their customers. 

The nameservers located at Internet exchange points peer directly with all of 
the ISPs in that exchange point. That is, the nameservers have 2 100MB (or 2 
1GB) connections directly into the exchange. This means that any ISP located in 
these exchanges has direct access to the .NET zone file and do not have to 
transit another ISPs network. .NET queries will be completed with a minimum 
number of hops. This architecture provides the highest level of service 
possible to the most ISPs and their customers, the Internet users.

3.2.1 NAMESERVER BUILDING SECURITY
For co-located nameserver sites, access to the .NET equipment is as strictly 
enforced as it is at NeuLevel's SRS data centers. The co-location facility 
provider is given a limited list of authorized individuals granted access to 
the .NET facilities. NeuLevel employees are responsible for accepting or 
denying access. Visitors sign in and must wear a badge while on the premises. 
They are escorted everywhere once in the location. Security personnel are 
located at each entrance point to the building and individuals must present the 
proper credentials to gain access. Each location is monitored on a 24/7/365 
basis by the facility provider's NOC. In the event of an alarm associated with 
the equipment, the facility provider's NOC will contact NeuLevel's NOC to seek 
further direction related to the event. 

3.2.2 NAMESERVER INTERNET CONNECTIVITY
We have provisioned a significant amount of bandwidth at the nameserver sites 
in anticipation of high volumes. With regard to bandwidth we have 4 different 
configurations, the Table below provides the bandwidth for each configuration. 

Configuration 1: Co-located at primary and secondary data centers
Sites: 2
Bandwidth: 310MB
Type of Bandwidth: Transit Link
-------------------------------------------------

Configuration 2: Co-located in a hosting facility
Sites: 6 
Bandwidth: 100MB
Type of Bandwidth: Transit Link
-------------------------------------------------

Configuration 3: Co-located with an IXP and peer directly over 2 100MB ports
Sites: 10 
Bandwidth: 200MB
Type of Bandwidth: IXP connection
-------------------------------------------------

Configuration 4: Co-located with an IXP and peer directly over 2 1GB ports
Sites: 2 
Bandwidth: 2GB
Type of Bandwidth: IXP connection



(ii) Stability of resolution and performance capabilities, including: response times and packet loss targets; availability of authoritative name servers; processes, tools and automated monitoring to ensure accuracy of zone data for resolution; diversity of DNS infrastructure; diversity and redundancy of network and DNS infrastructure to handle bandwidth congestion and network failures of ISPs and host providers.

WHY SENTAN
· Committed DNS availability of 100%

· 24 nameserver sites for global coverage, geographic diversity, and capacity

· 16 nameserver sites with direct peering to an Internet Exchange Point for 
optimal service to ISPs and Internet users

· 72+ nameservers for capacity

· Significant redundancy and diversity for stability via: Unicast and Anycast 
configuration; optimized and customized BIND 8 and 9; IBM/Linux and Sun/Solaris 
servers; multiple bandwidth providers; mix of transit links and direct peering 
with IXP

· Cross Network Nameserver Performance (CNNP) test to measure response time and 
packet loss performed by third party

1. INTRODUCTION
The Internet is available 24 hours a day, 365 days a year. And therefore, the 
resolution capabilities of a domain name registry must also be available 24 
hours a day, 365 days a year. Internet users expect that they will be able to 
use a domain name to access an application on the Internet, like a web page or 
an email, at any time of day, any day of the year. Further, the Internet is 
increasingly being used for real-time applications like voice, video, and 
instant messaging. Not only do users expect the name to resolve, they expect it 
to resolve quickly. The vast majority of companies and governments in the world 
rely on the Internet for their day-to-day operations or in some cases they rely 
on the Internet for their very existence. These companies rely on the ability 
of their employees or their users to be able to resolve domain names reliably 
and rapidly. Therefore, one of the most critical components of any TLD 
registry, particularly one such as .NET, is the stability and performance of 
the DNS (nameserver) operations.

In response, Sentan's technical operator, NeuLevel, will deploy a new 
nameserver infrastructure leveraging the existing 6 site locations and adding 
18 additional sites.  These 24 sites will utilize Anycast technology with 16 
sites with direct peering to Internet exchanges to provide significant capacity 
and diversity. Sentan's service will be consistently fast and provide accurate 
resolution for .NET users.

Performance stability of the DNS constellation is just as important as the 
sheer capability to bear the load. The asynchronous nature of the Internet's 
other protocols, e.g., HTTP, is adversely affected by instabilities, usually 
evidenced by varying response times. When instability occurs, Internet 
protocols go through a great effort to readjust to the new environmental 
conditions. To remove the need to expend this effort, achieving a stable DNS is 
one very important step.

The way in which the Sentan solution achieves consistent performance of the DNS 
constellation is addressed in this section. The main ingredients to 
understanding and meeting the challenge include: 

· A design in harmony with the protocol;
· Diversity in architecture;
· Redundancy of components and service paths; and
· Monitoring the "user experience".

2. A DESIGN IN HARMONY WITH DNS
Achieving a stable DNS requires careful design. At the very core of the DNS, is 
a fast and efficient, but unreliable, transport protocol called the User 
Datagram Protocol (UDP). This design choice dates back to the 1980's and is 
based on the observation that "if all goes well, this is the fastest means to 
an answer. If there's a problem, don't try to recover, just try, try again."  
Often times, all does go well, but there is no guarantee that a packet sent by 
either a resolver or a nameserver will ever reach the intended destination nor 
is feedback given. With UDP as a transport protocol, stability in DNS has to be 
achieved by design.
 
Fortunately, the designers of the DNS protocol understood these concepts and 
designed for the ability to tolerate an unpredictable base protocol. The DNS 
protocol features 3 design concepts:

1. Retrying queries in the absence of a response;
2. Trying alternate sources in the absence of a response; and
3. Avoiding the temptation to add reliability and predictability to UDP.

In addition to UDP's unreliable nature, another consideration when addressing a 
stable DNS is the non-deterministic load. Query demand will rise and fall 
without notice. UDP does not help with this; and without feedback there is no 
congestion control. Given the DNS protocol's designed-in error tolerance and 
the non-deterministic load, a DNS constellation best suited to the protocol 
should have the following features:

1. Multiple nameservers, for capacity and proximity;
2. Multiple identifiable nameservers, to retry when responses don't arrive; and
3. Overprovisioned to handle non-deterministic load.

One key tool in achieving the above goals is a routing technique 
called "Anycast."  Anycast has quickly become a proven technology where 
multiple, distributed nameservers can answer requests sent to a single address. 
Sentan will take advantage of this capability by deploying 3 separate Anycast 
clouds along with 6 Unicast nameserver sites.

Sentan's utilization of NeuLevel's DNS constellation will meet the above 3 
goals--multiple nameservers, adequate number of identifiable servers, and 
overprovisioning--by building on NeuLevel's current DNS constellation and the 
addition of Anycast routing. In designing the Anycast network, Sentan received 
considerable consultation from Bill Woodcock and Steve Gibbard--world-renowned 
experts on DNS in an Anycast environment--and input from JPRS about the 
operational experience of Anycast for .JP DNS. Specifically, Sentan's DNS 
Constellation:

· Will have 24 nameservers sites (see Part 2:5.b.vi). All continents, except 
Antartica, will have .NET nameservers. The goal of deploying to all of these 
sites is to bring .NET closer to more Internet users. The goal of deploying 
many geographically dispersed nameserver sites had the double benefit of 
provisioning capacity that far exceeds the estimated demand necessary.

· Will have 9 unique nameserver addresses. The 9 nameserver addresses act as a 
front for the 24 sites, allowing resolvers some choice in which nameserver is 
used, without burdening the resolvers with having to know about all 24 sites 
individually. The number of 9 includes 6 Unicast sites, which resolvers address 
specifically, and 18 Anycast sites, which resolvers are directed to by Internet 
routing. Diversity of routing protocol provides additional protection against 
systemic outages that may affect one type of site but not the other.

· Is "overprovisioned", having capacity 5 times greater than the estimated .NET 
traffic load (see Part 2:5.b.xiv). This will accommodate the non-deterministic 
load. Four Anycast sites will be held in reserve in the event that additional 
capacity is needed quickly. The 4 sites are in Europe, Asia, North America West 
Coast, and North America East Coast, where there is a corresponding Unicast 
presence. These sites will be treated as operational, but not have routes to 
them advertised (BGP will be turned off).
 
· Will provide resolvers the capacity and choices they need to do their job. 
While each element of the DNS constellation will be monitored and administered 
around the clock (addressed later), if there is a localized disruption of 
service, resolvers will be able to obtain answers by choosing a different 
nameserver address.

3. DIVERSITY AND REDUNDANCY TO COUNTER SYSTEMIC FAILURES
Sentan's DNS constellation of 9 distinct nameservers addresses will be 
identified by single letter names, A through I, and will have 4 configurations. 
Reliance upon a non-diversified approach to implementing a DNS constellation 
has a few alluring aspects--efficient in staff operations, lower training and 
troubleshooting costs, and the operator of the constellation may have more 
leverage with suppliers, such as ISP's. But these are all economic advantages--
siren's calls. Having a single approach to implementing a DNS constellation 
unduly introduces greater vulnerabilities to systemic faults, e.g., routing 
problems in an ISP, outright business failure of a supplier, or a security bug 
in commonly used software.

Sentan's proposed DNS constellation for .NET features diversity in practically 
every way. Nameservers are situated in different places and in different ways 
with respect to the Internet. Multiple ISPs are used, as well as facilities and 
utilities (covered in the previous section). Within a nameserver site, 
diversity is in the selection of load balancing approaches (dedicated servers 
or router-based solutions), nameserver hardware (Sun and IBM), nameserver 
operating system (Solaris and Red Hat Linux), and the nameserver implementation 
(BIND 8 and BIND 9).

3.1 DNS SOFTWARE DIVERSITY
NeuLevel has selected 2 different versions of DNS software as protection 
against a weakness that may affect one or the other. Common to all sites is the 
presence of BIND 8 and BIND 9. Although both BIND 8 and BIND 9 have been 
produced and are distributed by the Internet Systems Consortium, the two are 
diverse in their build. The development of BIND 9 was not based on BIND 8 code--
it was developed from scratch.
 
NeuLevel chose a combination of BIND 8 and BIND 9 because of its familiarity 
with the code. In 2001, NeuLevel modified BIND 8 by optimizing its performance, 
improving security, and integrating relevant performance statistics tools. 
Since 2004, this optimized version of BIND 8 has been operating both the .BIZ 
and .US TLDs. BIND 8 has been proven to be able to handle large zone file as it 
supported .COM and .NET until at least Q4 2001 when the zone files were over 
23M and 4M domains respectively.
 
In late 2004, NeuLevel embarked on an effort to add DNS software diversity to 
its nameservers. They decided to use BIND 9 as a baseline since it was a 
significantly different code base than BIND 8 and preliminary testing showed 
its performance to be sufficient for .BIZ and .US, both in terms of 
transactions and memory. BIND 9 has been added to the master servers for .BIZ 
and .US and is in the process of being implemented in slave servers in the 
remote nameserver sites.
 
During the BIND development process, NeuLevel tested BIND 8 with volumes 
equivalent to that of the .NET zone file. They discovered that dynamic update 
(IXFR), while sufficient for production use, did not perform to their level of 
satisfaction. In response, NeuLevel contracted with Olafur Gudmundsson, a well-
known DNS expert who has co-chaired the IETF's DNS Extensions Working Group for 
6 years, to work with NeuLevel engineers to improve upon its performance. As a 
result, BIND 8 with satisfactory performance is achieved.

3.2 NAMESERVER ARCHITECTURE DIVERSITY
Sites A and B are designed for high availability through the use of redundant 
components throughout the sites' architectures. The 2 sites are similar to each 
other, with the main difference being that the NOC is co-located with site A. 
Sites A and B are served by 2 ISPs each, with each connection terminating in a 
different router. At each site, the 2 routers (CISCO 7206) are each connected 
to 2, 1 Gbps LAN switches (CISCO 3750), which are in turn connected to 2 load 
balancers (F543400). Each load balancer is in turn connected to 4 active and 1 
reserve IBM DNS servers. In addition to the DNS hardware, there is hardware to 
support a management VPN and modem connections.

Sites C-F are located within co-location facilities, having one connection 
terminating in a CISCO 7206 router. The ISPs for these sites are QWEST (C), 
Colt (D), and SingTel (E and F). The router is connected to a CISCO 11150 load 
balancer in front of 4 active and 1 reserve IBM 336 servers on a 100Mbps CISCO 
3550-24 switch. The router is also connected to a firewall for VPN support, 
reaching a CISCO 2610XM console server and the DNS servers to deliver updates. 
A modem is also installed for access to the console server if there is no 
Internet connectivity available.
 
Sites G and H are non-overlapping Anycast server groups, each containing 8 
sites. Each of these sites is directly connected to an Internet exchange core 
network by redundant routers with 100Mbps interfaces. The routers have peering 
relationships with the other Internet exchange participants. The routers each 
connect to 2 Sun servers. The routers also feature dedicated transit links for 
VPN access to the NeuLevel network operations center, allowing the Internet 
exchange to be bypassed for maintenance purposes. The DNS servers run a VPN 
client, and respond to the same IP address(es), both IPv4 and IPv6, within the 
Anycast group. Each server has unique addresses used for management within the 
VPN and will use a unique address to perform cross-network monitoring. The 2 
routers perform load balancing of the 2 servers via the DNS query source 
address. With this design, there is no single point of failure at these sites.
Site I consists of 2 locations within a third Anycast cloud. Each location of 
Site I will have a CISCO 7206 router, a F5 load balancer, 4 active nameservers, 
a reserve nameserver, and a firewall to terminate the VPN.

3.3 REDUNDANCY OF COMPONENTS AND SERVICE PATHS
Having a single component fail is different from a systemic fault, a single 
failure is a random fault. Random faults are managed through the ability of the 
constellation to route traffic around the fallen component to the remaining 
working components. This automatic fix is designed to bear the load, without 
notice, while repairs are made to the fallen component.

The DNS constellation's varying site architectures, as described briefly 
before, feature redundancy in many ways. Two of the nameserver sites, named A 
and B, are high availability with no single point of failure in the 
architecture. Sites C, D, E, and F are redundant to each other, if there is a 
fault in one of the sites, the remaining sites in the constellation will have 
enough capacity to pick up the extra workload. In addition each of these sites 
have 4 active and 1 reserve nameserver. In the event of a server outage, the 
reserve will be placed in service while the faulty nameserver is being restored.
The Anycast sites addressed by the names G and H feature redundancy in the 
components and at the site level. Each site has dual servers and dual routers. 
If an Anycast site fails, it can be withdrawn from the routing table and the 
queries that would have landed there will find another Anycast site. The 
Anycast sites addressed by the name I have site redundancy, if one half 
experiences a fault, traffic will be routed to the other location.

4. TOOLS AND AUTOMATED MONITORING
In addition to system health monitoring (see Part 2:5.b.xvi), NeuLevel performs 
2 specific activities to measure the .NET user experience. The first activity, 
the Zone File Accuracy Audit, measures the accuracy of the answers; verifying 
that the DNS responses correspond with the data in the registry. The second 
activity, a Cross-Network Nameserver Performance (CNNP) test, measures the rate 
of queries and responses for response time and packet loss.

Accuracy of the DNS will be measured in 2 ways. To ensure that each component 
is updated and synchronized, NeuLevel will actively monitor the DNS 
constellation. During the update process, each incremental zone update is 
assigned a new DNS zone serial number. The master and slave servers are 
constantly validating the serial number with each other to ensure that each 
component is updated within a reasonable amount of time and that the updates 
are synchronized.

4.1 ZONE FILE ACCURACY AUDIT
A zone file accuracy audit system will be deployed for the .NET registry. It 
will compare data in the zone file to data stored in the SRS at the data level, 
to ensure that the SRS and the DNS slaves are in sync. This should be standard 
operating procedure for all registries. During the zone file accuracy audit, 
the system will:  receive updates from the master server; perform a query on 
the name to the .NET zone file; query the .NET SRS database for the same name; 
compare the data received from the zone file with that received from the DB; 
and generate an alarm if there is a mismatch. This process will run constantly 
and will include both recently added or modified names, as well as random names 
selected from the SRS DB.
 
4.2 PERFORMANCE MONITORING - CNNP TEST
Most of ICANN's registry contracts include a requirement for a CNNP test. The 
test is intended to monitor round trip time and packet loss for a DNS query, in 
essence the "user experience". Currently, ICANN performs this test. In the 
interest of relieving ICANN of this obligation, Sentan will hire (and pay for) 
a 3rd party monitoring company, such as Keynote, to perform this test on behalf 
of ICANN. NeuLevel has successfully used this service to monitor other 
applications. The CNNP test will serve as an additional performance monitoring 
and will be reported to ICANN monthly as part of Sentan's SLA reporting. 
The measurements will be conducted by sending strings of DNS request packets 
from each of 4 measuring locations to each of the .NET nameservers and 
observing the response time and packet loss. The measuring locations will be on 
the North America's East and West Coasts, Asia, and Europe.

Each string of request packets will consist of 100 DNS queries at 10-second 
intervals requesting nameserver records for arbitrarily selected .NET second-
level domains, preselected to ensure that the names exist in the Registry TLD 
and are resolvable. The packet loss (i.e., the percentage of response packets 
not received) and the roundtrip time for response packets received will be 
collected. The goals for response time are less than 300ms and for packet loss 
are less than 10%.

5. RESPONSE TIME AND PACKET LOSS TARGETS
· Measured via CNNP Tests (paid for by Sentan) run by a 3rd party
· Goals are less than 300ms round trip times and less than 10% packet loss
· Results will be provided to ICANN monthly

6. AVAILABILITY OF AUTHORITATIVE NAMESERVERS
· Committed DNS availability of 100%
· 24 nameserver sites
· 72 nameservers
· Multiple nameservers, significant capacity
· Diverse site architecture and connections to the Internet
· Redundant components, reserved and spare components
· Maintenance performed by replacing in-service components with reserves

7. PROCESSES, TOOLS, AND AUTOMATED PROCESSING TO ENSURE ACCURACY OF ZONE DATA 
FOR RESOLUTION
· CNNP test
· Serial Number validation
· Zone file accuracy audit process

8. DIVERSITY OF DNS INFRASTRUCTURE
· Optimized and customized BIND 8 and BIND 9
· Solaris and Red Hat Linux
· Sun and IBM Servers
· 24 sites, with 4 dark sites
· 72 servers

9. DIVERSITY AND REDUNDANCY OF NETWORK AND DNS INFRATRUCTURE TO HANDLE 
BANDWIDTH CONGESTION AND NETWORK FAILURES OF ISPs AND HOST PROVIDERS and HOST 
PROVIDERS 
· Mix of Unicast and Anycast sites, with multiple Anycast clouds
· Different site architectures
· Multiple copies of site architectures
· Mix of ISP and Peering 
· Redundant network infrastructure at 2 sites



(iii) Operational scalability sufficient to handle existing registry database and projected growth; DNS queries including peak periods and projected growth; DDoS attacks, viruses, worms and spam; and restart capabilities.

WHY SENTAN
· 24 Nameserver sites on 6 continents with 72 nameservers

· Deployed capacity for supporting over 65B queries per day, 5 times estimated 
demand

· 4 dark nameserver sites that can be active within minutes

· Existing servers and software equipped to host a zone file of 15M names; 
estimated June 2006 zone file size is 7.2M names

· Estimated June 2006 .NET QPS is 150K QPS, Sentan DNS solution can support 
750K QPS

· Established, proven procedures to identify and respond to nefarious activities

· 2 new tools to battle DDoS 

1. INTRODUCTION
The DNS constellation reflects an awareness of growth in design, 
implementation, and in operation. The constellation is designed to address the 
key factors in growth, is implemented in a manner that is scalable, and is 
operated by a staff familiar with the constellation's components and with tools 
that track manifestations of growth.

Sentan's DNS Constellation is designed by an organization that participates in 
progressing the DNS protocol and operations techniques in public fora, such as 
the IETF and regional operator groups. Through this activity, we will be a 
contributor of expertise, be aware of innovations, and be able to accommodate 
and conform to new standards quickly. Implementation of the constellation will 
address the manifestations of growth. Growth resulting from registration 
activity (more names, rate of change, service extensions) will impact the 
implementation of individual nameservers and sites. Growth resulting from 
changes to network activity will impact the number of sites and site capacities.
This section discusses estimates of zone file size and query volumes. For 
details of how those estimates were generated, please refer to Part 2:b.xiv.

2. SCALABILITY OF REGISTRY DATABASE
The .NET zone file is currently 5.2M names.  We estimate that the zone will 
grow to 7.2M names in June 2006 and receive over 11B queries a day, with 150K 
peak queries per second. 

2.1 ZONE FILE SCALABILITY
The DNS implementation used in the constellation is BIND 8 and BIND 9. Both of 
these store the entire DNS zone in memory, making memory size a consideration. 
Internal research has shown that BIND can store and serve a zone approximately 
3 times the size of the current .NET zone on 32-bit architecture machines. The 
DNS solution deployed by Sentan's technical operator, has both 32-bit and 64-
bit servers. The 32-bit processors will not become an issue until well past 
2007 at which time we will have all nameservers on 64 bit hardware.

2.2 NAMESERVER SCALABILITY
Sentan's DNS solution includes 24 nameserver sites (20 active, 4 dark) globally 
distributed with 72 nameservers. Each site has at least a 100MB connection to 
the Internet. Responding to growth in network activity is easily and seamlessly 
accommodated in the DNS constellation. Unicast server sites use load balancers 
to share the traffic across 4 nameservers. Each site has 1 reserve nameserver 
that can be activated within minutes if additional capacity is needed. Since 
each of these sites is located in an Internet hosting site, additional 
bandwidth can be provisioned within days. In addition, Unicast sites can be 
added relatively easily because we are only using 9 of the 13 available slots 
in a nameserver record.

The use of Anycast offers even greater flexibility with regard to adding 
additional sites. Anycast also allows us to add new sites closer to sources of 
demand. For example, if there is an increase in demand in South America, we can 
easily add a site there without worrying about using one of the 13 available 
slots in the nameserver record.

Sentan has left 4 of our 24 sites dark, to be activated in the event that there 
is a higher than expected demand. This means that 4 additional sites can be 
added in minutes.

3. DNS QUERIES - PEAKS AND GROWTH
We estimate that .NET queries will grow to 11B on a peak day and 150K peak 
queries per second (QPS) by June 2006. Volumes were projected to June, 2006 to 
ensure that equipment deployed in June 2005 to support the transition of .NET 
did not need to be updated for at least 12 months.

Sentan's registry operator, NeuLevel, is in the process of deploying a 
constellation of nameservers for their existing registry business that will 
include 24 nameservers site with 72 nameservers.  These sites will complete 
installation by March 1, 2005. Sixteen of the sites will be installed in 
Internet Exchange Points (IXP) with direct peering to the IXP. Forty of the 72 
nameservers are IBM servers.  The IBM servers are split between HS20 blades 
servers and x336 rack mounted servers. 32 of the servers are Sun blade servers. 
8 nameserver sites are configured with 5 IBM servers behind a load balancer. 
This configuration yielded at least a 75K Peak QPS load. Sixteen servers 
consist of 2 Sun servers using router load balancing. This test yielded at 
least a 10K Peak QPS. Total capacity for the DNS constellation is over 750K 
QPS. The following illustrates the results of this test.  The 750K QPS capacity 
of the DNS solution is 5 times the estimated June, 2006 demand of 150K QPS.

DNS Capacity in QPS
------------------
Configuration: IBM
8 Sites
75K QPS per Site
600K Total QPS
------------------
Configuration: Sun
16 Sites
10K QPS per Site
160K Total QPS
------------------
Total Nameserver Sites
24 Sites
750K Total QPS

4. DDOS ATTACKS, VIRUSES, WORMS, AND SPAM
Workload will vary in both the long run (growth) and in the short run (bursts). 
Bursts of activity may be the result of a demand spike, a product, or by-
product of nefarious activity, such as DDoS, viruses, worms, and spam.

The .NET registry will protect against this nefarious activity through various 
means including:

· Provisioning for excess capacity;
· Availability of additional capacity on demand;
· Use of Anycast to localize attacks;
· Processes to identify and react to nefarious activity; and
· Security hardening of software and hardware.

4.1 PROVISIONING EXCESS CAPACITY
The Sentan solution deploys significant query processing capacity distributed 
in 24 locations throughout the globe. Large increases in traffic can be 
absorbed.

4.2 AVAILABILTY OF ADDITIONAL CAPACITY ON DEMAND
8 of the 24 nameserver sites have a spare nameserver capable of supporting 15K 
QPS that can be activated in minutes and 4 of the 24 nameservers are dark.  
They are strategically located in high-volume Internet exchanges.

4.3 USE OF ANYCAST TO LOCALIZE ATTACKS
Anycast routing technology advertises the same IP address for multiple sites 
and multiple servers. Because there are multiple sites and multiple servers, it 
is difficult for attacks to overload all servers by targeting the IP address. 
The sites closest to the attacker will absorb the attack while other sites in 
other regions continue to operate.

4.4 PROCEDURES TO IDENTIFY AND RESPOND TO NEFARIOUS ACTIVITY
Sentan's technical registry operator, NeuLevel, is deploying a state-of-the-art 
monitoring system to detect and respond to issues that effect their DNS 
constellation. Part of that system will be able to detect potential attacks 
such as a DDoS attack by monitoring the traffic on the servers. There are 3 
modules involved in the detection and alerting of an attack: 

· System Edge - A simple network management protocol (SNMP) agent which is 
loaded on each of the nameservers. It monitors the system health of the server 
including transaction volumes, CPU usage, disc memory, file systems, and 
critical processes.
· EHealth - Performs trending and statistical monitoring.
· NetCool - A network management system utilized by network operations 
personnel that receives data, and distributes and displays alarms.

System Edge is loaded on every nameserver. The system health data is sent over 
a VPN to eHealth every 30 seconds. EHealth is provisioned with acceptable 
thresholds for each of the system parameters. For example, if CPU utilization 
increases by 20% within 1 hour the NOC will be notified.  The thresholds are 
manually set initially but over time, a profile is created of each nameserver's 
traffic. When a threshold is breached, an alarm is sent to NetCool. NetCool is 
provisioned for 4 levels of priority, from P1 the highest level (critical) to 
P4 (informational) the lowest level. An attack on a nameserver is a P1 alarm. 

In addition, NeuLevel is in the process of upgrading its ISP infrastructure for 
the purposes of capacity and security. The primary and secondary SRS sites will 
be served by 2 OC3s (155MB) from 2 different ISPs. Each OC3 will be equipped 
with a DDoS protection service provided by the ISP. The ISP will monitor the 
sites IP addresses; if it detects traffic that fits the profile of a DDoS 
attack it will send the traffic through a filter. The filter will analyze the 
traffic and filter out the harmful traffic. It will be able to filter 2GB of 
traffic. Once the harmful traffic stops the connection will be returned to its 
normal configuration - the filter removed from the path. The SRS sites also 
serve as nameservers sites. In the event that there's a DDoS attack on our 
sites these sites will get an extra level of protection.

4.5 SECURITY HARDENING OF SOFTWARE AND HARDWARE
All nameserver network, security, and server hardware and software have been 
rigorously hardened to filter nefarious traffic and access attempts and to only 
allow DNS traffic into the site. Details of this hardening are discussed in the 
confidential security section, Part 2:5.b.xiii.

5. RESTART CAPABILITIES
To restart DNS resolution, the first step is to reach and restart the 
individual elements, such as the processes running on the nameserver. The next 
step is to make sure all of the nameservers have data to serve. The final step 
is to make sure all of the components are up to date.

To restart a nameserver site, Internet packet forwarding is disabled on the 
router(s). This will leave either the VPN or the modem backup as the only means 
to contact the site. A console server is in place at all sites with LAN and 
load balancing equipment able to reach any component. Once the site is 
stabilized, processes that have failed or gotten stuck can be restarted. 
There are 16 Anycast sites that consist of only routers and nameservers, 
described as servers G and H in Part 2:5.b.ii. These sites have dedicated 
bandwidth into each router, bypassing the Internet exchange. The architecture 
of these sites does not need a modem connection or a console server.

Once a nameserver resumes operating, BIND will have a local copy of the zone 
available.  Because the disk copy of the zone may have fallen out-of-date, BIND 
also seeks to find a newer copy, and retrieves newer data from a master server. 
In Part 2:5.b.viii, regional-masters are used to send zone updates, this 
feature will be a benefit if a series of nameservers at one location resume 
service at once. At this point, Internet traffic forwarding can be enabled on 
the router.

In the event of an outage that prevents the NOC from accessing a nameserver 
site via the Internet or VPN, there is a backup modem connection available to 
all sites. This latter connection will enable the NOC to manually restart 
failed processes.



(iv) Describe the registry-registrar model and protocol; availability of a shared registration system, including processing times for standard queries (add, modify, delete); and duration of any planned or unplanned outages.

WHY SENTAN
· State-of-the-art Three Box Data center architecture built on a proven design

· Full redundancy at both primary and secondary sites

· Additional disaster recovery site

· Currently capable of handling both EPP and RRP

· Currently registering IDNs that are compliant with all IDN standards

· Currently storing IPv6 name server information

· More rigorous uptime specifications than in any existing ICANN contract

· More rigorous performance specifications than in any existing ICANN contract

·Performance being measured using 100% of all production transactions (not 
sampling)

1. INTRODUCTION
Sentan's technical operator, NeuLevel provides a shared registration system 
(SRS) that is a production-proven, standards-based, highly reliable and high-
performance domain name registration and management system that exceeds the 
requirements put forth in the .NET RFP. In this section, we will describe the:

· Registry-registrar model and protocol;
· Availability of our SRS;
· SRS performance characteristics; and
· Planned and unplanned outages.

The SRS lies at the heart of a registry operation and its quality and 
capability are essential to the overall stability of the .NET. Given the 
importance of a smooth transition to a new operator, the SRS must adhere to 
existing standard models and protocols. Given the aggressive transition 
timeline, it is not practical for a new operator to do material development 
after the selection date. The selected registry operator must have the ability 
to deploy an SRS in this very tight schedule. Additionally, the SRS must have 
high performance and be highly reliable. Our SRS, with its operation 
experience, meets these exacting requirements and will be an outstanding 
platform for the .NET registry. Throughout the section we provide information 
that demonstrates the quality of our SRS.

2. REGISTRY-REGISTRAR MODEL AND PROTOCOL
The registry-registrar model we propose does not deviate in any way from 
current industry practices. The registry-registrar model, while not defined 
completely by any one document, is described and embodied in a number of IETF 
RFCs, ICANN contracts and practices, and registry-registrar agreements. We 
recognize the hard work and many years of experience embodied in these years of 
industry practice. It would be very difficult for any entity that has not been 
practicing an EPP registry under ICANN policies and practices to deploy an SRS 
in that short time.

RFP Part 2:2.b describes the registry-registrar protocol required of the 
new .NET operator. Sentan complies fully with these requirements. At time of 
transition, our SRS will support RRP as defined in RFC 2832, RFC 3632 and 
modified to be compatible with the 2.1.2 software deployed in the current .NET 
registry. (We have already launched our .NET RRP Operational Test and 
Evaluation (OT&E) environment.)  Additionally, at transition, our SRS will also 
support EPP 1.0 as defined in RFCs 3730, 3731, 3732, 3733, 3734, and 3735. 

Sentan and our technical operator, NeuLevel, are fully committed to a 
cooperative, consensus-based approach to registry protocol development and 
deployment. As proven by our past operations, adherence to industry standard 
protocols is central to the mission of a domain name registry.

Please refer to Part 2:2.b for further information on our plan regarding 
registry-registrar interaction during the important period of protocol 
transition and during our transition from a thin to a thick registry.

Our SRS is currently capable of registering and managing internationalized 
domain name (IDN) in a fashion that is fully compliant with relevant ICANN 
guidelines and IETF standards. NeuLevel launched German language IDN in .BIZ in 
October 2004, and to date over two-dozen registrars have registered IDN names. 
Additionally, our SRS technology is at the heart of our ccTLD gateway to 
the .TW and .CN ccTLDs. In close cooperation with CNNIC, NeuLevel launched 
Chinese language IDNs in January 2005. This was significant in that it was the 
first fully standards-compliant deployment of Chinese language IDNs to the 
global registrar community.

We will support IDNs in .NET in a fully standards-compliant fashion at the time 
of transition. We believe that adherence to ICANN guidelines and IETF standards 
is essential to the healthy growth of IDNs and the ongoing globalization of the 
Internet. There are approximately 80,000 IDNs that are currently registered 
in .NET. These will be transitioned along with all other names in the database. 
Based on our analysis, some of these names are not fully compliant with 
accepted IDN practices, as they do not form a single language string. 
Recognizing the registrants' investment in these names, we will "grandfather" 
these names into the database, allowing them to remain registered and 
renewable. However, we will enforce ICANN guidelines and IETF standards on all 
IDN names registered after the transition date.

Additionally, our SRS is currently capable of registering IPv6 name servers and 
this capability will be part of our .NET SRS at the time of transition. 
Introduced in October 2004, this functionality allows registrars to provide 
IPv6 nameserver information into the registry database, where it is 
subsequently deployed into our DNS infrastructure. This capability is critical 
to the adoption and growth of IPv6 technology, an important technology at the 
infrastructure layer of the Internet, especially in growing and emerging 
markets.

3. AVAILABILITY OF OUR SRS
NeuLevel's SRS which operates both .BIZ and .US, consistently beats its 
stringent service level requirements (SLRs). Table 1 contains some data from 
our ICANN reports for .BIZ.

                      Service Availability - SRS
                     SRS - 99.9 per calendar month
-------------------------------------------------------------------
July 100%   Aug 100%   Sept 100%   Oct 100%   Nov 100%   Dec 100%

For .NET, Sentan, along with its registry operator, NeuLevel, will improve 
these commitments to 99.95% availability. We can commit to improving that 
service because of NeuLevel's extensive experience with EPP as well as 
improvements they've made to the platform for .NET.

NeuLevel is building a new SRS infrastructure dedicated to .NET based on 
production-proven architecture, the core of which has been in continuous 
operation since 2001. We are among the most experienced operators of EPP in the 
world, thus greatly lowering the overall risk of transitioning the .NET 
registry from RRP to EPP. Our EPP 1.0 compliant SRS software is in operation 
now and will only require minor modifications for .NET. As already stated, our 
RRP OT&E environment is operational as of proposal submission, the EPP OT&E 
will be available on April 1, 2005. Based on our industry experience, these 
timeframes will prove more than sufficient for a smooth transition.

Since NeuLevel first built its .BIZ and .US SRS in 2001, there have been 
advances in technology used for data center design. Two of those advances have 
been the advent of blade servers and the infrastructure switch. These two 
capabilities combined with a storage area network make up a new concept in data 
center design called the "Three Box" Data Center. Conceptually, a Three Box 
Data Center could consist of a single device for infrastructure, a single 
device for servers, and a single device for storage. However, it can also be 
used to describe an architecture where a number of identical devices can be 
used for each element of the architecture to accommodate equipment diversity 
and capacity. 

The infrastructure switch is a device that can perform multiple network related 
functions such as router, switch, load balancer, and firewall. This device 
results in cost saving and floor space reduction but it still provides separate 
functional systems that operate as if they were stand alone devices, with their 
own management console and element management system. 

Blade servers provide considerably more processing power in a much smaller 
space. It's possible to get over 140 CPUs in a standard rack, as compared to 
approximately 30 in a standard rack mount server configuration. Blade servers 
also incorporate onboard switches, gigE interfaces, management module, and 
redundant power supplies and cooling systems. This reduces the need for 
external switches, lowering maintenance expenses and reducing points of 
failure. 

NeuLevel has used the concepts it developed in building the .BIZ and .US 
registries and improved upon them with new technologies to deploy a state-of-
the-art Three Box Data Center architecture for .NET. 

We've chosen the Cisco 7609 with integrated switch, router, load balancer, and 
firewall functionality for our infrastructure switch. The firewall is a core 
firewall between the EPP servers and Application servers and between the 
application servers and the .NET database. The load balancer balances the load 
among the multiple EPP servers and Application servers. They are operated in a 
high availability configuration (2 switches). 

The blade servers are used for our EPP and Application servers. We use multiple 
IBM blade servers with 2 CPUs and 2.5G of RAM. This allows us to scale 
horizontally and maintain high availability. If one server is down, the other 
servers can support the capacity. 

The data base servers are IBM p570 servers with 8 CPUs and 24G of RAM. This 
server can scale up to 16 CPUs and 64G of RAM.

NeuLevel is deploying a true state of the art SRS by building upon its existing 
reliable architecture and updating the infrastructure to deploy a Three Box 
Data Center. See Exhibit 009.net for a diagram of the .NET SRS architecture. 

4. PROCESSING TIME FOR STANDARD QUERIES
Our SRS has a long history of high-performance SRS operation. In 2001 in 
launching .BIZ, the registry withstood the high volume of a landrush without 
incident, a claim that not every new gTLD registry launched in 2001 could make. 
Subsequently, in 2002, our registry also handled the .US landrush without 
incident, registering over 90,000 names with thick data in under 6 hours. 
Our .NET SRS will be built upon this same architecture, leveraging software 
that has consistently evolved to produce ever-increasing performance, and will 
operate on its own systems and network infrastructure, using equipment 
specifically configured for .NET. Consequently, it will be our best performing 
SRS.

Our current SRS, which operates both .BIZ and .US, consistently beats its 
stringent service level requirements (SLRs). Table 2 contains some data from 
our ICANN reports for .BIZ.

                 Processing Time - Add, Modify, Delete of all objects	
                      SLR - 3000 ms for 95% of transactions
--------------------------------------------------------------------------------
July 99.8%    Aug 99.8%    Sept 99.5%    Oct 99.9%    Nov 99.7%    Dec 99.9%


                    Processing Processing Time - Query Domain	
                      SLR - 1500 ms for 95% of transactions	
--------------------------------------------------------------------------------
July 99.9%    Aug 99.9%    Sept 99.9%    Oct 99.9%	    Nov 99.8%    Dec 
99.9%


The current .NET performance specifications are:
· Check domain average: 3 seconds; and
· Add domain average: 5 seconds.

For .NET, our SRS performance specifications will be:
· Read operations (check, info, etc):  95% will complete in 500ms or less
· Write operations:  95% will complete in 1000ms or less

These are far more aggressive performance specifications than the current .NET 
or .ORG agreement. Not only are the numerical thresholds lowered by 
approximately 80%, but also the measurement is based on the 95th percentile, 
not on the average. When compared to an "average", a "95th-percentile" 
measurement provides a far better representation of the true, performance being 
provided by the SRS and being experienced by the registrars. These performance 
specifications are to date the most rigorous in the industry.

Additionally, these performance measurements will be calculated by analyzing 
each and every production registrar transaction that flows through the SRS. 
This stands in stark contrast to the performance measurement approach used by 
other registry operators, which generates performance statistics by 
periodically injecting test transactions into the SRS. (See Part 2:5.b.xv for 
more information on our SRS performance SLAs.)

As further proof of the performance capability of our SRS, the following is an 
alternative analysis of our performance in the last half of 2004. In this 
table, we measure our actual .BIZ performance against our proposed .NET 
performance specifications.

                 Processing Time - Add, Modify, Delete of all objects	
                      SLR - 1000 ms for 95% of transactions
--------------------------------------------------------------------------------
July 96.2%    Aug 99.2%    Sept 97.9%    Oct 99.7%	    Nov 98.6%    Dec 
99.7%


                       Processing Time - Query Domain	
                    SLR - 500 ms for 95% of transactions
--------------------------------------------------------------------------------
July 99.9%   Aug 99.9%   Sept 99.8%   Oct 99.4%   Nov 98.9%   Dec 98.9%


This demonstrates quite clearly the confidence we have in our ability to 
achieve these proposed service levels.

Another factor in SRS performance is the ability to handle "add storms", 
periods of high EPP/RRP traffic that coincide with the deletion of names from 
the SRS. Add storms are a challenging phenomenon for a registry because the 
operator must balance equal access with stability. Overall, we manage equal 
access by allocating a set of SRS 35 connections to each registrar divided into 
two groups, one of 25 and one of 10. The group of 10 is known as the add storm 
connections and can be used to submit add storm transactions. The group of 25, 
the "normal pool", can be used for normal transactions. Normal transactions can 
be defined as the transactions generated by normal daily behavior of the 
registrants and resellers, e.g., registering new names, modifying existing 
names, and renewing names, while add storm transactions are those that are 
generated by attempts by the registrars to register a name that is expiring at 
a specific date and time. We will monitor traffic levels and patterns in the 
normal pool and work with individual registrars to ensure compliance with add 
storm policies.

5. PLANNED AND UNPLANNED OUTAGES AND DURATION 
Our SRS consists of a primary installation located in Sterling, Virginia, USA 
and a backup installation located in Charlotte, North Carolina, USA. As 
described in Part 2:5.b.xvi, our .NET SRS architecture will be highly 
redundant, having no single point of failure at either site. This greatly 
lowers the possibility of an unplanned outage. Indeed, in the past 16 months, 
as evidenced in our publicly available ICANN reports, we have experienced only 
one brief unplanned outage of our SRS. Section 3 above contains .BIZ SRS 
availability statistics for the past 6 months. This is a record of reliability 
that is easily comparable to, if not superior to, every other major registry 
operator. During this period, due to our redundant architecture, we have not 
been subject to any outages even though we have experienced equipment failures 
at frequencies expected by the manufacturers. Our architectural redundancy also 
allows us to perform a wide variety of minor maintenance without undertaking 
any failover activities.

It takes NeuLevel no more than 10 minutes to either cutover the SRS to the 
online backup database, or cutover to the secondary SRS in Charlotte.  If 
however there is an outage and the initial diagnosis is that service can be 
restored within 15 minutes, we do not initiate a cutover, instead we fix the 
problem and restore service.  If we do have to initiate cutover the unplanned 
outage will be no longer than 15 minutes, 5 minutes to diagnose the problem and 
10 minutes to cutover.

Operating an infrastructure as complex and intricate as a registry requires 
frequent maintenance and adjustments to the hardware and software systems. Our 
ability to failover to our secondary data center in a smooth and efficient 
manner allows us to minimize the frequency and duration of our planned 
maintenance outages as demonstrated by the following table covering the .BIZ 
registry operations:

                            Planned Outage Duration
--------------------------------------------------------------------------------
July 0 min   Aug 60 min   Sept 60 min   Oct 120 min   Nov 0 min   Dec 0 min

It should also be noted that we perform an annual extended maintenance outage 
in order to perform some critical pre-emptive maintenance activities, including 
a full failover test drill and a full overhaul of our data center power 
systems. 

In the event that we decide to failover SRS operations from the primary site to 
the backup site, our facilities are configured such that this can be 
accomplished quickly. We leverage this failover capability to conduct major 
planned site maintenance. When we conduct such maintenance, the total failover 
outage time is typically planned for one hour. This time duration is chosen to 
provide for a generous cushion. Failover will take approximately 15 minutes. 
Our confidence in our SRS architecture is evident by our commitment to 
stringent SRS availability Service Level Agreements, provided in Part 2:5.b.xv.

In addition to local redundancy and a dual-site capability, our SRS solution 
also includes a disaster recovery SRS in Tokyo, Japan. This provides an extra 
level of assurance that makes it possible to minimize outages (through quick 
failover to the disaster recovery site) even if the primary or secondary site 
is inoperable. The disaster recovery SRS is described fully in Part 2:5.b.xvi.



(v) Database capabilities including database software, size, throughput, scalability, procedures for object creation, editing, and deletion, change notifications, registrar transfer procedures, grace period implementation , availability of system with respect to unplanned outage time, response time performance; ability to handle current volumes and expected growth and reporting capabilities.

WHY SENTAN:
· Database capacity for 8 million domain names - as compared to June 06 
estimate of 7.2 million

· Database capacity for 13,333 transactions per second (TPS) - as compared to 
June 06 estimate of 4,500 TPS

· Database failover to backup in 10 minutes

· Commitment to faster transaction volumes than in existing .BIZ contract

· Well constructed solution for mixed protocol environment - EPP and RRP

· New reporting tool allows registrars to create ad hoc reports using the 
registry database

1. INTRODUCTION
At the core of the SRS is its database systems, which provides not only simple 
data storage-and-retrieval capabilities, but also the following attributes:

· Persistence--storage and random retrieval of data to enable rapid response 
times;

· Concurrency--ability to support multiple users;

· Replication--maintenance of data across multiple databases for redundancy and 
greater data security;

· Integrity--methods to ensure data is not lost or corrupted (e.g., automatic 
two-phase commit, physical and logical log files, roll-forward recovery) which 
maximizes accuracy, as well as redundancy and security;

· Availability--24/7/365 operations to support all registrars around the world; 
and

· Scalability--unimpaired performance as the number of users, workload volume, 
database size, or functionality increases to meet the growing needs of the .NET 
community.

2. THE .NET REGISTRY DATABASE - A FUNCTIONAL OVERVIEW
The .NET registry will include 4 major databases--SRS, Reporting, Billing and 
Collections (B&C), and WHOIS. This section provides detail relating only to 
the .NET SRS and Reporting databases. Information on the remaining 2 databases 
are referenced to other subsections of our response.  
.NET SRS DATABASE'S primary function is to provide highly reliable, persistent 
storage for all registry information required for domain registration services. 
The .NET database is highly secure, with access limited to transactions from 
authenticated registrars, trusted application-server processes, and highly 
restricted access by the registry database administrators. Supporting a thick 
data model, the .NET SRS database will store the following data:

Domain names	
·	Attributes (status)
·	Registrant
·	Contact details (administrative, billing and technical)
·	Authorization Information
·	Associated name servers
·	Associated registrar

Nameserver	
·	Attributes (status)
·	Associated IP addresses (if applicable)
·	Associated registrar

IP address	
·	IP Address attributes (status)
·	Associated nameservers
·	Associated registrar

Registrars	
·	Name
·	Contact details
·	URL (Home page)
·	WHOIS URL (Web Port 80)
·	WHOIS URL (Port 43 - if applicable)
·	Attributes (status)

THE REPORTING DATABASE is used to create both internal and external reports, 
primarily to support registrar billing and contractual reporting requirements 
for ICANN. For billing reports, the database is updated incrementally 4 times 
daily, then supplies those updates to the B&C system, which provides billing 
information for the registrars. For ICANN reporting, daily full backups are 
copied to the reporting database to perform report queries on a monthly and 
daily basis, per ICANN requirements. 

THE B&C DATABASE provides the information required for Sentan to accurately and 
efficiently render B&C services to the registrars. Access to data is restricted 
to the trusted B&C system processes and to registry database administrators.  
See Part 2:5.b.ix for more detailed information on the B&C system and 
procedures.

THE WHOIS DATABASE is a searchable database that any Internet user can access 
to view details of the domain name stored in the .NET database. The WHOIS 
database maintains data about registrars, domain names, nameservers, and IP 
addresses. The WHOIS database will be updated from the .NET SRS database via a 
dynamic and incremental replication process. WHOIS is discussed in more detail 
in Part 2:5.b.xii.

In addition to these databases, the registry will maintain numerous internal 
databases to support various operations, e.g., authorizing login UserIDs and 
passwords, authenticating digital certificates, and maintaining access control 
lists. 

3. DATABASE SOFTWARE
Sentan's technical operator, NeuLevel, utilizes the Oracle 9i DBMS for all SRS-
related databases. Oracle's reputation, stability, and global support make it 
the right choice for high-volume, high-transaction systems such as the SRS. 
They also utilize Oracle for their existing registry services .BIZ, CNNIC, and 
TWNIC Gateway.

4. DATABASE SIZE, THROUGHPUT, AND SCALABILITY
The following provides design parameters for the SRS and Reporting databases 
discussed in this section.   The parameters are based on current size and 
projected volumes over the next 2 years and applies to the production and 
Operation Testing and Evaluation (OTE) environments. The term "scalability" in 
the list refers to the databases' ultimate capacity expressed as a multiple of 
the initial design capacity in terms of size and transaction processing power. 

Database design parameters

.NET DATABASE	      ENGINEERED CAPACITY          ESTIMATED June 06 VOLUMES
----------------------------------------------------------------------------
Domain registrations:	         8 million	             7.2
Registrars:	                500	                     450
Database throughput TPS:	13,333	                   4,500
Size of registration object:	 10 K		
Total data:	                500 G
DBMS and logs:	                 20 G
Database indexing:	        150 G
Total size:	                650 G
Database scalability:	From 2-way to 16-way

REPORTING DATABASE	
------------------------------------------
Registrars:	500
Size of registration object:	4 K
Total data:	39 G
DBMS & logs:	10 G
Database indexing: 	100 G
Total size: 	200 G
Database throughput:	TPS = 2600
Database scalability:	2 to 16 way

5. DATABASE PROCEDURES FOR OBJECT CREATION, EDITING AND DELETION
All operational interactions with the SRS database occur via EPP or RRP 
transactions, which are passed through a firewall to an application server 
layer.  The application servers first apply the business rules and then perform 
the applicable operation on the database.  This layered architecture ensures 
that only operations that are processed using pre-defined business rules may be 
committed to the database.  In addition, this layered approach, with the 
database protected at the application and security layers, ensures that all 
registry data is protected from unauthorized access.

All operations, which cause changes to the database, are written to log files 
and audit tables. Combined, these provide a fully traceable and verifiable 
transaction history, including the time and source of all transactions. 
Operations that effect changes to the Database may only be performed by 
registrars, registry customer support, or authorized database administrators.  
All such transactions are subject to standard EPP and RRP security measures at 
both the application and network layers.

6. CHANGE NOTIFICATION
The primary means of notifying a registrar of changes to the database is via an 
EPP/RRP response code. As mentioned above, all operations to the database are 
processed by an application server, which will return an appropriate response 
code indicating that the transaction was either successful or unsuccessful.  
Additionally, the contents of the response to an EPP Poll command will notify 
the registrar of a pending domain transfer request or the result of a 
previously submitted domain transfer request. Some other notification methods 
are:

·	Daily transaction reports made available to registrars provide data on 
all domain creations, renewals, transfers, deletions and modifications 
performed by that registrar.

·	Billing notices will inform a registrar when it has reached its low-
water mark.

In certain rare circumstances, an operational problem emerges for which the 
resolution is best accomplished by a manual database change.  This approach is 
only used when all other reasonable possibilities have been exhausted.  In 
these cases, the registrar is contacted and provided with a full explanation of 
the situation.  Then registry database administrators, under strict change 
control procedures, perform the change.  The registrar is subsequently notified 
in writing with an explanation of the change, the impact, and the reason it was 
required. 

7. REGISTRAR TRANSFER PROCEDURES
Registrants may transfer their domain name from one sponsoring registrar to 
another after the first 60 days of the initial registration of the domain name. 
NeuLevel currently performs registrar transfers in its existing registry 
service over an EPP interface. In the .NET registry, the transfer process will 
be done over an RRP, EPP, or a mixed (RRP-to-EPP or vice versa) interface. 

The 2 protocols are different in 2 ways when it comes to registrar transfers:
· Registrar notification

   o With RRP, notifications to registrars are sent via email to both  
transferring registrars

   o With EPP, notifications to registrars are sent using the EPP poll command

· AuthInfo - With EPP, a registrar transfer requires the gaining registrar to 
submit authenticating information related to the domain.  The registry 
validates the AuthInfo provided by the registrar with the AuthInfo associated 
with the domain.  If there's a match, the transfer continues.  If there is no 
match, the transfer request is immediately denied.

The transfer process works as follows:

· The registry receives a transfer request from the gaining registrar.

· The registry notifies both the gaining and losing registrars of the transfer.

· The domain will be transferred if (a) the losing registrar expressly 
acknowledges (ACKS) the request; or (b) the registry does not receive a 
response from the losing registrar within 5 days.

· The domain will not be transferred if the registry receives a negative 
acknowledgment (NACK) from the losing registrar.

· If the domain is transferred, both registrars will be notified after the 
database has been updated to reflect the transfer to the gaining registrar.

For a mixed (EPP and RRP) transfer request, if the gaining registrar is using 
EPP and the losing registrar RRP, the notifications to the losing registrar 
will be sent via email, and via EPP poll commands to the gaining registrar.  If 
the gaining registrar is using RRP and the losing registrar EPP, again, the 
notifications to the losing registrar will be sent via EPP poll commands, and 
the gaining registrar will receive email. AuthInfo will not be required for a 
mixed transfer request.  

8. GRACE PERIOD IMPLEMENTATION
For .NET, NeuLevel will support grace periods for the add, renew, auto-renew, 
and transfers functions, including ICANN's policy on overlapping grace periods. 
In addition, NeuLevel will implement ICANN's redemption grace period policy.

9. AVAILABILITY OF SYSTEM WITH RESPECT TO UNPLANNED OUTAGE TIME
The database architecture is designed in such a way as to prevent, within 
limits, any unplanned outages. There is always risk that any system can fail, 
in even the best of circumstances, NeuLevel's redundant database and high-
availability network design will ensure the lowest number of unplanned outages 
possible. They will provide real-time, local failover at their primary SRS 
datacenter, allowing them to rapidly fail to a backup database within 10 
minutes should they experience a database software or hardware issue on the 
primary database. In addition, they will employ an automatic failover process 
between the primary and secondary database sites. The automatic failover 
process will enable the database to failover and the registry to be back up and 
operational within 15 minutes. 

In the event of a major hardware, software, or overall data center problem, the 
SRS database will failover automatically and without human intervention to the 
secondary SRS database. The database connection pool will contain connections 
to both the primary and secondary database servers. In the event of a failure 
of the primary, the application servers will continually try to establish a 
connection to either the primary or secondary. Once the auto-failover is 
complete and the secondary becomes available, connections will be established 
and processing will continue normally. 

10. RESPONSE TIME PERFORMANCE
Database response time can be defined as the number of milliseconds required to 
respond to both write and query transaction types. In NeuLevel's current 
registry operations for .BIZ, committed response time performance is as follows:

· SRS query operations, 95% will complete in 1500 msec or less; and 
· SRS write operations, 95% will complete in 3000 msec or less.

For .NET, Sentan proposes an increase in performance response times, which will 
provide improved service to current registrars. Our committed response time 
performance will be:

·	SRS query operations, 95% will complete in 500 msec or less; and
·	SRS write operations, 95% will complete in 1000 msec or less.

These are overall transaction times that are impacted by SRS components other 
than just the database. The performance of the database is paramount to meeting 
these aggressive service levels. Thus, NeuLevel's database design, upon 
transition, will be capable of processing 13,333 transactions per second, 
performing well above the requirement to meet the proposed service level 
agreement. For more information on quality of service, see Part 2:5.b.xv.

11. ABILITY TO HANLDE CURRENT VOLUMES AND EXPECTED GROWTH
While the 4 primary SRS databases will differ depending upon the services they 

· Manage large quantities of data;
· Support applications that use data models with complex relationships;
· Perform complex operations on managed objects; and
· Process large volumes of transactions from users.

Sentan forecasts that, as with most online transaction processing (OLTP) 
applications, the anticipated volume of SRS transactions will have a high ratio 
of reads to writes. We have designed the databases by partitioning the workload 
to optimize response times and scalability. The current .NET database contains 
just over 5 million names. Sentan's current growth estimates predict the .NET 
database will contain 7.2 million names in June 2006 and will process 4,500 
transactions per second (TPS). Using that data as a guide, we have sized the 
database for 8 million names and 13,333 TPS to ensure we not only have more 
than enough capacity for the transition in 2005, but room for immediate growth 
as well. See previous subsection on database size, throughput, and scalability 
for more information on database sizing.

Both the primary and secondary SRS locations in Sterling and Charlotte will 
have 2 database servers available: one primary and one backup for local 
failover. The local failover machine provides a means to quickly restore 
service in the event of an unplanned outage due to a database hardware issue. 
Attributes of all SRS database servers are as follows:

· IBM P570 server hardware;

· 8 x 1.90GHz POWER5 processors;

· 24 GB of 1.90GHz RAM;

· 2 hot-swappable disk drive bays per building-block/module with up to 880GB of 
internal storage;

· Data will be stored on an external EMC Symmetrix DX800 storage device with 
high-speed fibre-channel connectivity for reliability and performance;

· 6 hot-plug PCI-X adapter slots per building-block;

· 2 integrated internal Ultra320 SCSI controllers;

· Redundant hot-swappable, power supplies;

· 2 GB Fibre Channel;

· 3 10/100/1000 Ethernet Ports/Adapters; 

· Event management software for remote management; and

· IBM AIX 5L Operating System.

The database servers have been sized to efficiently handle both current and 
projected growth volumes as configured. All servers can be easily upgraded 
within hours to service dynamically changing transaction volumes, if necessary. 
This ability allows us to rapidly respond to changing transaction load levels 
while minimizing down time.

12. REPORTING CAPABILTIES
To support a detailed, usage-based accounting and billing structure, the B&C 
database and the .NET database will generate a substantial amount of highly 
detailed resource accounting data. This includes: 

· Monthly account statements--Sentan will send a detailed monthly transaction 
statement to each registrar via email. The statement will include:

 o An account summary, including payments received, balance forward, and 
   credits and adjustments.
 o A detailed list of all fee-incurring charges; e.g., new registrations,
   registration renewals, registrar transfers.

· Online B&C reports--The B&C system will generate a variety of reports for 
internal and external users.  Using the Internet, registrars will be able to 
access their secure account statements and detailed transaction reports, but 
not those of other registrars. Registrars will be able to request custom 
reports. The system will generate these reports in a batch process, and will 
store them in the FTP directory for the requesting registrar to download. 

· Audit reports--We will create audit reports, for internal and external 
purposes, that will include policy implementation, access privileges, capacity 
handling, and accountability.

In addition to these existing reporting capabilities Sentan, through NeuLevel, 
will provide additional functionality that allows registrars to customize their 
own reports, at no additional costs, through a tool called Ad Hoc Reporting.  
This tool will provide to registrars with fewer resources, the same access to 
industry reporting that larger registrars can produce in-house, which will 
further enhance competition in the registrar space.

(vi) Geographic network coverage, including physically diverse sites and support of growing and emerging markets.

WHY SENTAN
· 24 nameservers sites on 6 continents

· 3 SRS sites, 2 in North America and 1 in Japan

· 3 WHOIS sites, 2 in North America and 1 in Japan

· Research and development effort to provide 2 operational EPP server 
locations, 1 in North America and 1 in Japan

· Strong support for growing and emerging markets through location selection 
and IPv6 support

1. PHYSICALLY DIVERSE SITES AND SUPPORT FOR GROWING AND EMERGING MARKETS
Sentan's technical registry operator, NeuLevel, is deploying 24 nameserver 
sites around the world including at least one on every continent (except 
Antarctica) to ensure the greatest geographic network coverage and support for 
growing and emerging markets. 

The Internet is expanding globally at a rapid pace. Internet penetration is 
greater than 30% in North America, Europe, and Australia/Oceania, but the 
growth rate of penetration is fastest in Asia, South America, and Africa. 
The .NET registry needs to provide service where it is needed most, and needs 
to support those countries where expansion is occurring; both are critically 
important to .NET and to the Internet. Furthermore, because of the importance 
of the .NET domain to the infrastructure of the Internet, it is even more 
important that .NET have a presence in growing and emerging markets to foster 
the growth of the Internet. 

Sentan and its parent companies, NeuLevel and JPRS, believe in supporting the 
continuing globalization of the Internet. For example, NeuLevel has created 
partnerships with other like-minded companies from other parts of the world, 
e.g., Melbourne IT from Australia, CNNIC from China, and JPRS from Japan, in an 
effort to foster globalization. The following details Sentan's breadth of 
global coverage and commitment to support growing and emerging markets, as 
appropriate. 

The following is an excerpt from a white paper issued by the Global Internet 
Policy Initiative on June 6, 2002:

"To speed the spread of the Internet in developing countries, the cost of the 
Internet connectivity and bandwidth must be reduced and the quality of service 
improved. One of the most effective mechanisms to accomplish both cost and 
service gains is the Internet Exchange Point (IXP). An IXP interconnects 
Internet service providers (ISPs) in a region or a country, allowing them to 
exchange domestic Internet traffic locally without having to send those 
messages across multiple international hops to reach their destination."

A very similar thing can be said for gTLD nameservers. A nameserver located 
closer to developing countries will improve the quality of service to those 
countries. For example, locating a .NET nameserver in Nairobi, Kenya means that 
queries for .NET names do not have to go over a satellite link to another 
continent for Internet users within Kenya that access .NET names, so they will 
receive better service. The lower latency and higher reliability for .NET 
domain names would encourage ISPs and other Internet providers in Kenya to 
locate servers and services within Africa, rather than on another continent. 

Sentan finds this to be a compelling proposition. Our solution for .NET not 
only provides significant coverage within regions of the world that already use 
the Internet, but also provides improved coverage for growing and emerging 
markets.  Another important aspect of Sentan's global reach strategy is support 
for IPv6. We will continue to support IPv6 in the .NET registry. IPv6 is an 
important aspect for the globalization of the Internet. Because the Internet 
has been adopted faster in certain regions of the world, those regions 
naturally have used a higher percentage of IPv4 addresses than growing and 
emerging markets. As the Internet continues to grow into those emerging 
markets, IPv6 addresses will become increasingly important to continued growth 
of the Internet. IPv6 addresses will be able to be registered with .NET 
resource records. The .NET nameservers will be able to be accessed directly 
from the IPv6 backbone, .NET nameservers will have IPv6 addresses. This will 
ensure Internet users that use IPv6 addresses can register them natively 
in .NET and users trying to reach those addresses can reach .NET nameservers 
natively from the IPv6 backbone. 

2. DNS - COVERAGE AND SUPPORT
To achieve our goals for globalization and geographic diversity, Sentan, in 
collaboration with its technical operator NeuLevel, has chosen an innovative 
solution that includes many nameserver sites located in Internet exchange 
points (IXP). The nameservers will peer directly with the exchange. In many of 
those exchanges, the nameservers will peer in native IPv6. This allows us to 
encourage the growth of the Internet into new and emerging markets and to 
provide the best service possible to ISPs and Internet users. 

Our DNS solution has the following 24 nameserver sites located on 6 continents 
(See Exhibit 5.b.vi-1):

Africa
· Johannesburg, South Africa
· Nairobi, Kenya

Asia
· Hong Kong
· Osaka, Japan
· Seoul, South Korea
· Singapore 1
· Singapore 2
· Singapore 3
· Tokyo, Japan

Australia/Oceania
· Wellington, New Zealand

Europe
· Amsterdam, the Netherlands
· London, UK
· London, UK
· Paris, France

North America
· Ashburn, Virginia, USA
· Charlotte, North Carolina, USA
· Los Angeles, California, USA
· Miami, Florida, USA
· New York City, New York, USA
· Palo Alto, California, USA
· San Jose, California, USA
· Seattle, Washington, USA
· Sterling, Virginia, USA

South America
· Sao Paolo, Brazil

Four of the nameserver sites, located in high-traffic regions, will be dark 
sites. They will be turned on in the event that there is an outage or we need 
additional capacity quickly. From an operational perspective, these sites will 
be treated like the other 20 sites, they will be monitored and their zone file 
will be dynamically updated. They will be Anycast sites with border gateway 
protocol (BGP) turned off (the IP addresses will not be advertised to the 
Internet). If we need to use them, to provide extra capacity, we will simply 
turn on BGP. 

Twenty-four sites, many of them located in IXPs, not only provide global 
coverage but also provide significant geographic diversity. Geographic 
diversity is important for survivability. The more distributed the servers are, 
the harder it will be for the nameservers to be subject to a massive outage 
caused by a disaster or attack. 

3. SRS - COVERAGE AND SUPPORT
Sentan's solution utilizes 3 SRS sites rather than the traditional 2. There 
will be a primary SRS site and a secondary SRS site located in North America at 
the NeuLevel data centers. In addition to these 2 sites, there will be a 
disaster recovery SRS site located in Japan. 

The disaster recovery site serves 3 functions:

1. It converts to the secondary site if there is an outage in the primary site 
that disrupts service for a lengthy period of time;

2. It becomes the primary site if there is an outage in the primary and 
secondary site at the same time; and
3. It will be used for registry related research and development.

JPRS has cooperated with NeuLevel to perform registry related research and 
development (R&D). See Part 2:5.b.xvii for a more detailed description of the 
R&D efforts. One of Sentan's priorities regarding R&D is to improve the service 
to registrars outside of North America. JPRS will research, via an EPP 
connectivity test, the feasibility of locating EPP servers in Japan to 
interface with the registry database in North America. If the research is 
successful, Sentan expects to utilize the EPP/RRP servers for this purpose for 
an innovative solution to providing geographic network coverage for SRS sites. 

Ultimately, this may prove to be the way registries operate in the future to 
meet the needs of their customers. In addition, this may make it more cost 
effective and feasible for registrars to operate in growing and emerging 
markets. Poor Internet connectivity may impact the performance of a potential 
registrar's systems. Purchasing bandwidth to improve it may be too costly. 
Bringing the interface closer to those registrars may help them solve these 
problems. Registrars are an important aspect of the growth of the Internet. If 
there are more in more regions, the Internet has a better chance of growth in 
those regions. Enhanced competition is one of the direct benefits.  

3. WHOIS - COVERAGE AND SUPPORT
Most registries only provide 1 WHOIS site. NeuLevel has always provided 2 sites 
to support capacity and provide survivability. For .NET, Sentan will deploy 3 
sites--2 in North America and 1 in Japan. Putting a WHOIS server outside of 
North America will provide better service to some registrars located outside of 
North America, and it will also add capacity and an extra level of 
survivability. 

Placing WHOIS servers in both North America and Japan will provide better 
service to more growing and emerging markets--as users will evolve to the WHOIS 
that provides them better service.



(vii) Zone file generation including procedures for changes, editing by registrars and updates. Address frequency, security, process, interface, user authentication, logging and data back-up.

WHY SENTAN
· A commitment will provide 95% of updates in 10 minutes or less which is an 
improvement over "twice daily" updates required in the current .NET agreement 
in Appendix E

· Proven dynamic update capability

· Very strict user authentication which ensures a secure update process

· A Zone file audit process that performs a validation check on recent updates 
to ensure accuracy

· Innovative solution that utilizes remote regional master servers to speed the 
update process

1. INTRODUCTION
A registry must implement 3 zone subcomponents to provide DNS services:

· Generation (5.b.vii)
· Distribution (described in Part 2:5.b.viii)
· Resolution (described in Part 2:5.b.ii)

A registry operator may provide one of two mechanisms to generate a zone file. 
They may create incremental updates frequently (dynamic update) or create an 
entire zone infrequently (bulk update). This section describes both modes of 
zone generation, as well as mechanisms for the registry and registrars to 
update the zone by securely logging user authentication and data backups. 

2. PROCEDURES FOR CHANGES
NeuLevel, Sentan's registry operator, has been providing DNS and zone 
generation since 2001. NeuLevel has a proven architecture that supports both 
dynamic and bulk updates of the zone. 

2.1 DYNAMIC UPDATES
The benefits of dynamic updates of the DNS zone are significant. Given the high 
amount of growth and change in the Internet, the ability for registrants to 
purchase or update a domain and see those changes propagated to DNS in near 
real-time is of great advantage. Registries that support dynamic update of DNS 
have been around providing this service since the introduction of new gTLDs in 
2001. Until very recently, .NET customers have had to wait up to 12 hours 
before their changes were reflected in the .NET zone.

To build a dynamic update platform, a registry needs to build an infrastructure 
that will accurately: take new add, modify, or update changes; delete 
transactions performed by registrars in the SRS; and generate incremental 
updates. The generation of dynamic updates should be decoupled from the SRS to 
ensure that it does not adversely impact the provision of registration 
services. 

Exhibit 5.b.vii-1 depicts the zone file generation process and Exhibit 5.b.viii-
1 (shown in Part 2:5.b.viii) depicts the zone file distribution process.

· The zone administrator inspects the SRS database for new changes.
· The zone administrator collects the updates and then generates a dynamic 
update file.
· The update file is pushed to the primary master server.
· The primary master server loads the dynamic update file into its local copy 
of the zone.
· The primary master server validates that the increment is valid.
· The primary master server creates an update file and increments the serial 
number.
· The primary master server notifies the regional masters of an update.
· The regional masters request the new update file from the primary.
· The regional master than notify its slaves of an update.
· The slaves then request the update file from its master.
· The update file is updated in the zone file.

There are many benefits to this process. The primary master ensures that all 
changes are accurately processed in exactly the same order in which registrars 
submitted transactions to the SRS (ensuring accuracy of the zone). The regional 
master preserves valuable bandwidth and therefore results in faster updates. In 
addition, the secondary master receives the update file in the process to be 
prepared in case of an emergency. For more information on zone file 
distribution, please see Part 2:5.b viii.

2.2 BULK UPDATES
Until very recently, the generation of entire zones during bulk updates has 
been the norm for .NET. While the newer registries, including NeuLevel, have 
the capability to generate a new bulk zone file: NeuLevel only uses bulk 
updates to make the zone available for download and to serve as a method of 
backup in a disaster recovery scenario.

3. EDITING BY REGISTRARS AND UPDATES
Registrars update the zone via the SRS. This is both the most efficient and 
most secure way of updating the zone file. Registrars interface via EPP or RRP 
to the SRS to add, change, and delete domains, nameservers, and IP Addresses. 
Domain and host information is then pulled into the dynamic generation process 
described above.
 
4. FREQUENCY
NeuLevel's current SLA for dynamic updates is 95% of all updates performed 
within 15 minutes. The following table demonstrates their reported up-to-15 
minutes dynamic update percentages for the third and fourth quarters of 2004. 
Please see Part 2:5.b.xv, System Reliability, where Sentan proposes to increase 
this SLA from 95% within 15 minutes to 95% within 10 minutes. We are able to do 
this based on improvements engineered (by NeuLevel) during the fourth quarter 
of 2004.

MONTH           UPDATES
July		 97.449%
August		 99.759%
September	 99.582%
October		 97.106%
November	         96.361%
December	         100.00%	

5. SECURITY
Updates to the SRS database, which is the only channel for 
registrars/registrants to change zone files, can only happen via registrars 
performing add, change, and delete transactions via the SRS protocol server. 
The protocol servers are protected by a combination of:

· Connection limiting via a Packet Shaper;
· IP monitoring via firewalls;
· TLS certificates;
· UserIDs; and
· RSA SecureIDs.

Please see Part 2:5.b.i for more detailed information on the SRS. 

The incremental zone file updates are sent via secure VPN connections to the 
nameservers. There are 2 layers of security at both the SRS and the nameserver. 
Each VPN is protected by IPsec and a firewall. Our publicly available zone file 
for download is secured by SSH on a file server. Only registered users are 
allowed to download the zone.

6. PROCESS
The generation of dynamic update is controlled by a process that monitors the 
SRS for changes that need to be propagated to DNS. All changes to the SRS are 
initiated by registrars on behalf of registrants.  The incremental zone 
generation creates an incremental update file that is signed with a serial 
number that is used for tracking purposes.

NeuLevel's DNS infrastructure is in full compliance with all DNS RFCs. Each 
nameserver correctly implements the IETF standards for the DNS (RFC1035, 
RFC1995, RFC1996, RFC2136, RFC2181). They have also implemented all applicable 
best-practice recommendations contained in RFC 2870 and RFC2182.

7. INTERFACE
As discussed previously, there are 2 processes that interface with the SRS 
database to generate either an incremental zone update (IXFR) or an entire zone 
file. Both processes are java applications that use standard Java Database 
Connectivity (JDBC) access to the SRS database. The zone administrator then 
uses IXFR transactions to pass updates to the centralized master.

8. USER AUTHENTICATION
The SRS follows best practices in regards to security. There are only 2 methods 
in which changes occur in the zone. The first and most common method is via the 
SRS and dynamic update. In addition to the SRS, Sentan's customer support team, 
using the Registrar Administration Tool (RAT), may affect changes in the SRS.

All domain and host changes are then pulled into the dynamic zone generation 
process discussed above. The RAT tool has 2 levels of authentication:

1. User must be pre-registered in the SRS with proper privileges.
2. Registered users must pass website authentication using RSA SecureID. 

The second method, bulk update, is only used under emergency situations such as 
disaster recovery. Only members of the registry technical staff have access to 
process a bulk update, prior to pushing any changes to the DNS. 

In the rare circumstance where a bulk update is required, members of the DNS 
technical staff perform it. Access to the zone file by a User (NeuLevel 
internal resource) is tightly controlled by the application of an 
authentication and authorization approach. It is worth noting, an authenticated 
and authorized user may be a person or an application. There are 3 types of 
users--all with varying levels of authentication and authorization--users, 
groups, and super users. When it comes to generating changes, NeuLevel uses the 
following authentication and authorization tools and processes:

· User-account security--Establishes the access capabilities of a specific 
authenticated user. After authenticating a user, each application's security 
data tables control access to information. Access is based not only on UserID, 
but also on the type of application being used. The application server uses 
UserID to provide precise control of access privileges to - and uses of (read, 
write, execute) - all system resources: screens, menus, transactions, data 
fields, database tables, files, records, print facilities, tape facilities, 
software tools, and software executables.

· Group-level security--Establishes the access capabilities of all users within 
a specific group. All users belong to one or more access-control groups. Access 
control is identical to that for individual users.

· System administration-level security--Restricts access to system 
administration tools, including the ability to change resource-access 
privileges. NeuLevel system administration staff use dedicated links on an 
internal LAN/WAN to access administrative functions that are off limits to 
others. There is no external access to this management LAN. All sessions 
require user identification by user name and password. Access control lists 
then determine what resources a user or user group is allowed to access and 
use. Super-user access is managed through an auditable delegation system. The 
router at the backend of the environment manages all normal management traffic.

· Hardened operating systems - Hardened operating systems have all but the most 
necessary services either disabled or removed. This hardening makes it 
extremely difficult for a user, authorized or unauthorized, to intentionally or 
unintentionally impact the system. Essentially, if the services with 
vulnerabilities are removed or disabled, it becomes very difficult to exploit 
the weakness.
 
· Tripwire - The critical core of Name Server environment is protected against 
tampering by an application (Tripwire) that monitors all core aspects of the 
environment. Tripwire is capable of alerting on unauthorized change and even 
executing a rollback to the approved configuration if a change is detected. The 
health of the nameserver environment is monitored 24/7/365 by a centralized NOC.

9. LOGGING
Each component in NeuLevel's SRS provides audit logs with enough detail to be 
able to track down any changes to the zone. For instance, all write 
transactions to the SRS are logged to persistent audit tables. Their audit 
tables give them a complete history of changes requested by registrars to 
affect changes in the DNS zone. The zone administrator also logs to a file as 
it processes DNS work items from the SRS and passes incremental update files to 
the centralized master.

10. DATA BACKUP
Please see Part 2:5.b.x for detailed information on NeuLevel's data backup 
processes. The SRS database, which contains all DNS zone data, is backed up to 
the secondary data center in Charlotte, NC, USA, the disaster recovery site in 
Tokyo, and to tape. All log files are backed up daily to an archive server that 
is then backed up daily to tape.

11. MONITORING
To ensure that each DNS slave is updated and synchronized, NeuLevel actively 
monitors their DNS infrastructure. During the update process each incremental 
zone update is signed with a new serial number. They have automated alerts, via 
a state-of-the-art Network Monitoring System (NMS), that monitors and ensures 
each and every slave is updated within a reasonable amount of time and that the 
updates are synchronized. 

In addition, they also monitor each subprocess in their infrastructure. Should 
any one process have a problem, an alert is generated and investigated by their 
24/7/365 NOC.

For validating the accuracy of zone data, NeuLevel is deploying a zone file 
accuracy audit system. It will compare data in the zone file to data stored in 
the SRS. Thorough auditing, at the data level, to ensure that the SRS and the 
DNS slaves are in sync is not a trivial exercise but one that should be 
standard operating procedure for all registries.

The system for zone file accuracy audit processing will work as follows:

· Receive updates from the master server;
· Perform a query on the name to the .NET zone file;
· Query the .NET SRS database for the same name;
· Compare the data received from the zone file with that was received from the 
database; and
· Generate an alarm if there is a mismatch.

This process will run constantly and include both recently added or modified 
names, as well as random names selected from the SRS database. 

12. CONCLUSION
DNS and DNS zone generation are critical to the operation of the .NET registry. 
Our technical operator, NeuLevel, is a proven provider of DNS services. They 
have been providing dynamic updates for the last 3 years. In addition to 
providing dynamic updates, they also recognize that unexpected issues can and 
do arise. They therefore have implemented extensive monitoring that sends 
alerts to their 24/7/365 NOC. The NOC then coordinates their "Incident Response 
Team" to solve the problem. Security is a major priority at NeuLevel. They use 
a combination of tools to secure the registry and zone files. In addition, both 
Sentan, and its parent companies, are committed to the furthering stability of 
the Internet. To this end, we are strong supporters of the Internet Systems 
Consortium (ISC) and the evaluation of DNSSEC.



(viii) Zone file distribution and publication. Locations of name servers, procedures for and means of distributing zone files to them.

WHY SENTAN
· Innovative architecture which utilizes a tiered solution for updates

· Introduction of Synchronized WHOIS and DNS to .NET--users will benefit from 
their information being displayed more rapidly

· More aggressive commitments--95% of updates performed in 10 minutes or less; 
down from 15 minutes

· Increased stability through 3 geographically distributed, load-balanced WHOIS 
sites

· WHOIS site located in Asia

1. INTRODUCTION
To provide DNS services, a registry must implement three zone subcomponents.

1. Generation (Part 2:5.b.vii)
2. Distribution
3. Resolution (Part 2:5.b.ii.)

This section discusses the distribution of the zone file. NeuLevel, Sentan's 
technical operator, has an existing dynamic infrastructure that is built upon 
BIND, customized and optimized for performance, monitoring, security, and 
operations of a gTLD. Powered by NeuLevel, Sentan's solution provides .NET not 
only with world-class dynamic updates of DNS; but for the first time, .NET 
users will also benefit from synchronized WHOIS and DNS in that their 
information is displayed more rapidly.

2. NAMESERVER LOCATIONS
Sentan will provide the .NET community with a vast, globally distributed DNS 
constellation that is available 100% of the time.  NeuLevel will make use of 
Unicast and Anycast sites, organized in such a way that each site has 
overlapping service areas. These overlapping sites limit the potential for any 
one area of the world from being impacted by DDoS attacks on the network.

Please see Exhibit 5.b.vi-1 in Part 2.5.b.vi for the location of our 
geographically diverse sites.

3. PROCEDURES AND MEANS OF DISTRIBUTING ZONE FILES
NeuLevel has developed a state-of-the-art dynamic update facility. It uses the 
IXFR mechanism, as described in RFC 1995, to distribute incremental updates 
throughout the DNS constellation. Their DNS constellation is made up of a zone 
administrator, primary and secondary masters, regional masters, and DNS slave 
servers. The master servers perform the update to the DNS slave servers. The 
DNS slaves receive and respond to queries from the Internet.

Exhibits 5.b.viii-1 and 5.b.vii-1 depict the following zone file generation and 
distribution and publication process. Zone file generation process was shown 
previously in Part 2:5.b.vii. This section will discuss in detail zone file 
distribution.

· The zone administrator inspects the SRS database for new changes.
· The zone administrator collects, updates, and then generates a dynamic update.
· The update is pushed to the primary master server.
· The primary master server loads the dynamic update into its local copy of the 
zone.
· The primary master server validates that the increment is valid.
· The primary master server creates an update and increments the serial number.
· The primary master server notifies the regional masters of an update.
· The regional masters request the new update from the primary.
· The regional masters then notify its slaves of an update.
· The slaves then request the update from its master.
· The update is updated in the zone file.

The secondary master acts as a backup to the primary master and is located in 
the backup SRS site. In the event that the primary master is down, the zone 
administrator will update the secondary master that in turn will update the 
slaves. The secondary always pulls updates from the master to keep a current 
copy of the zone file.

NeuLevel's experience in supporting a world-class DNS constellation has shown 
that the use of regional masters is the fastest and most efficient solution.  
Sentan's plan for .NET includes the use of the following regional masters:

· Sterling;
· San Jose;
· Charlotte;
· Singapore;
· London; and
· Tokyo.

To ensure the robustness of the dynamic update facility, each nameserver, 
whether it is the primary master, regional master, or slave, has one or more 
partners that can take over responsibility in the event of a hardware failure. 
This is accomplished by interconnecting all nameservers.

3.1 PRIMARY MASTER
The primary master is a nameserver that operates in the SRS site in Sterling. 
It is protected behind firewalls from the Internet. It receives incremental 
updates from the zone administrator, loads the increment, and sends 
notifications to the secondary master and all regional masters. The secondary 
master receives its updates over an internal dedicated line. The secondary 
master runs in NeuLevel's secondary recovery data center in Charlotte, NC USA. 
It is also protected behind firewalls from the Internet. Should the primary 
master become unavailable, the secondary master will begin to receive updates 
directly from the zone administrator.

3.2 REGIONAL MASTERS
The regional masters each get their updates from the primary master. These 
updates are sent over secure VPN links using backend private IP Addresses. 
These machines are protected from the network by firewalls connected to the 
VPN, strict access control lists, and application layer firewalls on the 
servers. Each regional master acts as a backup to the other regional masters. 
If any one should fail, the other is able to take over. Likewise if they should 
all fail, highly unlikely given the number of them, the slaves will get their 
updates directly from the primary master. In the event that a regional master 
cannot receive an update from the primary master, it will try the secondary 
master. If, for some reason, it cannot communicate with either the primary 
master or the secondary master, it will try each of the other regional masters.

3.3 DNS SLAVES
The slaves receive their updates from the regional masters via private, back-
end IP Addresses over secure IPsec VPN links. The slaves are configured to 
first try their regional master for incremental updates. If it cannot 
communicate with its regional master, it will try the next closest regional 
master, then the secondary master, and finally the central master.

.NET users will benefit greatly from NeuLevel's existing dynamic zone update 
infrastructure that guarantees that 95% of all DNS-affecting SRS transactions 
are propagated to all slaves within 10 minutes. This capability, which, until 
very recently, was unheard of in the .NET community, gives the freedom to 
registrants to launch new web services and prevent down time of existing 
services much more efficiently then they are used to. 

4. WHOIS UPDATE
While dynamic update has recently been implemented in the .NET zone file, 
dynamic update to the WHOIS has not.  That means, for recent updates, the zone 
file and the WHOIS are frequently out of synch. With Sentan's solution, the 
WHOIS and the zone file will be updated at the same time ensuring that they are 
synchronized. This is a great improvement over the current operation of 
the .NET registry.

5. MONITORING
It is important that a registry operator have state-of-the-art monitoring. 
NeuLevel constantly monitors their DNS constellation along with all 
intermediate components involved in dynamically updating the zone. They employ 
many levels of monitoring from hardware analysis, network probes, update 
synchronization, and DNS response times from various locations throughout the 
Internet.

6. CONCLUSION
DNS and DNS zone generation are critical to the operation of the .NET 
registry.  NeuLevel is a proven provider of DNS services. They have been 
providing dynamic updates for 3 years. In addition to providing dynamic updates 
they also recognize that unexpected issues can and do arise. Therefore, they 
have implemented extensive monitoring that sends alerts to their 24/7/365 NOC. 
Sentan will bring synchronization of DNS and WHOIS to .NET.



(ix) Billing and collection systems. Technical characteristics, system security, accessibility.

WHY SENTAN
· An auto-renew billing process that provides material financial benefit to 
Sentan's primary customer: the registrar

· A credit card capability that provides payment flexibility to promote 
competition and support equal access

· B&C systems that are production-proven, stable, and trusted by over 150 
registrars using them today

· Web-based interface that will provide registrars with near-real-time 
visibility into changes in account balance

1. INTRODUCTION
Given the importance of financial operations, it is critical for billing and 
collections (B&C) systems to be robust, secure, and easily accessible by 
customers. Our technical operator, NeuLevel, provides Sentan's B&C systems 
using in-place, enterprise-class B&C systems that leverage years of expertise 
working with large and small registrars and other customers. The registry 
billing infrastructure is a proven robust platform for the operation of 
the .NET registry. The systems are secure, regularly audited, and are readily 
accessible by our customers via a web interface.

The B&C system for .NET will be anchored in the same registry billing 
infrastructure used for the operation of the .BIZ and .US TLDs. Having an 
operating B&C system is a distinct advantage when assuming responsibility for 
the .NET registry because financial relationships with over 150 of the global 
community of accredited registrars are existing.

Since 2001, NeuLevel's billing system has been a stable platform for its 
registry business. It has proven to be accurate, secure, scalable, and 
reliable. While quite proud of the robustness and capability of the B&C 
systems, Sentan believes it is a focus on customer service that sets these B&C 
operations apart from those of any other gTLD registry.

In the section below, we describe our B&C approach and the technical 
characteristics, system security, and accessibility of our B&C solution. We 
also describe the important and unique ways in which we focus on customer 
service and implement customer-friendly policies in this critical area. 

2. A FAMILIAR B&C APPROACH 
Sentan will maintain NeuLevel's existing B&C approach of the .BIZ registry. At 
no expense to itself, each registrar will establish a debit account with the 
registry's bank. Debit accounts will exist in a US-based bank. A registrar 
funds its debit account using either wire transfer or other standard means, 
taking responsibility for any applicable currency conversion and receiving a 
notice that confirms receipt of funds. As is standard in the industry, the 
registry transfers funds from registrar debit accounts to settle registrar 
accounts payable balances with the registry.

As an added service to registrars, Sentan will allow a registrar to store 
credit card information on file with the registry. For some registrars, this 
serves as the primary source of funds, while others use it as a back-up to the 
debit account. This approach, currently used by NeuLevel in its operations, is 
another example of the ways in which the principles of equal access and 
promotion of competition permeate our business processes. While not of 
particular import for larger registrars, NeuLevel has found that smaller 
registrars frequently use this capability to make payments.

Registrar charges will be accrued for successful transactions to create, renew, 
and transfer domain names for durations that vary between 1 and 10 years. Under 
standard grace period terms and conditions, credits will be granted for 
transactions to delete domain names. The B&C system supports all ICANN-standard 
grace periods, overlapping grace periods, and will support transactions that 
synchronize domain expiration dates.

If selected, NeuLevel's B&C systems will support all of these transactions and 
capabilities immediately upon Sentan fully assuming responsibility for .NET.

3. TECHNICAL CHARACTERISTICS
The B&C infrastructure is organized around a central server. This server 
operates the application software and database to store B&C data. Smaller 
servers that perform auxiliary functions of web access and reporting augment 
the central server. The systems have been architected for high capacity and 
high reliability.

The primary server is a 6-processor IBM p650 server with 12 GB RAM. NeuLevel's 
operational experience indicates that this capacity is adequate to handle .NET 
transactions of more than double their current rate. For extra capability, the 
server is scalable to 8 processors and 16 GB RAM. It currently has 14 146 GB 
disks (2.044 TB) that are configured in RAID 1+0 (mirrored stripes) for over 
800 GB of available capacity with extremely high I/O performance. Disk capacity 
(currently sufficient for 2 years based on current projections) can be added 
without causing server downtime. Secondary servers include 2 dual-processor 
Dell 2650 machines. These are used for a webserver (Red Hat Linux Advanced 
Server 2.1 running BEA Weblogic 8.1) and reporting server (Microsoft Windows 
2000 Server running Crystal Reports). These servers are also adequately powered 
and if load exceeds current projections, the software is easily portable to 
more powerful machines.

This infrastructure, which resides in NeuLevel's Sterling, VA, USA data center, 
is fully and completely duplicated at their backup data center in Charlotte, 
NC, USA. This provides full and complete redundancy. The primary database, 
running Oracle 9i, synchronously replicates its data using Oracle DataGuard to 
the backup database using synchronous replication to eliminate any opportunity 
for data loss.

The B&C software is the highly regarded PeopleSoft 8.8--a modular system. We use 
the Billing, Accounts Receivable (AR), and eBillPayment modules for registry 
billing. For financial systems, it is preferable to use an integrated suite of 
software to achieve accuracy and auditability. Stitching together an 
infrastructure using a variety of different systems results in a solution which 
is difficult to maintain and costly to test.

PeopleSoft operates using a database that is operated by standard Oracle 
database management software. The B&C database stores information for B&C 
services. Its contents include:

· Registrar billing profile--accessed and modified by the administration 
functions;
· Registrar account--queried, credited, and debited while processing 
transactions from registrars; and  
· Catalog--pricing information for different transactions, queried in the 
charging process.

Under typical operations, registrar account information is the type of 
information most frequently modified by the B&C software. Other information, 
such as the registrar billing profile and the catalog is typically read-only, 
with relatively infrequent modifications.

The following lists several of the design parameters and quantities that are 
relevant in sizing the B&C database:

Billable events per month:	  3 million
Transaction size: 	           249 bytes
Transactions per month:	           625 MB
Historical data for three months:    2 G
Total billing-data:	             3.5 G
Total data:	                    16.5 G
DBMS & logs:	                     4.5 G
Database indexing: 	              18 G
Total size:	                       83 G
Database throughput:	        TpsC = 4000

The current .NET database currently contains just over 5 million names. Our 
growth estimates predict the .NET SRS database will contain roughly 7.2 million 
domain names in June 2006. Using that data as a guide, NeuLevel has sized the 
billing database for 8 million names to ensure we not only have enough capacity 
for the transition in 2005, but room for growth as well. Our sizing model, 
which includes other factors that influence the quantity of billing events, is 
based on NeuLevel's operational experience with .BIZ and .US and provides us 
with adequate capacity even if actual volumes and/or transaction rates exceed 
current projections. See Part 2:5.b.v for more information.

4. SYSTEM SECURITY
Our B&C infrastructure is protected by NeuLevel's same dual-layer firewall 
system that protects the core registry database. However, given the extremely 
sensitive nature of the financial data it contains, we have established other 
special security measures. These include:

· Internal network segmentation to prevent access by unauthorized internal 
users and systems;
· Login access is granted only to the financial systems team; and
· Web traffic via Internet uses HTTPS.

While access to the web server obviously requires a login/password, the web-
based access (fully described below) is protected by an additional security 
mechanism. Please refer to Parts 2:5.b.iii and 2:6.c for more information 
security.

5. ACCESSIBITY
While it is essential that B&C systems be robust, accurate, and secure, it is 
also fundamentally important that customers have easy access to B&C 
information. Given the dynamic nature of the domain name business, registrars 
require exceptional access to accurate and timely billing information. It is 
critical that they know their account balance at all times because they operate 
on a debit system. In today's world, that means electronic access over the web. 
Highly accessible B&C systems are also an essential ingredient in equal access 
for registrars and are a tangible demonstration of a customer-focused service 
provided by the registry.

As indicated above, registrars have access to the B&C system through a web-
based interface. This interface contains two core capabilities: account/invoice 
review and electronic bill payment. Through the account/invoice review 
capability, registrars can access a wide variety of information, including 
current account status, historical invoice summaries, and invoice detail. 
Through the electronic bill payment mechanism, a registrar can pay outstanding 
invoices using a credit card.

Although linked at lower levels, the review and payment functions are protected 
by separate customer logins. This allows the ability to grant access to the 
commonly used review functions without granting access to the more sensitive 
ability to pay invoices, thus providing an important financial control for the 
registrar.

The web-based system also provides a capability to converse securely with 
registry B&C staff. Functioning similarly to many commercial online banking 
systems, this system maintains the messages in a secure data store, rather than 
flowing through unsecured email. All message data is encrypted using standard 
SSL (HTTPS) security.

In addition to these review and payment capabilities, Sentan, through NeuLevel, 
will also provide a tool that allows the registrars to generate a variety of 
reports on demand via a web interface. While built to satisfy a broad set of 
registrar needs, these reports will also be useful to registrar finance 
personnel. This reporting service, which is provided on the principle of equal 
access, is fully described in Part 2:3.a.

These reports are in addition to the electronic monthly statements that we will 
submit to registrars. These statements are provided in both Portable Document 
Format (PDF) and a detailed listing of all transactions in a comma-separated 
(CSV) file formats. The CSV file is in a consistent format that is suitable for 
being imported into a registrar's internal systems.

6. INDUSTRY-LEADING BILLING POLICIES AND CUSTOMER FOCUS 
Thus far, this section has focused on the technical aspects of our B&C 
capability. However, it is our B&C operations and policies that truly 
distinguish Sentan.

During 2004, our technical operator, NeuLevel, made 2 significant improvements 
to the billing operations. First, the frequency of billing runs was increased. 
Previously, billing data was gathered and posted daily. This frequency was 
increased to 4 times daily. These improvements allow registrars to more closely 
manage cash by providing greater visibility into their debit account position.

For .NET, this will be further enhanced, flowing transaction information to the 
billing website within 15 minutes on average. This will allow registrars even 
greater visibility into their cash position. Additionally, the B&C systems do 
not automatically disable a registrar's ability to purchase domains via the SRS 
if a registrar's cash balance falls below a certain threshold. We believe that 
part of developing a business relationship with a registrar is to have 
collaborative approach to accounts receivable; thus our policies require 
specific management approval to disable a registrar account due to lack of 
funds.

The second improvement occurred when .BIZ became the first gTLD registry to 
bill for auto-renewals at the end of the auto-renew grace period, rather than 
at the beginning. While perhaps it might appear that this is a trivial change, 
the financial impact for many registrars was quite significant. The reason for 
this lies in the auto-renew process. When a domain in the registry expires, it 
is automatically renewed. If the registrant does not elect to renew the name 
within 45 days of auto-renewal (the "auto-renew grace period"), the registrar 
can delete the name at no cost. Previously, the registrar was billed for the 
renewal immediately when the name was auto-renewed. But if the registrant 
declined to renew the name and the name was deleted within 45 days of auto-
renewal, the registrar was credited with a refund. This means that for a name 
that was deleted within the auto-renew grace period, the registry held the 
registrar's funds from the time of auto-renew until the time of delete.

While the amount of cash at stake varies greatly between registrars of 
different scale, the cash flow impact is material for each registrar. For 
example, as part of the regular turnover in the .BIZ registry, on average 
15,000 auto-renewed names per month are deleted within the auto-renew grace 
period. Under the more favorable auto-renew billing policy, this amounts to 
nearly US$100,000 per month that registrars are able to use. Other gTLD 
registries, using traditional policies, are requiring registrars to provide an 
interest-free loan to the registry for such names. The bigger the registry... the 
bigger the ongoing interest-free loan by the registrars.

Response to this unilateral change from the registrar community has been 
overwhelmingly positive. Yet we note that as of the date of proposal 
submission, .BIZ remains the only gTLD registry with this policy and Sentan 
will be able to leverage this for the registrars benefit (indeed, no other gTLD 
registry has even announced such an approach, much less implemented it.).

Sentan will bill .NET auto-renew transactions under the registrar-friendly 
policy described above. This B&C policy is an important and practical factor in 
both providing equal access and promoting competition, because it lowers the 
cash requirements for registrars, allowing them to focus financial resources on 
growing their businesses.

The B&C systems will be specially configured to handle the unique billing 
circumstances surrounding a transition of this nature.  In particular, the 
system will be modified to handle grace periods that extend through the cutover 
period. This unusual situation is explained in more detail in Part 2:8.1.

(x) Backup. Describe frequency and procedures for backup of data. Describe hardware and systems used, data format, identity of suggested escrow agent(s) and procedures for retrieval of data/rebuild of database.

WHY SENTAN
· Additional disaster recovery SRS site provides even stronger backup 
capabilities

· Zero-downtime/zero-impact incremental data backup each day

· Online Business Continuity Volume (BCV) disk copy of the database provides 
extra stability and protection

· Escrow agent, Iron Mountain, is the largest records and information 
management company in the world

1. INTRODUCTION
The ability to perform regular data backup is of paramount importance in 
operating the .NET registry. Backups must be done in a manner that minimizes 
potential data loss, and ensures easy, accurate, and timely retrieval and 
restore capability in the event of a hardware or software failure. 

Given the potentially devastating effects of such a failure, Sentan will take 
all steps necessary to avoid ever having to utilize its recovery plans. 
Sentan's first line of defense against data loss is its highly secure, 
redundant registry infrastructure (provided by NeuLevel). Responsible 
operations, however, require a recovery plan.

Comprehensive data recovery procedures address both small-scale failures, as 
well as more serious total system failures. The goal of any data backup and 
recovery procedure is full recovery from failures, with complete data integrity 
and minimal-to-no data loss. Data backup strategies handle system hardware 
failures (e.g. loss of a processor or one or more disk drives) by reinstalling 
the data from daily backups, supplemented by the information on the "before" 
and "after" image-journal backup files that the database creates. More serious 
failures require more aggressive solutions.

The customary strategy for guarding against loss of an entire facility because 
of natural or man-made disaster is to provide offsite escrow of the registry 
data in a secure storage facility. Sentan provides offsite escrow with Iron 
Mountain, the largest records and information management company in the world 
(see Part 2:5.b.xi for more information on Sentan's data escrow solution). 

Even when successful, this recovery strategy does not always prevent the loss 
of a certain volume of transactions between the time the data was backed up and 
the occurrence of the disaster. Users are subject to loss of service during the 
time required to recover the data center database and/or re-establish 
operations at an alternate disaster recovery site. Relocating the data center 
normally requires at least 24 hours, and the escrowing of full backups are done 
only weekly, meaning that a disaster could result in substantial loss of both 
services and data. The recovery from daily incremental backups requires 
additional recovery time, yet reduces the risks for data loss.

In order to address these deficiencies, Sentan's solution utilizes 3 SRS data 
centers operating in a primary/secondary/disaster recovery mode. Both the 
primary and secondary SRS data centers are capable of handling the entire 
workload should a major system failure or natural or man-made disaster occur at 
the other. The transactions from the active data center are replicated to a hot-
standby database at the secondary SRS data center over two dedicated DS-3's. 
For the disaster recovery site, daily incremental batch data updates are sent 
using Oracle Data Guard via a secure VPN connection. This connection is 
available from both the primary site in Sterling, VA, USA and the secondary 
site in Charlotte, NC, USA ensuring the disaster recovery site located in Tokyo 
is updated regardless of whether the registry is running at the primary or 
secondary site. The connection is always active with 750K bandwidth.

The active SRS data center conducts full database snapshots from a third mirror 
of this data twice a day and backs up all database transaction logs, as 
described in the following section. Since the primary and secondary SRS data 
centers are synchronized, our backup strategy maintains continuity of 
operations and enables full recovery of all transactions, even in the event of 
multiple hardware failures. Further, in the event of a natural or man-made 
disaster that affects both primary and secondary data centers simultaneously, 
our disaster recovery SRS location in Tokyo can be ready to handle normal .NET 
traffic within 24 hours.   

2. FREQUENCY AND PROCEDURES FOR DATA BACKUP
Sentan creates a third BCV copy of the database to offer the highest level of 
stability. The BCV copy is used to perform daily business operations such as 
creating backup and Linear Tape Open (LTO) tape copies of the database. This 
architecture allows for the second mirrored copy of the database to be utilized 
solely as an online disk version of the primary database. The BCV copy is 
created and used in the following manner:

· In addition to the primary .NET database, there is a second mirrored copy and 
a third BCV copy made--all on disk.  The BCV is cut twice daily, 12 hours apart.

· The BCV copy is available online for a period of 7 days. The online 
availability of the backup allows for database restoration in minutes in the 
event of a database failure.

· Backup software, which is located on a backup server independent from the 
application servers, creates the backup LTO tape copy from the BCV copy.

· Backups are performed in both full (weekly) and incremental (daily) modes.

· When the backup is finished, the LTO tapes are transported to Iron Mountain, 
the secure, offsite facility on a weekly basis.

In addition to the 3 copies of the .NET database, NeuLevel will perform the 
following backup operations on:

· .NET database - The primary  SRS data center implements a zero-downtime/zero-
impact incremental data backup each day, and a zero-downtime/zero-impact full 
data backup weekly.

· Static data - Software for applications such as the operating systems, BIND 
software, and applications software are copied to CD-ROMs for quick reload, 
should it become necessary.

· Dynamically changing file - Files such as log files vital to system 
maintenance and operation, database files, database-journal files, and software 
configurations are copied to high-capacity LTO.

· WHOIS and billing databases - Copied to LTO tapes weekly.

· Escrow - We place the backup tapes in a secure offsite storage facility 
operated by Iron Mountain. 

3. BACKUP HARDWARE AND SOFTWARE SYSTEMS
Exhibit 5.b.x-1 depicts the SRS data centers' backup process. Each data 
center's system includes 2 backup servers with LTO robotic tape libraries, 
using high speed LTO II drives. To achieve zero-downtime/zero-impact backup, 
NeuLevel uses a RAID disk array and a high-speed fiber channel bridge 
interconnect to the robotic tape libraries. The backup server copies not only 
the database server's backup files to the disk array, but also the backup files 
of the cluster servers. During the few minutes this process requires, 
applications still have access to the cluster servers and database server. 
Finally, the backup server copies the files to the LTO robotic tape device. 
This approach ensures Sentan meets its Service Level Commitments. A list of 
backup systems' hardware and software is provided below.

BACKUP SYSTEMS DESCRIPTION
---------------------------------------------
Backup System - Database server cluster
Hardware - IBM p570
Software - AIX 5.2

Backup System - High Performance Disk Storage
Hardware - EMC DMX 800
Software - EMC firmware

Backup System - Backup Server
Hardware - IBM P650
Software - HP Data Protector

Backup System - Fiber Switch
Hardware - McData DS62M
Software - McData Software

Backup System - Robotic Tape Library
Hardware - StorageTek L700 w/HP LTO Drives
Software - StorageTek Software

4. DATA FORMAT
Backups of the SRS databases are done using Oracle backup utility.  The backup 
utility makes a copy of the Oracle data files while they are in a consistent 
state.  The database is placed in backup mode, and a backup file is created, 
which is in proprietary Oracle format.   The backup file is then copied to its 
destination location and/or tape.  The following are the data elements that are 
part of the backup process.

.NET Backup Data Elements

Domain - All domain data including nameserver reference, contact reference, 
registrar references, statuses, and historical data.

Nameserver - All nameserver data including IP addresses and histories

Contact - All contact data for registrants, administrative, technical, and 
billing contacts.  This also includes histories.

Registrar - Registrar profile data.

Billing - Billable transaction data.

WHOIS - WHOIS update transactions.

DNS - DNS update transactions.

5. IDENTITY OF ESCROW AGENT
Sentan will also provide offsite escrow with Iron Mountain, Inc., the largest 
records and information management company in the world.  More detail about 
Sentan's escrow approach is presented in Part 2:5.b.xi.

6. PROCEDURES FOR RETRIEVAL OF DATA/REBUILD OF DATABASE
On behalf of Sentan, NeuLevel will maintain an online plus three-tape rotation 
to maximize efficiency and effectiveness:
 
· One online BCV backup available for a full database restore within minutes;
· One LTO backup tape in transit to Iron Mountain, our secure offsite escrow 
facility;
· A second LTO tape in storage in the secure escrow facility; and
· The third LTO tape in the active data center for reuse.

The full backup tapes are maintained in a 2-tape rotation, with 1 tape at the 
secure escrow facility and 1 at the active data center for reuse. A copy of the 
static-data CD-ROMs for the operating systems and applications are also 
maintained at Iron Mountain.

In the event of a site outage at the primary data center, service will failover 
to the back-up data center. The back-up data center will have a current copy of 
the .NET database due to the synchronous data replication process. The back-up 
data center will assume the primary data center's role and continue SRS 
operations with near-zero downtime. The following steps will be taken to 
restore the primary data center:

· Retrieve and restore physical data backup and archive logs from online BCV;
· If online is not available, retrieve the full and incremental back-up LTO 
tapes from active data center;
· Restore the full files;
· Restore the incremental files;
· Synchronize the recovered database from the back-up data center; and
· Restore the primary data center to operations.

This backup procedure enables Sentan to meet service-level agreements required 
for continuous availability and near-zero unplanned downtime, maintaining 
stability, enhancing public confidence, and improving customer satisfaction. 
These procedures are tested by NeuLevel, at the secondary SRS data center twice 
per calendar year during normal maintenance cycles. This testing ensures the 
process is tested and repeatable, and minimizes the risk of failure during a 
real disaster situation.



(xi) Escrow. Describe arrangements for data escrow, or equivalent data backup security, data formats, insurance arrangements and backup plans for data recovery.

WHY SENTAN
· Data will be in XML format for accurate and quick recovery

· Off-site escrow performed by Iron Mountain, the world's largest data 
management company

· Data will be provided to ICANN upon request

1. INTRODUCTION
Proper escrow arrangements, including adequate insurance, must be outlined and 
adhered to for the protection of ICANN and the .NET community. Data escrow must 
be performed in a manner which:

· Protects against data loss;
· Follows industry best practices
· Ensures easy, accurate and timely retrieval and restore capability in the 
event of a hardware failure
· Minimizes the impact of software or business failure. 

The customary strategy for guarding against loss of an entire facility because 
of a disaster, man-made or otherwise, is to provide off-site escrow of the 
registry data in a secure storage facility. NeuLevel, Sentan's primary 
technical operator, provides off-site escrow with Iron Mountain, Inc., the 
world's largest records and information management company.

2. ARRANGEMENTS FOR DATA ESCROW
As mentioned above, NeuLevel has contracted with Iron Mountain, Inc. to provide 
neutral escrow services. NeuLevel's data escrow solution is in full compliance 
with existing ICANN contractual procedures. NeuLevel prepares a full data set 
for one day of the week (designated by ICANN), and incremental data sets for 
all 7 days of each week. Full and incremental data sets are up-to-date and 
coherent as of 1200 UTC on the day to which they relate. 

On behalf of Sentan, NeuLevel will prepare and transfer the escrow deposit file 
by taking the following steps, in sequence:

· The file making up the escrow deposit is created according to the format 
specification below. The file is named according to the following 
format:  "netSEQN" where "SEQN" is a four digit decimal number that is 
incremented as each report is prepared. (Example: NET0001 NET0002 NET0003 etc.)

· The file is processed by a program provided by ICANN that: verifies it 
complies with the format specification and contains reports of the same 
date/time (for a full deposit), counts the number of objects of the various 
types in the deposit, and appends to the file a report of the program's 
results. If the file is large, it will be split using the UNIX Split command 
(or equivalent) to produce files no less than 1 GB each (except the final 
file). If the file deposit is split, an MD5 file (produced with MD5SUM or 
equivalent) is included with the resulting files to isolate errors.

· The file is then encrypted using GNU PGP and digitally signed.

· The file is transmitted to Iron Mountain using SSH via a secure FTP server at 
NeuLevel to a secure FTP server at Iron Mountain.

· Iron Mountain sends a notification that the file was received, digitally 
signed, and moved to a non-publicly accessible directory. If these are multiple 
files, they will be concantenated in sequence.

· Iron Mountain then decrypts the file, runs a program on the deposited file 
that; splits it in to its constituent reports, checks its format, counts the 
number of objects of each type, and verifies that the data set is internally 
consistent. This program will also compare its results with the results of a 
registry-generated format report and will generate a file deposit format and 
completeness report.

· The decrypted deposit file will be encrypted using GNU PGP, and the decrypted 
file is destroyed to reduce the likelihood of data loss to intruders in case of 
partial security failure.

· These data sets are available for download no later than 2000 UTC on the day 
to which they relate.

3. ESCROW DATA FORMAT
Each full and incremental data set consists of an XML document meeting the 
content and format requirements outlined in the table below. Once the XML 
document is generated, it is placed in a file named according to the following 
convention:

· For full data sets:  "wfYYMMDD" where "YYMMDD" is replaced with the date 
(YY=last two digits of year; MM=number of month: DD=day; in all cases, a single-
digit number is left-padded with a zero). 

· For incremental data sets: "wiYYMMDD" where "YYMMDD" follows the same format 
as for full data set.

.NET Escrow Data Format

Domain object
· Domain ID
· Domain Name
· Sponsoring Registrar
· Domain Status
· Registrant Identifier
· Contact Identifiers for Administrative, Technical, and Billing Contacts
·  Nameservers associated with This Domain
· Child Nameservers Registered in This Domain
· Domain Created by Registrar
· Domain Last Updated by Registrar
· Domain Registration Date
· Domain Expiration Date
· Domain Last updated date
· Domain Last Transfer Date
· Domain Authorization Information
· Additional Fields (Registrar Specified)

 Nameserver Object	
· Nameserver ID
· Nameserver Name
· Nameserver Status
· Nameserver Association Status
· Nameserver IP Addresses (if applicable)
· Sponsoring Registrar
· Created by Registrar
· Nameserver Creation Date
· Namer Server Last Updated Date
· Nameserver Last Transfer Date
· Additional Fields (Registrar Specified)
· Nameserver Authorization Information

Contact Object	
· Contact ID
· Contact Name
· Contact Status
· Contact Association Status
· Contact Organization
· Contact Address, City, State/Province, Country
· Contact Postal Code
· Contact Phone, Fax, E-mail
· Sponsoring Registrar
· Created by Registrar
· Contact Creation Date
· Contact Last Updated Date
· Contact Last Transfer Date
· Contact Authorization Information
· Additional Fields (Registrar Specified)

Registrar Object
· Registrar ID (registry specific)
· Registrar Object Identifier (Unique object identifier)
· Registrar ID (conforming to the IANA registrar-ids registry)
· Contact of Registrar
· Registrar Name
· Registrar Address, City, State/Province, Country
· Registrar Administrative Contacts
· Registrar Technical Contacts
· Registrar Billing Contacts
· Registrar URL
· Registrar Creation Date
· Registrar Last Updated Date
· Registrar Authorization Information
· Registrar Account Information

In addition, incremental data sets contain notations of deletion of objects 
since the last incremental data sets. (see below)

.NET Notations of Object Deletions
-----------------------------------------------------------------------------
Del-domain:		domain:sNameType
Del-nameserver:          host:sNameType
Del-contact:		contact:sIDType
Del-Registrar:		WHOISdb:registrarIDType

Full data sets include one domain object for each domain name within the 
registry TLD; and  nameserver, contact, and registrar object for each 
nameserver, contact, and registrar referred to in any domain object.

Incremental data sets consist of:

· Those of objects constituting a full data set that have been added or updated 
since the last incremental data set; and

· Notations of deletion of any objects since the last incremental data set.
  
Full and incremental data sets are in XML version 1.0, UTF-8 encoded documents.

4. INSURANCE ARRANGEMENTS
The importance of committing to, and maintaining, ample insurance from a 
reputable insurance provider cannot be overstated. Through NeuLevel, Sentan 
already enjoys the same comprehensive insurance that currently covers NeuLevel. 
NeuLevel has, and Sentan will contractually commit to maintaining, the highest 
insurance coverage in the industry. This not only includes US $15,000,000 in 
comprehensive general liability insurance from a reputable insurance provider 
with an A.M. Best rating of "A", but also ample Directors and Officers, 
Technology, Commercial Crime and Fiduciary Liability Insurance. Sentan's 
current insurance providers include the Chubb Corporation, National Union 
Insurance Company, Gulf Insurance Company, and ITT Hartford Insurance Company.

5. BACKUP PLANS FOR DATA RECOVERY
It is important to point out that as a "thick" registry, Sentan's escrow data 
will ensure the most safe and secure solution in the unlikely event the 
registry should cease operations. In this instance, ICANN will have all the 
data necessary, including registrant information, to guarantee that the 
registrant-to-domain name relationship is not lost. In a thin registry, if a 
registrar were to cease operations prior to transferring the domain names to a 
new registrar, it would be impossible for the registry or ICANN to associate 
these domain names with their rightful owners. However, under a "thick" 
registry model where registrant data is held in a secure central database at 
the registry level, there are 3 highlevel approaches to backup. There will be 
three copies of the registry database available for data recovery:

· Online backup--there will be an online backup at the Sterling SRS site which 
can be loaded into the production database in minutes if there is a need for 
data recovery.

· Secondary SRS site--there is a database that is constantly being replicated at 
the secondary SRS site in Charlotte, North Carolina, USA. In the event that the 
production database is impacted, all SRS transactions can be performed on the 
Charlotte database with no reduction in service. This allows adequate time to 
restore the database at the Sterling site.

· Escrow--As mentioned in this section, the registry has access to a copy of the 
database at Iron Mountain, Inc's escrow site. In the unlikely event that the 
first two options for data recovery are not available, we can use the escrow 
database to restore the production database.

· Disaster Recovery SRS Site - there is a replicated database at the disaster 
recovery SRS site in Tokyo, Japan.  In the event there is an outage at both the 
primary and secondary sites, the SRS and transactions can be performed at the 
Tokyo site until service is restored.

(xii) Publicly accessible WHOIS service. Address software and hardware, connection speed, search capabilities and coordination with other WHOIS systems. Frequency of WHOIS updates, availability and processing times. Identify whether you propose to use a “thick” registry model or “thin” registry model, and explain why you believe your choice is preferable.

WHY SENTAN:
· WHOIS service is production proven, highly flexible and scalable, with a 
track record of 100% availability over the past 2.5 years

· Exceeds current .NET WHOIS performance supporting dynamic updates with the 
capability of doing bulk updates in the case of unexpected emergencies

· WHOIS is geographically distributed in 3 sites to provide greater stability 
and performance

· Provides for added stability of .NET with thick data but with the flexibility 
to display thin data

· Protects WHOIS data from data mining using proven technologies

· Provides additional search capabilities (e.g. IDN, registrant data)

· Commitment to provide the Internet Registry Information Service ( IRIS) as 
described in RFC 3981 and 3982
	
1. SOFTWARE
Powered by NeuLevel, Sentan's WHOIS is distributed, flexible, scalable, and 
stable; with a history of near real-time dynamic updates and no outages. The 
design and construction is agnostic with regard to data display policy. It is 
flexible enough to accommodate thin, thick, or modified thick models, or 
indeed, any potential future ICANN policy (such as different information 
display levels based on user categorization). Shown in Exhibit 5.b.xii-1, the 
WHOIS architecture comprises the following components:

· WHOIS Service - The WHOIS service is responsible for handling port 43 
queries. Our WHOIS is optimized for speed using an in-memory database. This 
architecture was developed to exceed NeuLevel's current .BIZ SLA of 95% of all 
queries responded to in less than 1.5 seconds. Please see section 5.b.xv for a 
more detailed discussion on Service Level Agreements.

Our WHOIS service also has built-in support for IDN. If the domain name being 
queried is an IDN, the returned results include the language of the domain 
name, the domain name's Unicode HEX representation, and the Unicode's HTML 
encoding.

Web WHOIS page - The web based WHOIS allows Sentan to provide the following 
enhanced services in addition to those mentioned above.

a. Extensive support for international domain names (IDN)
1. Ability to perform WHOIS lookups on the actual Unicode IDN

2. An onscreen keyboard to assist users in typing Unicode characters such as: 
ö, ä, and ü.

3. Display of the actual Unicode IDN in addition to the ACE-encoded name

4. A Unicode to Punycode and Punycode to Unicode translator
b. An extensive FAQ
c. A list of upcoming domain deletions

We will also add translation of our WHOIS website into 9 languages. Please see 
Part 2:3.a and 5.xix for more detail.

Local WHOIS database - a local in-memory database is used in each WHOIS server. 
This optimizes the speed of lookup queries. In addition, the in-memory database 
is decoupled from the lookup engine which allows for efficient dynamic updates. 
This design also completely decouples the WHOIS service from the registration 
services.

Local update agent - is used in each WHOIS server to manage the update of the 
local WHOIS database. By separating the update process from the WHOIS lookup 
agent, we are able to optimize refresh times, while maintaining high 
availability for processing WHOIS queries.

Message queues - Guaranteed delivery message oriented middleware, MQ Series, is 
used to ensure each individual WHOIS server is refreshed with dynamic updates. 
This component ensures that all WHOIS servers are kept up to date as changes 
occur in the SRS, while also decoupling WHOIS from the SRS. By decoupling 
dynamic updates from the SRS, we are ensuring registration services are not 
overly tasked by WHOIS services. Meanwhile, decoupling distribution of dynamic 
updates from the WHOIS lookup engine ensures that WHOIS queries from the 
Internet are not over- tasked by updates.

Master update agent - is responsible for processing new WHOIS updates from the 
SRS database. This is the first step in pushing dynamic updates to the WHOIS 
servers. It processes small batches of updates that have been made to the SRS. 
Keeping this process external from normal SRS operations optimizes the speed of 
dynamic updates while not impacting the processing cycles of the SRS.

SRS database - is the main persistent store of the registry and the SRS 
Database maintains a history of WHOIS. The master update agent uses the SRS 
database to compute what WHOIS updates need to be pushed out. This near-real-
time process is the perfect balance between true real-time (instantaneous) and 
low frequency updates. True real-time would put extra processing needs on the 
SRS and affect the performance of registration services. In addition, customers 
have not expressed a need for such instantaneous updates. By using a dynamic 
update process, we are able to comfortably meet customer needs and our proposed 
SLA of 95% within 10 minutes.

2. HARDWARE
Each of NeuLevel's 3 geographically diverse WHOIS sites use:

· Firewalls, to protect this sensitive data; 
· Dedicated servers for MQ Series, to ensure guaranteed delivery of WHOIS 
updates; 
· Packetshaper for source IP address-based bandwidth limiting; 
· Load balancers to distribute query load; and 
· Multiple WHOIS servers for maximizing the performance of Sentan's WHOIS 
service.

Please see Part 2:5.b.i for a more detailed description of hardware facilities 

3. CONNECTION SPEED
NeuLevel's data centers provide 2 155 MB connections to the Internet using 
diverse carriers, and 2 diverse 45 MB connections between the primary and 
secondary data centers in Sterling, VA, USA and Charlotte, NC, USA, 
respectively. In addition the third WHOIS site in Tokyo, Japan will have 2 100 
MB connection to the Internet.

4. SEARCH CAPABILITIES 
Sentan's WHOIS service provides the following search capabilities from the web 
and command line WHOIS:

· Domain Name (IDN and ASCII);
· Registrar;
· Nameserver (host name);
· IP address (IPv4 and IPv6);
· Registrant Id; and
· Wildcard searches.

5. COORDINATION WITH OTHER WHOIS SYSTEMS 
As we transition .NET from a thin to thick data model, we will maintain a 
registrar WHOIS referral capability - i.e. while the registry WHOIS is thin, we 
will link users to registrar data. This is where some WHOIS clients will 
perform further WHOIS queries based on the WHOIS server that is listed with the 
text "WHOIS Server".

As specified in Part 2:5.b.xvii Sentan commits to deploy IRIS for .NET within 1 
year of the transition of the .NET TLD. We will work with the Internet 
community and ICANN to help the industry determine potential implementations of 
some of IRIS's richer features, i.e. its security capabilities. We also commit 
to indefinite ongoing support for the WHOIS protocol (in conjunction with IRIS 
implementation) as the community may require the WHOIS protocol throughout the 
term of the contract.

6. FREQUENCY OF WHOIS UPDATES 

Dynamic Updates
Sentan will improve the .NET operation through a dynamic update process that 
supports dynamic updates of WHOIS. NeuLevel has been successfully operating 
this dynamic system for three years. The architecture and performance provide a 
good balance between user needs and the preservation of SRS performance and 
stability. Many other registry operators perform bulk updates of their WHOIS 
every 12 hours. While a 12-hour frequency is easier to manage and implement at 
the registry level, it provides fewer benefits to registrars and the end users; 
primarily the currency of WHOIS data. In addition, our solution improves 
current .NET operation by ensuring DNS and WHOIS updates are synchronized. 
Failure to synchronize these 2 updates results in end-user confusion and 
increased customer support costs for registrars.

NeuLevel's architecture uses a workflow that decouples the update process from 
the SRS. This ensures SRS performance is not adversely affected by the load 
requirements of dynamic updates. It is also decoupled from the WHOIS lookup 
agent to ensure the WHOIS service is always available and performing well for 
users.

Bulk Updates
Through NeuLevel, Sentan will also perform bulk updates, primarily for purposes 
of disaster recovery. The bulk process would only be used in the event of a 
disaster, or if the dynamic update process failed.

7. AVAILABILITY 
Sentan commits to 100% WHOIS availability for the 3 load-balanced .NET sites. 
NeuLevel's production proven architecture, which has successfully operated for 
3 years, is designed to ensure high availability. To minimize service 
disruption, maintenance occurs on 1 machine at a time (note: few registries 
provide more than 1 WHOIS site).

8. PROCESSING TIMES 
Sentan's WHOIS is optimized for speed using an in-memory database. This 
architecture was developed to exceed our current .BIZ SLA of 95% of all queries 
responded to in 1.5 seconds or less. Please see Part 2:5.b.xv for a more 
detailed discussion on Service Level Agreements. 

As outlined below, NeuLevel has exceeded their SLA for WHOIS updates, query 
time, and availability for each month in the last quarter.
 
Month           Updates	         Query	         Availability
October	        99.529%	         100%	         100%
November	   100%	         100%	         100%
December	   100%	         100%	         100%

9. THICK-VS-THIN 
Sentan, along with its parent companies, is a strong proponent of the thick 
model as we believe its benefits significantly outweigh its potential 
disadvantages. The following summarizes our view of the pros and cons of the 
thick model data.

FEATURE 1 OF THICK MODEL--Centralized Storage of Contact Data 
PROS
· Increased stability of .NET. Thick model protects possible loss of data due 
to registrar system or business failure.

· Improves the domain transfer process due to improved compatibility of data 
fields between losing and gaining registrars. The advantages of improved 
transfers are: (i) enhanced competition as domain portability assists new 
registrars to enter the market; (ii) improved end-user satisfaction due to a 
fewer failed transfers; and (iii) reduced support costs for registrars. Better 
transfers also represent an improved implementation of ICANN policy.

· Permits a greater range of reports from registry to registrars (see Part 2: 
3a. `New Registry Services'). These reports will reduces costs for registrars, 
enhance competition and increase the quality of services provided by registrars 
to end-users.

· Places fewer limitations on the development of consensus policies (a thin 
model inhibits any potential policies that might require centralized, 
standardized TLD data).

· Improved data accuracy. During the transition phase from thin to thick 
models, we will use our WHOIS Contact Validator tool (see Part 2:3a. `New 
Registry Services') and other methods to improve the accuracy and completeness 
of data provided by registrars. As an example of `other methods', -- incomplete 
data fields will be flagged and reports sent to applicable registrars. 
Resulting improvements in data accuracy will have the following effects: (i) 
improved implementation of ICANN data accuracy policy; (ii) improved service 
from registrars to their end users, i.e. fewer instances of deletions due to 
non-receipt of renewal notices; (iii) reduced support costs for registrars due 
to a reduced incidence of end user queries, e.g. "I'm trying to contact a 
domain holder and the WHOIS data appears to be wrong".

· Creates audit trail of domain history. In the event of disputes between 
registrars the registry holds an audit record of historical data, including 
ownership data.

CONS
· Registrars need to send more data to the registry.
· Some registrars feel that this is a loss of control over their data.

FEATURE 2 OF THICK MODEL--Centralized Display of Contact Data 
PROS 
· A standard, centralized display is significantly more efficient for all users 
(including intellectual property and law enforcement users).

· Registrars do not need to maintain their own WHOIS. Their costs can be 
lowered by linking to the registry WHOIS (note: currently ICANN requires 
registrars to maintain their own WHOIS).

CONS
·	Provides centralized source for data mining.

Our analysis of these factors leads us to believe the thick model provides 
significant improvements for .NET operations and .NET customers. It 
significantly improves stability, enhances competition, enables policy 
implementation, and maximizes customer support, and may also reduce registrar 
costs.

The primary concerns regarding the thick model are a perceived loss of 
proprietary data by registrars and a centralized source for possible data 
mining. To mitigate these potential problems with the thick model, we will 
implement the following actions:

Proprietary Data. We make an iron-clad commitment to the security and 
confidentiality of customer data. This neutrality is the fundamental business 
principle of our parent companies and is also a fundamental principle of 
Sentan. We back this up with a willingness to accept all ICANN requirements 
with respect to the security and confidentiality of registrar data. We also 
propose neutrality audits (please see Part 2:2.a) 

There are 2 popular methods used to control potential data mining of WHOIS at 
the registry level - use of a "Cloudy GIF" and Bandwidth throttling. We chose 
to use bandwidth throttling rather than use of Cloudy GIFs for 2 reasons - use 
of cloudy GIFs is mostly ineffective and discriminatory. Specifically, a cloudy 
GIF is an image displayed on a web WHOIS page that contains characters not 
easily readable by a machine. Cloudy GIFs inhibit mechanized queries of the 
WHOIS website, however, they do not affect data mining from Port 43, where the 
overwhelming majority of attempts tend to occur. In addition, cloudy GIFs can 
be disadvantageous to users with sight-related disabilities. Instead, to 
control potential data mining of WHOIS at the registry level, we will employ 
bandwidth throttling to limit the number of queries a given user can submit in 
a given time period. Registrars will have unlimited access (i.e. no throttling -
 however, potentially `abusive' behavior will be monitored). Other users will 
be throttled to approx 60 to 100 queries per minute. We will review and 
potentially modify this policy based on user feedback and patterns of 
legitimate use.

10.	MONITORING 
It is important that a registry operator have state-of-the-art monitoring 
systems. NeuLevel's systems are extensive and operationally proven and their 
24/7/365 NOC reacts to any alert in the registry's global operation. NeuLevel's 
monitoring of the WHOIS service includes:

· Dynamic update throughput is measured and tracked. At any instance in time, 
should they notice that one or more local WHOIS databases have not been 
updated, the NOC is alerted, at which point an investigation is begun.

· Each WHOIS lookup site is monitored from various points on the Internet for 
availability. At any instance in time, if one of those points is not able to 
reach a WHOIS site, an alert is generated. The NOC then begins investigation.

· Each process in their architecture is monitored for normal operations. If, at 
any point an alert is generated that shows unexpected behavior, the NOC begins 
to investigate.

· An upgraded auditing capability will be finished and deployed prior to 
transition of the .NET registry. NeuLevel will audit that each WHOIS lookup 
agent is responding with accurate data as stored in the SRS. Thorough auditing, 
at the data level, to ensure that the SRS and the WHOIS servers are in sync is 
not a trivial exercise but one that should be standard operating procedure for 
all registries.

11. CONCLUSION
The following table shows a side-by-side comparison of the WHOIS Sentan is 
proposing for NET versus what is currently available.

FEATURE        CURRENTLY provided for in .NET  SENTAN proposed WHOIS services
--------------------------------------------------------------------------------
Domain Name	            X                               X
Registrar	            X                               X
IP Address	            X                               X
Registrant ID	                                            X
Wild cards	            X                               X	
Dynamic Updates	                        	            X           
On screen IDN keyboard		                            X                 
IDN search                                                  X
IDN Converters		                                    X		
Unicode display of WHOIS output		                    X		




(xiii) System security and physical security. Technical and physical capabilities and procedures to prevent system hacks, break-ins, data tampering and other disruptions to operations.

The applicant's response to Part 2, Section 5, Subsection b, Question xiii will remain confidential to ICANN and the independent evaluators. ICANN will use reasonable efforts to avoid publication or release of this information, but in no circumstance will ICANN's liability for any release of this information exceed the amount of the application fee.


[RESPONSE IS CONFIDENTIAL]


(xiv) Peak capacities. Technical capability for handling a larger-than-projected demand for registration or load. Effects on load on servers, databases, back-up systems, support systems, escrow systems, maintenance and personnel.

WHY SENTAN
· Sentan's deployed capacity significantly exceeds expected demand in every 
aspect of registry operations

· Sentan's DNS solution has significantly more capacity than will be needed to 
support .NET for the foreseeable future, and has been designed to allow for 
simple and cost-effective expansion as demand increases

· Sentan's DNS sites have bandwidth that would support over 20X times the peak 
anticipated .NET load in June 06

· Sentan's WHOIS systems have been designed and lab-tested to support 10X the 
estimated .NET demand in June 06

· Sentan's SRS capacity is 3 times the expected peak .NET demand in June 06

SYS/SERVICE	 EST DEMAND 6/06 *	DEPLOYED CAPACITY      EXCESS CAPACITY
DNS-Bandwidth	      210MB	               4.11GB	            20X
DNS-Server	    150 QPS	              760 QPS	             5X
SRS - Bandwidth	       47MB	                310MB	             6X
SRS - Transactions	4,500TPS	            13,333TPS	             3X
SRS Database	      7.2M names	             8M names	           1.1X
WHOIS	            400 QPS	            4,000 QPS	            10X

* Estimates are conservative and actual demand will likely be less than the 
estimated demand.

1. INTRODUCTION
NeuLevel, Sentan's technical registry operator, has estimated .NET volumes and 
stress tested its infrastructure to volumes well in excess of our high estimate 
for future .NET volumes. 

The .NET TLD is critical to the infrastructure of the Internet. This is due to 
its legacy as a domain for ISPs and Internet infrastructure. Each of the 13 
root servers is hosted on a nameserver with a .NET name. Many domain names in 
other TLDs, such as .COM and .BIZ (including high volume names such as 
amazon.com), are hosted on nameservers with .NET names.

After analyzing the .NET and .COM zone files we have determined that .NET makes 
up a 14% of total .COM and .NET names. However, almost 30% of .COM names are 
hosted on nameservers with .NET names. This means that 30% of .COM names rely 
on a .NET name. Clearly .NET is more important that its 14% share would 
indicate.

Because of this, NeuLevel created a Capacity Planning Team made up of 
representatives from NeuLevel engineering and operations, as well as members 
from NeuLevel's parent company NeuStar. NeuStar has had extensive experience 
successfully estimating transaction volumes and sizing infrastructure to 
support those volumes. 

For example, in 1997, NeuStar successfully implemented a first-of-its-kind 
registry to support telephone number portability in the US and Canada. They had 
to ensure that the system they built was sufficient to handle the demand 
created by the telephone companies. Further, wireless number portability was 
introduced in the US in 2003.  While the introduction of number portability in 
1997 was staggered across the continent, in 2003 all wireless telephone number 
became available for portability on the same day. Again NeuStar's Capacity 
Planning Team was called in and successfully predicted the demand and required 
size of the infrastructure.

NeuLevel was able to utilize NeuStar's expertise, combined with its own domain 
name registry expertise, to create a Capacity Planning Team to evaluate .NET.

The NeuLevel Capacity Planning team specifically evaluated:
· DNS;
· SRS;
· WHOIS; and
· Bandwidth.

The Team took the following approach to estimating the demand:
· Develop an estimate of current .NET volumes;
· Extrapolate growth to June 2006, 12 months after transition of .NET;
· Using .BIZ data, extrapolate a peak transaction/queries per second; and
· Using an average transaction size extrapolate a peak bandwidth demand.

2. DNS CAPACITY
The latest statistic with regard to .NET DNS query volume says that .COM 
and .NET combined receive over 14B queries a day. To estimate how much of that 
applies to .NET, we did some comparisons of the .COM and .NET zone files. The 
results are shown in Table 1:

Table 1 - Comparison of .NET and .COM nameservers and names
Names/Nameservers	.NET Zone File	.COM Zone File	Totals
Domain names	              5.2M	      32M	37.2M
.NET nameservers	              3.2M	    20.1M	23.3M
.COM nameservers	              6.7M	    43.9M	50.6M

The team developed a statistic called "Names Supported" by adding the number 
of .NET names to the number of .NET nameservers and dividing it by the total 
number of names and nameservers  The result shows .NET is 26% of the total of 
names and nameservers. 

         .NET Names Supported = 5.2M+23.3M / 37.2M+23.3M+50.6M = 26%

These statistics show that .NET is 26% of total names supported and .COM is 
74%.  We consider this a useful rule of thumb for the purposes of estimating 
the number of .NET queries. However, it doesn't take into account many 
variables that could either increase or decrease .NET usage as compared 
to .COM, such as; high-volume websites, nameserver names outside of .NET 
and .COM, and names with overlapping host names (both a .COM and .NET host). To 
be conservative, we will increase the proportion to 35% to account for those 
other variables. 

We concluded that 35%, or 4.9B, of the 14B queries applied to .NET. Using 
statistics from the .BIZ TLD, we know a Peak Day is 13% higher than an average 
day. Applying this to .NET gives us a Peak Day of 5.5B queries. 

We also know that the Peak 5 minutes is .4% of a Peak Day. Applying this factor 
to the 5.5B queries gave us 20M queries in the Peak 5 minutes. Dividing 20M by 
300 seconds (5 minutes x 60 seconds) gives us a Peak Queries Per Second (QPS) 
of 75K. 

The .NET registry provider has stated that combined .COM and .Net query volumes 
double every 12-24 months. Therefore, we doubled the 75K Peak QPS to derive a 
Peak QPS in June 2006 of 150K.

The Capacity Planning Team has concluded that the .NET nameserver network must 
support a Peak QPS of 150K in June of 2006.

Table 2-Summary of DNS Demand Estimate
ESTIMATED DNS QUERIES	                                    VOLUMES
Peak day .COM/.NET queries                                   14,000M
.NET transactions, 35% of total plus peak day factor	   5,500M
.NET 5 minutes, .4% of a day                                     22M
.NET Peak QPS, peak 5 minutes/(5x60)                             75K
.NET Peak QPS 6/06, 2xPeak QPS                                  150K

2.1 DNS Server Capacity
There are two different philosophies for deploying nameservers and nameserver 
sites. These philosophies can be described as "many and small" or "few and 
large". That is, a registry can choose to deploy:

· Many small servers within a site and have many small sites; or 
· Fewer large servers within a site and have few sites. 

Deploying few large servers in few sites creates numerous problems. With regard 
to the servers, it forces the registry to rely on high-end, expensive 
equipment. This architecture is difficult to scale. Growth in a large server 
architecture creates a step function growth curve. Large servers are expensive 
and support high capacities. Adding more capacity will be a large expense and 
will add a lot of capacity with most of the additional capacity unutilized. 
This creates difficult and risky engineering decisions as to when to add more 
capacity. 

In addition, because the servers are expensive, it forces the registry to 
choose a smaller number of sites. Choosing a smaller number of sites may cause 
the registry to neglect important locations in growing/emerging markets. 

On the other hand, many small servers in many sites gives the registry operator 
a great deal of choice in how to add more capacity and where to place 
nameserver sites. Growing an architecture of many small servers is a very 
graceful process. Each server is relatively inexpensive, so utilizing small 
servers allows the registry to choose more sites in emerging markets that may 
demand lower levels of capacity relative to more mature markets. 

We have also chosen an architecture that has many nameserver sites located 
throughout the world. We decided to place nameserver sites in growing/emerging 
markets to bring .NET closer to those Internet users. Our nameserver 
architecture has allowed us to take full advantage of the "small and many" 
philosophy for the benefit and stability of the Internet. 

Sentan's .NET DNS solution includes 24 nameserver sites located throughout the 
world. There are 2 different configurations for these sites:

· Configuration 1 (8 sites)-4 active and 1 standby IBM servers behind 
a load balancer; and
· Configuration 2 (16 sites)-2 active Sun servers with router load 
balancing.

NeuLevel tested each of these configurations in their lab. The results are 
listed in Table 3. Configuration 1 supports 75K QPS and configuration 2 
supports 10,000 QPS. All nameserver sites combined support 760K QPS, 5 times 
the estimated demand. 

Sentan's DNS solution has significantly more capacity than will be needed to 
support .NET for the foreseeable future, and has been designed to allow for 
simple and cost-effective expansion as demand increases.

Table 3-Nameserver Capacity
Nameserver	# of sites	Capacity per site	Total Capacity
Config 1              8	             75,000	            600,000
Config 2	             16	             10,000	            160,000
TOTAL	             24	               N/A	            760,000

2.2 DNS Bandwidth Capacity
Based on the Peak QPS, the Capacity Planning Team estimated the DNS bandwidth 
demand. Using an average packet size of 1,400 bits, 150K QPS will require 210MB 
of bandwidth (1.4K x 150K = 210M). 

Each nameserver site in the Sentan solution has at least 100MB of bandwidth to 
the Internet. Sixteen sites have 2 100MB connections directly into an Internet 
Exchange Point (IXP). (In fact some of those sites have 2 1GB connections to 
the exchange, but for conservative engineering purposes we'll assume they all 
have 2 100MB connections.) That is over 4GB of bandwidth for .NET, almost 20X 
the peak load for .NET. Table 4 provides a summary of the bandwidth capacity.

Table 4 - Nameserver Bandwidth Capacity
Number of Sites	Bandwidth per site	Total Bandwidth	Type of Bandwidth
2	310MB	310MB	Transit Link
6	100MB	600MB	Transit Link
16	200MB	3.2GB	IXP connection
24	N/A	4.11GB	N/A


3. SRS CAPACITY

SRS capacity can be divided into multiple categories;
·	SRS transactions
·	Database transactions and storage

3.1 SRS Transactions - Registrar Connections

Registrar's access to the SRS depends on two parameters; the number of 
connections and the available bandwidth. Registrar transactions traffic 
behavior can be divided into 2 categories; normal transactions and add storm 
transactions. Normal transactions can be defined as the transactions generated 
by normal daily behavior of registrants, e.g., registering new names, modifying 
existing names, renewing names, etc. Add storm transactions are those that are 
generated by attempts by the registrars to register a name that is expiring at 
a specific date and time. For example, if the name computer.net was expiring at 
noon EST February 1st, then the .NET SRS would receive a significant number of 
add commands from registrars at about that time. 

NeuLevel has decided that the best solution would be to provide each registrar 
the same number of connections and to divide the connections between those to 
be used for normal traffic and those to be used for add storm traffic. Each 
registrar will get a total of 35 connections to the SRS - 25 for normal traffic 
and 10 for add storm traffic. NeuLevel will monitor the traffic on these 2 sets 
of connections and work with the registrars to manage their traffic 
accordingly. 

3.1.2 SRS Transactions - Demand

The Capacity Planning Team estimated peak SRS transactions per second (TPS) 
using a similar process to the one used for DNS. 

The peak month for SRS transaction over the last 12 months reported by VeriSign 
was 1,759M transactions (domain name and nameserver transactions).  Since we 
are proposing to collect contact data in addition to the information VeriSign 
collects today (as an EPP-based "thick" registry) we must add a factor for 
contact related transactions.  By extrapolating data from NeuLevel's .BIZ TLD 
we estimate that there would be an additional 210M contact related transactions 
in a month for .NET/.COM. Rounding up we will estimate 2B SRS transaction for a 
Peak month for .COM and .NET. 

We know that .NET domain names make up 14% of the total of .COM and .NET names. 
To be conservative we will round this number up to 20% to generate a factor for 
estimating .NET transaction. Using a 20% factor, .NET would make up 400M of the 
2B transactions. 

The Team used the growth rate of .NET names to extrapolate monthly transactions 
in June 2006. The average growth rate over the past 12 months has been 1.6% per 
month, so to be conservative the Team increased this to 1.7% per month. Using a 
1.7% per month growth rate yields 480M transactions for June 2006. (This 
estimated growth rate is for capacity engineering purposes and therefore is 
high. Growth estimates for revenue projections and other purposes will follow 
historical data more closely.)

A peak day for SRS transactions in the .BIZ TLD is 5% of the month. Applying 
this to 480M results in a Peak Day of 25M transactions. 

A Peak 5 minutes in the .BIZ TLD is 5% of a Peak Day. The Peak 5 Minutes is 
such a large percent of the day because it includes add storm activity. 
Applying this to 25M results in a Peak 5 Minutes of 1.3M transactions. Dividing 
1.3M by 300 seconds results in a Peak TPS of 4,500. 

ESTIMATED SRS TRANSACTION TYPES	VOLUMES
Peak Monthly .COM/.NET transactions	2,000M
.NET transactions, 20% of total	400M
.NET Peak Month in 6/06, historical 1.7% per month growth	480M
.NET Peak Day, 5% of month	25M
Peak 5 Minutes, 5% of day	1.3M
Peak TPS, Peak 5 min/(5x60)	4,500 TPS

3.1.3 SRS Transactions -SRS Capacity

The Team used this data to analyze the capacity of the .NET SRS systems; 
EPP/RRP and application servers, and the database. In the NeuLevel SRS 
architecture, the database is the most limiting item.  The architecture of the 
SRS utilizes blade server clusters for the EPP/RRP and application servers.  
Increasing capacity to those servers is a matter of adding more servers to the 
cluster.  We have engineered our database to be able to support 13,333 TPS - 3 
times the expected peak demand in June 2006.

The Sentan solution can support demand for SRS transactions even when 
accounting for add storms.

3.1.4 SRS Transactions -Bandwidth Capacity

Using data from .BIZ, we know that an average SRS transaction is 10,400 bits. 
This means that the .NET registry will have to support 47MB of bandwidth during 
an add storm (4,500 x 10,400 bits = 47MB). 

The .NET registry's primary and secondary SRS sites both have 310MB of 
bandwidth (2 OC3s), 6 times the estimated demand. 

3.2 Database Transactions and Storage

The current .NET database contains just over 5 million names. The Capacity 
Planning Team's growth estimates predict the .NET database will contain 7.2 
million names in June 2006, and will process 4,500 TPS. Using that data, we 
have sized the database for 8 million names and 13,333 TPS to ensure we not 
only have more than enough capacity for the transition in 2005, but room for 
growth as well. Please see Part 2:5.b.v for more information on database 
capabilities.

4. WHOIS
The Capacity Planning Team estimated peak WHOIS QPS using the same process they 
used to estimate SRS TPS. 

ESTIMATED WHOIS QUERY TYPES	                         VOLUMES
Peak Monthly .COM/.NET queries                     	1,400M
.NET queries, 20% of total	                           280M
.NET Peak Mth in 6/06,historical 1.7% per month growth	  390M
.NET Peak Day, 5% of month	                            20M
Peak 5 Minutes, .6% of day	                           120K
Peak QPS, Peak 5 min/(5x60)	                        400 TPS

Sentan has decided for geographic coverage, redundancy and survivability 
reasons to deploy 3 WHOIS sites, 2 in North America and 1 in Japan. Each WHOIS 
site consists of 2 servers behind a load balancer. We have tested this 
configuration in NeuLevel's lab. Each WHOIS site will be able to support 4,000 
QPS. This is 10X the estimated June 2006 demand for .NET.

5. Backup, Support and Escrow Systems and Processes
Each data center includes two backup servers with LTO robotic tape libraries, 
using high speed LTO II drives.  To achieve zero-downtime/zero-impact backup, 
we use a RAID disk array and a high-speed fiber channel bridge interconnect to 
the robotic tape libraries. The backup server copies not only the database 
server's backup files to the disk array, but also the backup files of the 
cluster servers.  During the few minutes this process requires, applications 
still have access to the cluster servers and database server.  Finally, the 
backup server copies the files to the LTO robotic tape device. The backup 
process is sized in accordance with the database discussed above and therefore 
can support 8M names and 13,333 transactions. Since the backup process is 
decoupled from normal SRS processes we can seamlessly add more capacity as 
needed. Please see Part 2:5.b.x for more information on backup systems.

Our support systems consist of 2 types of software; network management systems 
(NMS) such as NetCool and eHealth that aggregate and analyze data and provide 
decision support, and agents such as sysEDGE and Tripwire that are placed on 
servers to collect and report data to the NMSs. NeuLevel's NMSs have been 
implemented to support their high capacity state of the art network operations 
center (NOC). They are designed for significant growth. There is significant 
available capacity to be able to handle the .NET registry. The only aspect of 
this architecture that is affected by growth in servers is the agent. The 
agents are deployed on a per server basis so there are no capacity 
considerations. 

Our escrow process is also decoupled from the SRS and operated in a separate 
environment.  The escrow process runs in our data warehouse on data pulled 
nightly from our database via BCV cuts.  The data warehouse is sized comparably 
with the primary SRS database discussed above and therefore can support 8M 
names. Please see part 2:5.b.xi for more information on escrow.

6. MAINTENANCE AND PERSONNEL
There are 3 aspects to maintenance capacity; vendor support, tools, and 
personnel. NeuLevel always purchases support contracts from its vendors. The 
cost of vendor support is either already incurred for existing systems and 
software or it has been built into the cost of building the .NET registry. The 
capacity of tools to support maintenance is covered in the section above. 

Part 2:4b.ii provides a detailed breakdown of personnel estimates for the .NET 
registry. The estimates capture a medium demand staffing and a high demand 
staffing. For the technical personnel the medium demand staffing is 42 and the 
high demand staffing is 55. While this should be sufficient to support .NET 
operations Sentan is committed to providing the highest level of service 
for .NET. And if it's necessary to add more people to achieve that high level 
of service we will add the additional people.

(xv) System reliability. Define, analyze and quantify quality of service.

WHY SENTAN
· Highest commitment to service levels so far for any ICANN accredited gTLD 
registry, e.g.:
o DNS and WHOIS availability of 100%;
o WHOIS and DNS update time of less than 10 minutes for 95% of transactions; and
o SRS availability of 99.95%

· Service level requirements (SLR) use a measurement of actual traffic rather 
than simulated traffic to more accurately reflect the user experience

· SLRs use a 95th-percentile measurement rather than an average which provides 
a more accurate representation of the quality of service

· DNS SLRs commence when Sentan takes over the management of .NET

1. INTRODUCTION
In today's world, operational problems on the Internet are literally front-page 
news as the Internet continues to grow in importance. With a design goal of 
overall reliability and resiliency, few components of Internet infrastructure 
are centralized. However, the operation of gTLD registries is one of those 
functions that are centralized by design. Consequently, gTLD registries, 
stewards of a critical infrastructure resource, must be held to high standards 
for service quality. Sentan welcomes this responsibility and accountability.

Sentan's technical operator NeuLevel has a history of providing high-quality, 
highly reliable domain name registry services to the global community of 
registrars, registrants, and Internet users. Given the wide variety of services 
provided by a gTLD registry and the wide variety of stakeholders to whom those 
services are provided, quality of service is necessarily a multi-dimensional 
concept. In this section, we will provide a comprehensive definition of quality 
of service, analyze our approach to providing reliability for .NET, and 
quantify our solution through a proposed set of operational measurements. We 
will also:

· Describe ways of measuring quality that are accurate and representative;
· Plainly describe our service commitments; and
· Make service commitments that are clearly required given the importance 
of .NET

2. DEFINING QUALITY OF SERVICE
For the purposes of this section, we constrain the discussion about quality of 
service to quantitative core operational quality of service. There are many 
other aspects of service quality that are important when considering a registry 
operator's performance (e.g. customer support, registrar relations, etc), but 
those described here are among the most quantitative aspects of registry 
operation. In order to characterize operational quality, we focus on three key 
systems: DNS, SRS, and WHOIS. We can summarize the important quantitative 
factors for quality of service to be generally related to availability and 
performance. These factors correspond directly to the Service Level Requirement 
(SLR) measurements that are typical of ICANN gTLD agreements signed during and 
since 2001.

We will define quality of service for .NET as:
· DNS - Availability of overall service, availability of individual sites, 
query performance, update performance, and cross network nameserver performance
· WHOIS - Availability of overall service, query performance, and update 
performance
· SRS - Availability of overall service, query performance, and update 
performance
· Planned maintenance - The duration, timing, and frequency of planned 
maintenance for these services

3. ANALYZING QUALITY OF SERVICE
Key to analyzing service quality is the style of measurement for a performance 
requirement. In this regard, gTLD agreements are inconsistent. Some agreements 
call for 95th-percentile measurements, while others call for measuring the 
average of events relative to a quantity (e.g. "average time < 1 second"). In 
examining gTLD agreements, defining requirements using averages is more common. 
However, from the customer perspective, a 95th-percentile measurement is a far 
better and more precise indicator of the overall level of service than a simple 
average. This is because a high percentage of the service can receive 
relatively poor performance when measured as an average. A 95th-percentile 
measurement accurately defines the vast majority of the quality of service.

Additionally, gTLD agreements are inconsistent in what is actually measured. 
Some agreements call for performance measurements of all live transactions. 
Others use tools that initiate simulated transactions to periodically measure 
performance. The measurement of live transactions is a much better indicator of 
the overall level of service than measurement of simulated transactions. 
Simulated transactions are just that: simulated. And periodic measurement 
captures measurements equally throughout the day, but real load is not equally 
distributed. Thus simulated measurements over-represent periods of lower load, 
making performance appear better than it really is.

Currently .NET (and .COM) is not subject to any of these measurements. .ORG 
uses simulators to measure quality of service and their SLRs are based on 
average measurements. 

Sentan will use the following quality of service analysis techniques:
· We will use a 95th-percentile measurement rather than an average measurement; 
and
· We will measure actual transactions rather than use a sampling technique.

4. QUANTIFYING QUALITY OF SERVICE
Sentan's technical registry operator, NeuLevel, has been operating a domain 
name registry for .BIZ for over 4 years. As can be expected, they have improved 
infrastructure and service over those 4 years. In addition, Sentan has worked 
with NeuLevel to design the architecture of the .NET solution with service 
improvement in mind. For the .NET proposal, Sentan will take advantage of these 
improvements and commit even stricter service levels than NeuLevel committed to 
for .BIZ.

Some of the most impressive improvements in service quality are:
· DNS availability of 100% - NeuLevel is deploying 18 additional nameserver 
sites, implementing greater diversity in hardware and software, and improving 
service monitoring techniques.

· SRS availability of 99.95% - Upgrades in system architecture and optimization 
of software has allowed us to commit to a higher level of SRS availability.

· Update time/Transaction time - Timeframes have been reduced for both of these 
SLRs.

We are also committed to paying credits for failures to meet these SLRs. We 
have formally detailed this set of SLRs and credits in our provided versions of 
Appendix D and Appendix E. The service requirements are clearly and simply 
summarized here:

DNS:
· DNS availability at 100% 
· The DNS service does not have any planned unavailability
· At any time, 80% of the total active nameserver sites must be available (80% 
of 20 nameserver sites)
· We will measure the cross network nameserver performance (CNNP) with a goal 
of less than 300 msec round trip time with packet loss below 10%
· Of DNS operations, 95% will complete in 250 ms or less

WHOIS:
· WHOIS availability of 100%
· WHOIS has a maximum unplanned monthly unavailability of 20 minutes, 
representing an availability of 99.95%
· Of Query operations, 95% will complete in 1000 milliseconds (ms) or less

Dynamic update:
· For updates to the DNS, 95% of all updates will be applied in 10 minutes or 
less
· For updates to the WHOIS, 95% of all updates will be applied in 10 minutes or 
less

SRS:
· SRS availability of 99.95%.
· Of SRS query operations, 95% will complete in 500 ms or less. 
· Of SRS write operations, 95% will complete in 1000 ms or less.

Unavailability defined for SRS:
· Planned unavailability of 8 hours per month
· Planned unavailability can take place on Sunday between 0500-1300 UTC
· Planned unavailability requires a minimum 7 day advance notice
· Additionally, once per calendar year, an extended planned outage of up to an 
additional 8 hours may be incurred for major upgrades.
· Extended planned unavailability requires a minimum 28 day notice
· Planned SRS unavailability can occur on a maximum of 2 days per month
· Any unavailability that does not qualify as planned availability is 
considered unplanned unavailability

In keeping with standard practice, we will include our SLR measurements in our 
monthly report to ICANN. With the exception of those SLRs related to DNS 
availability, measurements of each SLR will begin 90 days after Sentan takes 
over management of .NET from the incumbent. For SLRs related to DNS 
availability, SLAs shall commence immediately upon assuming .NET from the 
incumbent.

5. CONCLUSION
In this section, we have defined, analyzed, and quantified the quality of 
service that we will provide as the .NET registry operator. Our definitions of 
service quality are in keeping with those in existing registry agreements. Our 
analysis of service quality demonstrates our understanding of the relative 
importance of various measures of quality. And our quantification of service 
quality demonstrates our willingness to be held to the high standards befitting 
the steward of an important public resource like .NET.

Sentan and its technical registry operator, NeuLevel, understand the importance 
of providing reliable, high-performance, scalable services to customers and the 
public at large. We also believe in measuring our services and reporting on 
those measurements in an open and direct fashion. In this proposal, we have 
established high standards of performance for ourselves as the .NET operator.

(xvi) System outage prevention. Procedures for problem detection, redundancy of all systems, backup power supply, facility security and technical security. Outline the availability of backup software, operating system and hardware. Outline system monitoring, technical maintenance staff and server locations.

WHY SENTAN
· Technical operator, NeuLevel, possesses deep operational experience with a 
large domain name registry

· Existing systems and processes for accurate, fast problem detection

· Superb technical staff--well trained and tested in registry implementations 
and operations

· Significant redundancy to minimize the effect of outages

· Online tape backup for rapid restoration

1. INTRODUCTION
Sentan's offering greatly benefits from its technical operator, NeuLevel, Inc. 
Their years of experience in designing and operating large-scale mission 
critical infrastructure, including the operation of several large-scale 
Internet registries, have allowed them to gain a great deal of expertise in the 
area of system outage prevention. Optimization of these techniques cannot come 
without such directly applicable experience.  For example, NeuLevel's registry 
experience has enabled them to develop and further strengthen their:
 
· Solid architectural design, including redundancy of all systems and network 
components;
· Established proactive maintenance plans;
· Documented knowledge base of problem detection and correction processes;
· Proactive and consistent system monitoring and problem detection;
· Highly skilled technical registry and data center infrastructure operations 
staff;
· Solid security plan--both physical and system;
· Sound processes for continual improvement;
· Communication within the support team;
· Detailed failover processes and guidelines;
· Graceful degradation plans and strategies for outage prevention; and
· Geographic diversity of sites.

2. PROCEDURES FOR PROBLEM DETECTION
NetCool is monitored on a 24/7/365 basis by NeuLevel network operations 
personnel in the Network Operations Center (NOC). SysEDGE, Tripwire, and 
eHealth will generate an alarm to NetCool if a problem is detected. NetCool 
will assign the problem a priority level. The NOC will issue a trouble ticket 
and initiate the appropriate response. The NOC initiates different responses 
based on the priority level. The priority level and responses are:

· P1 - Critical Business Impact--complete loss of service to all or some 
registrars, nameserver sites, or WHOIS out of service. Response - Tier 2 
(application support) and Tier 3 (engineering support) involved immediately, 
24/7 coverage of the issue until resolution, fix applied as emergency patch if 
necessary.

· P2 - Significant Business Impact - partial outage affecting some registrars, 
multiple nameservers, or WHOIS servers, but no sites. Response - Tier 2 support 
involved immediately, 24/7 coverage of the issue until resolution, workaround 
solutions evaluated.

· P3 - Minimal Business Impact- Issue can be circumvented, service can be used 
with only slight inconvenience may include 1 or 2 nameservers or WHOIS servers 
if overall DNS/WHOIS service is fine. Response - Tier 1 (customer support) 
refers problem to Tier 2, fix applied next maintenance window.

· P4 - Little Business Impact - Feature request, documentation enhancement, 
cosmetic issue. Response - Fix implemented as needed.

NeuLevel is in the process of upgrading sysEDGE, eHeath, and  NetCool to be 
able to work in concert to detect a potential DDoS attack. Sysedge will provide 
system health data to eHealth every 30 seconds. EHealth is provisioned with 
acceptable thresholds for each of the system parameters. The thresholds are 
manually set initially, but over time a profile is created of each nameserver's 
traffic. When a threshold is breached, an alarm is sent to NetCool. An expected 
attack on a nameserver is a P1 alarm. 

3. REDUNDANCY OF ALL SYSTEMS
We believe that in order to ensure the availability required for the .NET 
registry, extensive use of redundancy must be implemented. 

3.1 DNS AND WHOIS REDUNDANCY
We will provide redundancy of the DNS and WHOIS servers by deploying:

· Servers at multiple geographically diverse sites--24 nameserver sites; 3 WHOIS 
sites;
· Multiple servers behind a load balancer within a site--each nameserver site 
has either 2 or 5 servers; each WHOIS site has 2 servers;
· Online resources in reserve available within minutes--8 nameserver sites have 
1 reserve nameserver each; there are 4 "dark" nameserver sites;
· Redundant network equipment--2 nameserver sites have fully redundant routers, 
switches, and load balancers; and
· All WHOIS sites have fully redundant routers, switches, and load balancers;.

3.2 SRS AND WHOIS REDUNDANCY
NeuLevel's philosophy for the architectural design of the SRS portion of 
the .NET registry incorporates redundancy at several distinct levels. No single 
point of failure exists within the primary or secondary SRS sites because they 
employ:

· Redundant network equipment--2 nameserver sites have fully redundant routers, 
switches, and load balancers;

· Two OC3s from 2 different ISPs;

· Redundant local failover databases and synchronizing remote databases at 
secondary site; and

· EPP and application blade server farms with excess servers deployed to 
protect against individual server outages.

All system components are locally replicated and configured for automatic 
failover.

· To further enhance system availability, a full duplicate of the production 
SRS will be available at the secondary site. With real-time replication of data 
between the 2 sites being delivered across dual secure 45 Mbps connections 
using 2 separate network providers, this site will be capable of immediately 
becoming the primary production site, either on demand (e.g. - in the event of 
a prolonged system slowdown), or in the event of an outage at the primary site.
 
· In order to ensure service continuity in the event of a failure at the 
primary or secondary site, a third SRS site, capable of being turned up as the 
primary production site or the secondary site within 24 hours will also be 
provided. Asynchronous replication using Oracle Data Guard and journaling feeds 
will be provided to this site, via dual network connections using separate 
network providers. This third site will reside in Tokyo, Japan.
Every system operates with complete redundancy. Exhibit 5.b.xvi-1 describes 
elements of Sentan's system architecture redundancy to be employed at each SRS 
data center.

4. BACKUP POWER SUPPLY
The SRS and WHOIS data centers will be equipped with an Uninterrupted Power 
Supply (UPS) power, capable of supporting the entire data center and network, 
in the event of brief electrical surges and outages. For longer outages, a 
diesel generator capable of sustaining the entire operations building 
(including the data center and network) for 60 hours will also be available. 
Supplied with diesel fuel, generator power can be sustained indefinitely. 
Should the fuel supply be jeopardized, or chance of failure be imminent, 
failover to the secondary site will be performed until power is restored.
It should be noted that in order to ensure the proper function of the UPS and 
diesel generator, each would be tested under load on a weekly basis. All 
prescribed preventative maintenance of the UPS system and generator will also 
be diligently performed, as recommended by the manufacturer. Each device has 
power supplies from at least two power distribution units (PDU).
All nameservers sites have UPS and backup generators of varying capacities.  
The Sentan architecture has been provisioned to be able to withstand multiple 
nameservers outages and still be able to serve the load.

5. FACILITY AND TECHNICAL SECURITY
We understand the need to protect registry services, especially with regard to 
a public resource as critical as .NET. We utilize a full array of the most up-
to-date tools, methods, and procedures to ensure secure operation of the 
registry, as well as fully secured facilities. See Part2:5.b.xiii for a 
complete description of our facility and technical security approaches.

6. AVAILABILITY OF BACKUP RESOURCES - SOFTWARE, OPERATING SYSTEM, HARDWARE
In addition to holding complete and up-to-date backups of all system data, it 
is also important to have readily available copies of all current system code, 
third-party software and operating systems, either locally or from another 
trusted source. It is important to always have the ability to reload all or a 
portion of a system's software in order to correct potentially corrupted 
software, or quickly load software on a new component being swapped into the 
system, either replacing failed equipment or expanding capacity. Likewise, 
having service agreements with equipment and facilities vendors is another 
important consideration in order to ensure a timely vendor response at times of 
need.

The primary SRS data center, run by NeuLevel on behalf of Sentan, implements a 
zero-downtime/zero-impact incremental data backup each day, and a zero-
downtime/zero-impact full data backup weekly. They copy static data (e.g., the 
operating systems, BIND software, applications software) to CD-ROMs for quick 
reload, should it become necessary. They back up to high-capacity LTO (Linear 
Tape Open) storage tapes any dynamically changing files (e.g., log files vital 
to system maintenance and operation, database files, database-journal files, 
software configurations). Weekly, NeuLevel, performs full-system backups to LTO 
tape on all registry databases (.NET DB, Billing). They place escrow copies of 
the backup tapes in a secure off-site storage facility operated by Iron 
Mountain, a full-service provider of management and storage services for 
business records, healthcare records, film and sound archives, and vital 
records.

Sentan will have complete "golden images" of all current software and operating 
systems available at each of the hosting SRS data centers, as well as storing 
these images at a secure off-site location, along with backup data. This will 
allow Sentan to quickly configure or reconfigure equipment as necessary. As an 
additional precaution, we opt for the highest level of support agreements with 
software vendors (where applicable), ensuring timely responses from vendors 
when issues are encountered.

From a hardware perspective, 3 levels of precautions will be taken. First, high-
availability, redundant hardware will be used throughout the system instances. 
Second, all system, security and network equipment will come with 4-hour on 
site maintenance and support in the event of a problem. Finally, Sentan's 3 
main data centers will each contain hardware allocated to DNS, WHOIS and SRS 
systems. 

7. SYSTEM MONITORING
As noted in this section, NeuLevel currently operates a NOC, from which all of 
their systems, networks, applications, and facilities at all sites can be 
monitored. This NOC will be expanded to accommodate the .NET registry. NeuLevel 
has deployed an integrated network/system management infrastructure using the 
best-of-breed management tools in the industry. This infrastructure consists of 
tools such as Micromuse NetCool, HP OpenView, Concord eHealth, EMC/IBM/HP 
proactive fault detection/phone home software, and customized monitoring 
scripts. This infrastructure will allow automatic detection and compensation 
for system and network faults that notify system operators. This proactive 
approach will minimize outages and maximize service availability.

See 2. Procedures for Problem Detection in this section for detailed 
information about system monitoring tools and processes.

8. TECHNICAL MAINTENANCE STAFF 
.NET registry will be supported by a technical maintenance staff that are fully 
experienced and familiar with the operation of a large-scale Internet registry. 
The technical maintenance staff members are trained in operating and monitoring 
mission-critical infrastructure. Deployed in NeuLevel's NOC data centers, a 
team of infrastructure resource specialists supports the technical maintenance 
staff. They include:

· Database specialists;
· Application specialists;
· Security specialists;
· Systems architects;
· Systems performance analysts;
· A certified business continuity professional; and
· Hardware and software vendor support. 

Each of these specialists is also already very familiar with the working of 
large-scale Internet registries. This group of specialists also serves to train 
additional technical maintenance staff, should replacements or incremental 
staff be required. This team has been managing the .BIZ, .CN, and .TW 
registries for NeuLevel since 2001.

It is very difficult, expensive, and time-consuming to assemble such a team and 
make them productive, complete with clearly defined roles and responsibilities 
and rules of engagement. Sentan's technical association with NeuLevel allows 
the unique opportunity to offer the Internet community the benefit of a fully 
trained and operational system infrastructure team that understands fully the 
intricacies involved in operating a large-scale Internet registry.

9. SERVER LOCATIONS 
Sentan will deploy SRS, WHOIS, and DNS systems in existing world-class data 
centers residing in Sterling, Virginia, USA, Charlotte, North Carolina, USA, 
and in Tokyo, Japan. The primary SRS site will be in Sterling, and the 
secondary SRS site in Charlotte. The SRS disaster recovery site will be the 
Tokyo site.
 
The WHOIS and DNS systems will be deployed in all 3 data center sites, and 20 
additional active DNS sites will be distributed throughout the world. 4 DNS 
backup sites will be deployed, as "dark" sites. They can be quickly brought 
online in the event of outages or higher than anticipated demand. See Part 
2:5.b.i for a complete list of the DNS site locations.

The Sterling site is a fully staffed data center. Redundant links and 
monitoring between Charlotte and Sterling are currently operational and used 
for various NeuLevel systems. The Tokyo site is also a manned facility.




(xvii) Ability to support current feature functionality of .NET (to the extent publicly or otherwise available to the applicant, including IDNs, support of IPv6, DNSSEC.

WHY SENTAN
· Support for all existing .NET registry features

· Improve "1 Tag-1 Table" IDN solution which follows IDN policies

· Support for ISCs open source plug-in effort

· Deployment of IRIS for .NET

· Sentan R&D commitment will provide further enhancements to the Internet 
community

· Commitment to researching the applications and operational implementation of 
DNSSEC

· Dynamic update to the WHOIS as well as the DNS to ensure detail synchronized

1. INTRODUCTION
Sentan will support all current feature functionality of the .NET registry and 
improve on most of them. We will also offer new services that are not currently 
offered in .NET. 

The existing features of the .NET registry include:
· Two registry interfaces - RRP and EPP without contact information;
· Dynamic update of the zone file;
· Synchronized Renewal Service (Similar to the Incumbent's Consolidate product);
· IPv6 support; and 
· Internationalized Domain Names (IDN).

In addition to these features, Sentan's .NET registry will offer the following 
new features:
· EPP with contact information; and
· Internet Registry Information Service (IRIS).

In its role as the .NET registry, Sentan has committed to funding a research 
and development effort to evaluate DNS and registry-related technologies 
including IDN, health of the DNS, and Anycast deployment and architectures. 
Sentan has contracted with JPRS, one of its parent companies, to perform R&D 
for the advancement of DNS and registry infrastructure and services. JPRS, the 
registry for the Japanese ccTLD, .JP, has a long and distinguished history 
performing valuable technical research for the benefit of the Internet 
community. 

2. EXISTING REGISTRY FEATURES
Sentan commits to supporting all existing features offered by the current .NET 
registry operator. We will make the transition as simple and smooth as possible 
for the registrars and the industry as a whole. 

2.1 Registry Interface
Registrars currently use 1 of 2 registry interfaces--RRP or EPP without contact 
data. Sentan has chosen to evolve the .NET registry to a thick data model, 
therefore the NeuLevel registry will support RRP, EPP without contact data, and 
EPP with contact data at the rollout. This evolution from a thin registry to a 
thick registry will occur over the first 9 months of operation of the new .NET 
registry. 

Sentan will make the transition to the NeuLevel registry as easy as possible by 
offering a registry interface identical to the ones the registrars use today - 
RRP and EPP without contact data. In addition, we will also offer EPP with 
contact data for those registrars that want to take advantage of their existing 
systems that are compatible with other registries and deploy EPP with contact 
data as soon as possible.

2.2 Dynamic Update
The .NET registry currently provides dynamic update of the zone file. Sentan 
will continue to provide this service, but will enhance it to also provide 
dynamic update to the WHOIS. This will ensure that the zone file and the WHOIS 
are in sync.

2.3 Synchronized Renewal Service
Registrars for .NET get a service today called Consolidate. This service allows 
the registrar to synchronize the expiration date for a number of different 
domain names. For example, if example.net expired on March 1, 2005 and 
alpha.net expired on December 1, 2005 the registrar could consolidate both 
expiration dates to December 1, 2005. In that case, the registrant would not 
have to keep track of multiple expiration dates for its domain names. NeuLevel 
will continue to offer a service that synchronizes the expiration date for 
multiple names.

2.4 IPv6
IPv6 is important to the growth of the Internet and to Internet adoption within 
growing and emerging markets. There are 2 factors that will increase the demand 
for IP addressing space--penetration of the Internet into growing and emerging 
markets and new devices with access to the Internet. NeuLevel has already 
acknowledged the importance of IPv6 to a domain name registry by implementing 
it in the .BIZ domain. We commit to continuing to support this capability 
in .NET for Sentan.

2.5 IDN
Sentan will improve on the Incumbent's implementation of IDN. Specifically, 
will:
· Deploy a "1 tag - 1 table" solution to ensure compliance with ICANN 
guidelines and international policies;

· Implement bundling for the Chinese language tag consistent with relevant 
stakeholders' concerns and implementations performed by leading Chinese 
registries such as CNNIC (.CN) and TWNIC (.TW);

· Fund ISC's IDN plug-in project to ensure availability of an open source IDN 
plug in;

· Introduce new registrations in a language only when there is agreement by the 
relevant stakeholders for that language regarding language-specific 
registration policies; and

· Grandfather all existing IDNs.

In late 2000, the .NET registry began offering internationalized domain names 
(IDN) in the .COM, .NET, and .ORG domains. At the time there was an outcry from 
the Internet community. There was no existing Internet Engineering Task Force 
(IETF) standard, there were no policies for how individual languages would be 
treated, compatible resolvers did not exist, and there were no ICANN guidelines 
for the registries and registrars. This forced registrars and registrants to 
act before they were ready. For example, a company with an existing COM/NET/ORG 
domain name was forced to decide on what to do with their name (or names 
similar to it) in other languages. 

However, the greatest outcry came from the international community. Countries 
have a great affinity for, and pride in, their languages and did not want 
another entity deciding how their language should be represented on the 
Internet. 

Since 2000, the international community and the Internet community have created 
the following solutions for many of the problems that existed in 2000 and for a 
number of years after:

· Standards Development - The IETF has created a standard for IDN that 
is open, non-proprietary, and fully compatible with the Internet's existing end-
to-end model;

· International Policies - The ccTLD administrators have led the way in 
defining language tables for their respective languages;

· Resolvers - Some resolvers have integrated IDN into their code while 
there are plug-ins available for other resolvers; and

· ICANN Leadership - ICANN has created guidelines and an agreement for 
IDN deployment. 

Now in 2005, it is possible to deploy IDN in a manner that accounts for many of 
the concerns of the technical, international, and Internet communities. Sentan, 
and its primary technical registry operator NeuLevel, will maintain all of the 
existing IDNs in the .NET database and improve the existing service 
considerably. 

2.5.1	1 Tag - 1 Table
Today, the .NET registry uses a few very large language tables for reference 
when registering an IDN. The language table maps a code point to a character. 
When a registrant chooses to register a name, they select a language tag, to 
define what language they are choosing, and that tag will reference the 
language table to create the IDN. For example, to register a German domain 
name, a registrar would select the language tag for German and that, in turn, 
would reference a specific language table that would provide the German 
characters. 

The language table, however, plays another very important role - it keeps the 
language consistent. For example, if one were to select the German language 
tag, it should not let that person choose a Chinese character. This is a 
problem in the current .NET large table implementation. The large tables 
contain characters from many different languages. This can allow a registrant 
to register a domain name with characters from many different languages, which 
would be a violation of ICANN's guidelines. In addition to mixed characters, 
the large table implementation can allow for the registration of characters not 
considered "legitimate" by the Internet community, such as symbols and 
punctuation. We have found many examples of both of these problems in our 
analysis of the .NET zone file. 

To improve the service to the .NET users, Sentan will adopt a "1 tag-1 table" 
solution. That is, each language that we support will have its own table - each 
tag has its own table. This will allow us to be in complete compliance with 
ICANN guidelines. It will also allow us to work with representatives of the 
local languages and add, delete, and modify characters as advised. The large 
table solution cannot offer this level of flexibility. 

As part of our improvement of the IDN service in .NET, we have already worked 
with many local language experts from around the world, as required, in the 
ICANN guidelines. In collaboration with these experts, we have already 
developed language tables for 11 languages:

· Chinese;
· Japanese;
· Korean;
· German;
· Swedish;
· Danish;
· Norwegian;
· Icelandic;
· Polish;
· Thai; and
· French.

If selected, Sentan will support all of the above languages, except Chinese 
upon Transition Day. According to our analysis of the .NET zone file, these 
languages make up over 95% of the existing IDNs and a corresponding 94% of 
new .NET registrations going forward (based on current trends for language 
registration).

Sentan will work with the IDN Community and local language experts to develop 
additional language tables. The goal is to deploy tables for all of the 
languages currently registered in .NET.

2.5.2 Chinese Language IDNs
There are unique complexities concerning the bundling of Chinese IDNs. The 
current implementation in .NET does not fully meet these needs. An 
implementation that more fully complies with the policies of the relevant 
stakeholders, including JET, IETF, CDNC, and Chinese language registries such 
as CNNIC and TWNIC, will require additional time to complete. We will begin 
accepting new Chinese IDN registrations within 90 days of transition. The 
following provides additional information concerning our Chinese IDN solution.

2.5.3	Bundling
When developing the language tables, we also had to address the issue of 
variants. Variants are characters that have the same meaning but look different 
and are represented by different code points. It is possible for 2 
registrations to have the exact same meaning but be entirely different 
characters. Because we have selected a "1 tag-1 table" solution, Chinese is the 
only language with a potential for variants, of the languages we are 
introducing. There are variants between the Simplified and Traditional versions 
of the Chinese language. 

Our solution for Chinese language variants is to "bundle" the names. This 
follows the policies of CNNIC with whom we worked to develop our solution. When 
a name is registered, it can create 2 or more variants. Typically, this will be 
a Traditional name, a Simplified name, and one or more names with mixed 
Traditional and Simplified characters. The combination of the Traditional and 
Simplified names is called the common names. Mixed character names are not 
commonly used. 

When a bundle is created, the registry will reserve all names in the bundle for 
the specific registrant. The common names will be put in the zone file with the 
same delegation information. The mixed names will be reserved, but not put in 
the zone file; unless it was a mixed name that the registrant attempted to 
register, then it will be put in the zonefile with the common names.

Therefore, for each bundle created, 2 names will be put in the zone (the 
Traditional and the Simplified), unless the registered name is a mixed name 
then all 3 names will be put in the zone. The remaining mixed names within the 
bundle will be reserved and will not be able to be registered by anyone else. 
The reserved IDNs can be activated, i.e., put into the zone file, anytime after 
they are reserved. If the registered name is renewed all names stay in the same 
status. If the name is deleted than the bundle is broken apart and the names 
are no longer reserved. 

2.5.4 IDN Resolver
IDNs are only useful if they can be resolved. The lack of IDN support in 
applications is a major hurdle in the widespread use of the technology. Sentan 
will sponsor and endorse the open source plug-in software for Microsoft 
Internet Explorer by Internet Systems Consortium's IDN-OSS project.

Sentan believes that end users will benefit from the non-proprietary and 
community-driven nature of the open source plug-in that we have developed.

3. NEW REGISTRY FEATURES AND REGISTRY RESEARCH
Sentan is committed to the improvements of registry features and operations. As 
part of that, we will commit to deploying an IRIS server within the first 12 
months of operations. We have also committed to funding registry-related 
research and development. And finally, we will rely on the expertise of our 
parent companies to advise us further on the potential deployment of DNSSEC.

3.1 IRIS
In September of 2004, the IETF published RFC3912, which defines the final form 
of the WHOIS protocol. WHOIS (originally RFC954) has served the Internet 
community for almost 2 decades as a means of determining the ownership and 
authority of a name in the domain name system. However, to quote RFC3912:

"For historic reasons, WHOIS lacks many of the protocol design attributes, for 
example internationalization and strong security, that would be expected from 
any recently-designed IETF protocol."

Accordingly, while ongoing support of WHOIS is necessary to support legacy 
systems, modern registries require a system that has the necessary 
internationalization and security properties. The IETF has developed the IRIS 
for this purpose, within the Cross-Registry Information Service Protocol 
(CRISP) WG.

The most important improvements of IRIS over traditional WHOIS are:

· Structured interface: WHOIS-provided, unstructured textual responses 
to queries that were difficult to parse in any automated fashion.

· Security infrastructure: WHOIS queries and responses are transmitted 
over an unsecured TCP connection, and WHOIS provides no intrinsic means for 
authenticating the source of a WHOIS query or guaranteeing the integrity of 
WHOIS responses. IRIS employs Transport Layer Security (TLS) and the Simple 
Authentication and Security Layer (SASL) frameworks. This allows registry 
policy to determine whether a particular originator of a query is entitled to 
information about a particular name.

· Internationalization: The XML format used by IRIS supports UTF-8 and 
UTF-16 encoding, and a "language" tag that specifies the language in which a 
response has been generated.

Sentan believes that .NET has a responsibility to be a leader in IRIS adoption. 
The .NET community is a technical community; perhaps more so than is the case 
for any other gTLD, and the benefits of IRIS are likely to resonate strongly 
with this community. 

Consequently, Sentan commits to deploy IRIS for .NET within 12 months of the 
transition of the .NET gTLD. Sentan furthermore commits to indefinite ongoing 
support for the WHOIS protocol, as it is likely that the community will require 
it for sometime to come.

This means that the information available from the .NET WHOIS will also be 
available from an IRIS server. Entities that want to deploy an IRIS client will 
have the option of receiving that information using the IRIS protocol. Sentan 
will work with the Internet community and ICANN to help the industry determine 
potential implementations of some of IRIS's more rich features, such as its 
security capabilities. 

3.2	SENTAN R&D
Sentan has a distinguished lineage. The parent companies of Sentan, JPRS and 
NeuLevel, are both technology leaders whose strengths compliment each other. 
JPRS's strength is in research and development. JPRS has been at the forefront 
of Internet related technologies such as IDN, DNSSEC, DNS use of Anycast, and 
IPv6. NeuLevel's strength lies in implementing new technologies in an 
operational environment such as, EPP, dynamic update, and IPv6. 

Sentan will take advantage of this rich legacy by committing to fund JPRS to 
perform Internet domain name related research and development. The goal of this 
research is not simply to support future developments in the .NET registry but 
to benefit the Internet community at large. 

On behalf of Sentan, the JPRS R&D effort will include:
· Advising Sentan on new registry-related technologies;
· Publishing white papers and best practice documents in multiple languages;
· Sponsoring and hosting working groups;
· Participating in existing working groups;
· Managing an online resource center;
· Establishing test beds; and
· Hosting educational sessions.

Candidates for the R&D effort include:

· IDN - Advance Internet community efforts to make the Internet more 
accessible to non-english speakers;

· Health of the DNS - Support Internet community efforts to monitor, 
maintain and improve the "health" of the Internet as it relates to performance, 
accessibility, usability, robustness and survivability; and

· Anycast deployment - Conduct research and development in the area of 
deployment and ongoing operation and enhancement of services using Anycast 
technology including DNS, WHOIS, and IRIS.

The .NET registry will receive benefits from the R&D performed by JPRS for 
Sentan. New .NET registry technologies and features will result from JPRS's R&D 
efforts. 

3.3 DNSSEC
DNSSEC is a protocol extension to the DNS recently approved by the IETF. It 
provides protection against some threats to the DNS. Both of Sentan's parent 
companies are doing extensive research on DNSSEC that compliment each other. 
JPRS is working on the impacts of DNSSEC on the DNS and NeuLevel is focusing on 
the operational aspects of DNSSEC in the registry and the applications for 
DNSSEC.

Ed Lewis, NeuLevel staff member, is one of the originators of the requirements 
for DNSSEC. He has worked on the protocol for over 10 years and is one of the 
most well respected members of the DNSSEC community. Ed recently lead an effort 
at NeuLevel to trial the EPP extension related to DNSSEC. The team worked with 
an accredited registrar in the .US domain to test the functionality of sending 
DNSSEC keys and resource records from the registrar's system to NeuLevel's SRS. 
The trial evaluated various operational aspects of DNSSEC, as well as tested 
the IETF draft for the EPP extension.

In addition to these operational aspects of DNSSEC, NeuLevel has also been 
working on the applications related to DNSSEC in an effort to foster adoption 
among Internet users and developers. DNSSEC, through its chain of delegation 
from the root to any particular DNS name, also creates a binding between a set 
of cryptographic keys and a domain name. Accordingly, there exists a potential 
for applications that today rely on certificates similarly to rely on the 
intrinsic properties of DNSSEC. There are a number of emerging applications 
which require a key-to-name binding security property but are unable to 
leverage certificates. The most high-profile of these is sender authentication 
for email. This is one of the tools that can be used to battle spam. 

Sentan believes that DNSSEC will play a critical role in enabling new security 
services for applications like sender authentication for email. Applications 
are essential for widespread DNSSEC adoption; without them, neither resolver 
implementers nor domain-name vendors will have much incentive to further DNSSEC.

(xviii) System recovery procedures. Procedures for restoring the system to operation in the event of a system outage, both expected and unexpected. Identify redundant/diverse systems for providing service in the event of an outage and describe the process for recovery from various types of failures. Describe the training of technical staff that will perform these tasks, the availability and backup of software and operating systems needed to restore the system to operation and the availability of the hardware needed to restore and run the system. Describe backup electrical power systems and the projected time for system restoration. Describe procedures for testing the process of restoring the system to operation in the event of an outage, the documentation kept on system outages and on potential system problems that could result in outages.

WHY SENTAN
· Extensive capacity and redundancy has been built into the architecture to be 
able to withstand any outage with little or no impact to the Internet and 
enable system restoration in an established, orderly manner

· Third disaster recovery SRS site provides extra protection when restoring 
service in SRS

· Systematic assessment of outage or failure by experienced technical team

· Performs a failover to the secondary SRS periodically to ensure proper 
processes and procedures

1. INTRODUCTION
With expectations of .NET registry service unavailability being virtually zero, 
one would assume that system recovery procedures would essentially be able to 
deliver near zero recovery times as well. This would mean that any solution 
depending on actually having to take the time to diagnose and repair a failed 
system, leaving a registry service unavailable during the process would simply 
be unacceptable. Given these realities, redundancy will be key. Several 
provisions for redundancy can be made. Redundancy via multiple site instances 
is one approach, but it does not necessarily suit every service application. 
Ensuring that no single point of failure within an instance is another 
approach, however, this does nothing if the physical site becomes inoperable. 
Hot sites are useful, but failover durations can vary widely. 

Given the variety of registry services that will be offered, Sentan believes a 
blended approach including each of the aforementioned redundancy approaches. 
Sentan's .NET solution addresses and surpasses the specific availability and 
system recovery needs of each of the three services within the registry. While 
the urgency of minimizing individual system recovery time varies, based on the 
service and its implementation, the ultimate goal is always the same: zero 
service unavailability, zero data loss, and minimize perceptible registry 
slowdowns. While system recovery procedures are very important and minimizing 
recovery time is certainly a goal, Sentan's approach depends less on system 
recovery time than is does on the registry's high degree of redundancy, local 
to the instance and/or via multiple site instances, which in effect reduces 
recovery time to zero.

2. PROCEDURES FOR RESTORING SYSTEM TO OPERATION

2.1 PLANNNED SYSTEM OUTAGES
Sentan has architected a solution that only has planned outages from the SRS. 
The DNS and WHOIS services will not experience any unavailability, as 
maintenance on a particular instance (or even several instances in the case of 
DNS) will in no way affect the user community. Sentan will arrange to conduct 
planned system outages on the DNS and WHOIS instances such that the service 
itself is not affected. For SRS, given its differences, will in some cases 
require having planned outages that will cause service unavailability, 
typically for database maintenance reasons. When suitable, Sentan will failover 
to the fully replicated secondary site while maintenance is performed on the 
primary site, in order to minimize SRS service unavailability.

In all cases of planned system outage, the technical maintenance personnel will 
pre-determine exactly what is to be performed and how long it will take. Plans 
for rolling back the changes in the event that the planned outage takes too 
long will also be made, in order to respect the pre-determined maintenance 
window periods. For the SRS, the user community will be advised of the timing 
and duration of the planned outage 7 days in advance. A reminder notice will 
also be sent the day before the planned outage is to occur. Additional notices 
will also be sent at the beginning and end of the planned outage event, with 
the final notice indicating the result of the planned outage.

While performing maintenance during the planned outage window, progress will be 
carefully monitored. If at any point it is determined that the tasks are taking 
longer than expected, decisions will be made to either cut short some of the 
tasks, or possibly even to cease and roll back changes made, in order to bring 
the system back online at the pre-determined time.

For details on notification and durations of planned unavailability please see 
Part 2:5.b.xv.

2.2 UNPLANNED SYSTEM OUTAGES
NeuLevel's Trouble Management Policy defines procedures and timelines for 
identifying unplanned outages, notification and escalation either to functional 
experts or to management for resolution if they are not resolved within the 
escalation policy time limits. Outages are categorized into 1 of 2 priority 
levels:

P1 - Catastrophic outage affecting an overall platform or multiple customers on 
a specific platform
Procedures for resolution
· Open an Internal Conference Bridge
· Send P1 page to all Technical Support, Service Management and Technical 
Management.
· Open an internal trouble ticket
· Provide support and information as needed
· Send out internal status page every 30 minutes
· Update internal ticket every 30 minutes
· Maintain internal ticket and event time-line information
· Contact vendor as required for break/fix
· Verify that service is restored
· Resolve ticket
· Provide root cause analysis team with event timeline

P2 - Degradation or an outage affecting at least one customer on a single 
platform, or degradation of multiple customers on a single platform
Procedures for resolution
· Open an internal trouble ticket
· Perform trouble-shooting procedures
· Provide support and information as needed
· Update internal ticket every hour
· Maintain internal ticket and event timeline information
· Contact vendor as required for break/fix
· Verify that service is restored
· Resolve ticket

3. REDUNDANT AND DIVERSE SYSTEMS
As previously mentioned, Sentan will provide significant redundancy and 
diversity of system instances in order to minimize service unavailability.
The following outlines Sentan's approach to each service:

· Twenty sites and four backup ("dark") instances of the DNS service will run 
throughout the world, ensuring the continuous availability of DNS. Diversity of 
application software (BIND 8 and 9) and hardware/operating systems (IBM/Linux 
and Sun/Solaris).

· From a WHOIS service perspective, Sentan offers three sites. Each of the 3 
WHOIS sites consists of 2 servers behind a load balancer. The outage of 1 will 
not put the site out of service

· The SRS function differs from the other two in that it would not make sense 
to provide multiple site instances of SRS, since it inherently needs 
centralized control over user community input and updating the aforementioned 
DNS and WHOIS database instances. Therefore, with a single active instance, it 
is certainly the most vulnerable to failure and hence requires the most 
aggressive of system recovery procedures. Sentan's approach in this case is to 
provide redundancy at every level for the active instance, thus leaving no 
single point of failure. No software, hardware, power, network, or any other 
type of outage of single part of the system can cause the system to fail. In 
addition, a secondary hot backup instance, which exactly matches the 
configuration of the primary site, will be provided. Synchronous replication of 
the database, as well as database transaction journaling, will be used to 
ensure that no possibility of data loss exists. In the unlikely event of an 
outage at the primary site, the secondary site will be able to take over full 
primary responsibility in less than 15 minutes. As a supplementary measure, and 
ensuring the continuity of SRS operations, a third instance, residing in Tokyo, 
will provide a warm backup for disaster recovery situations. We define these 
situations as an outage which we estimate will be of greater than 24 hours in 
duration at either (or both) of our two other instances. When faced with such 
circumstances, this third instance will be brought online as a fully capable 
primary or secondary instance within 24 hours.

4. RECOVERY PROCESS FROM VARIOUS TYPES OF FAILURES
For DNS and WHOIS, our global redundancy eliminates the possibility of a total 
and immediate failure of the entire DNS and WHOIS infrastructure. Generally, 
customer's queries will be directed to the DNS and/or WHOIS site closest to 
their geographic location. In the event that particular site is not available, 
the customer's request will be dynamically re-routed to the next available 
site. This allows our technical staff to address the particular problem and 
restore service, while at the same time minimizing customer impact. 

The SRS, on the other hand uses full local instance and backup instance 
redundancy, in addition to having a disaster recovery site. The following 
provides a summary of recovery measures for various failures:

FAILURES AFFECTING THE PRIMARY SRS INSTANCE

FAILURE: Applications-cluster processor fails	
RECOVERY: Cluster management software logs out the failed processor and 
processing continues on the remaining processors in the cluster.

FAILURE: EPP/RRP server processor fails	
RECOVERY: Registrar session is dropped from the failed server and reconnected 
to the other EPP/RRP server in the blade server farm.

FAILURE: Web server processor fails	
RECOVERY: Web session will be reconnected to another server in web form.

FAILURE: Database server processor fails	
RECOVERY: The operating system automatically distributes load to the remaining 
SMP processors.

FAILURE: Database disk drive fails	
RECOVERY: Processing automatically continues on the mirrored drive with no data 
loss.

FAILURE: Database crashes	
RECOVERY: The applications processing is failed over to the hot-standby site 
and continues on the backup replicate database.

FAILURE: Authentication server fails	
RECOVERY: Processing automatically continues on the redundant authentication 
server.

FAILURE: WHOIS-cluster processor fails	
RECOVERY: Cluster management software logs out the failed processor and 
processing continues on the remaining processors in the cluster.

FAILURE: B&C server fails	
RECOVERY: Will failover to the redundant B&C server.

FAILURE: Internet or VPN link fails
RECOVERY: Ongoing sessions are dropped and restarted on the other redundant ISP 
or VPN access link.

FAILURE: Router or firewall fails
RECOVERY: Ongoing sessions are dropped and restarted on the remaining redundant 
router or firewall.

FAILURE: Physical site becomes inoperable for more than 24 hours	
RECOVERY: Failover is initiated to the secondary site and bring the Tokyo 
disaster recovery site online within 24 hours.

FAILURE: Both the primary and secondary data centers become inoperable.	
RECOVERY: Tokyo disaster recovery site will be brought online within 24 hours.

In each instance when a redundant component fails the operations team restores 
the server and places it back in service without disruption to the customer (or 
during the next maintenance window if restoring service will be customer 
effecting). 

The registry technical teams follow the steps below whenever a component outage 
or failure occurs:

· The NOC opens an internal conference bridge and pages the on-call technical 
services teams to join the bridge

· An internal trouble ticket is opened to track the issue

· The appropriate support teams conduct an immediate investigation and make an 
initial assessment

· If parts or an existing spare is available, the system administration team 
completes the replacement
 
· If the team determines that it cannot immediately be fixed, a service call is 
initiated with the vendor

· The trouble ticket is updated with the issue listed as resolved

· The Service Management Team issues a Root Cause Analysis (RCA) Report with 
the details of the event, including an analysis of the cause, the steps taken 
to fix the problem, and a timeline of the events


5. TECHNICAL STAFF PERFORMING THESE TASKS 
NeuLevel, Sentan's technical operator, has an average of seven years of data 
center operations experience, encompassing the high-availability cluster 
technology, distributed database management systems, and LAN/WAN network 
management systems that are employed in the recovery process. New hires and 
transfers to Sentan's .NET registry operations will be given the following 
training:

· A one-week ".NET Registry Overview" course;
· Vendor-offered courses for certification in backup/recovery, cluster 
management, system management, and network management; and
· On-the-job training on registry operations, including high availability 
cluster management, system backup/recovery, database backup/recovery, and 
system/network management.

6. AVAILABILITY AND BACKUP SOFTWARE, OPERATING SYSTEMS, AND HARDWARE*
In addition to holding complete and up-to-date backups of all system data, it 
is also important to have readily available copies of all current system code, 
third-party software and operating systems readily available, either locally or 
from another trusted source. It is important to always have the ability to 
reload all or a portion of a system's software in order to correct potentially 
corrupted software, or quickly load software on a new component being "swapped 
in" to the system, either replacing failed equipment or expanding capacity. 
Likewise, having service agreements with equipment and facilities vendors is 
another important consideration, in order to ensure a timely vendor response in 
times of need.

The primary SRS data center implements a zero-downtime/zero-impact incremental 
data backup each day, and a zero-downtime/zero-impact full data backup weekly. 
We copy static data (e.g., the operating systems, BIND software, applications 
software) to CD-ROMs for quick reload, should it become necessary. We back up 
to high-capacity LTO (Linear Tape Open) storage tapes for those dynamically 
changing files (e.g., log files vital to system maintenance and operation, 
database files, database-journal files, software configurations). Weekly, we 
perform full-system backups to LTO tapes on all registry databases (.NET DB, 
WHOIS, Billing). We place the backup tapes in a secure off-site storage 
facility operated by Iron Mountain on a weekly basis, a full-service provider 
of management and storage services for business records, healthcare records, 
film and sound archives, and vital records.

Sentan will have complete "golden images" of all current software and operating 
systems available at each of the hosting SRS, WHOIS and DNS data centers. This 
will allow Sentan to quickly configure (or reconfigure) equipment as necessary. 
As an additional precaution, Sentan will also opt for the highest level of 
support agreements with software vendors (where applicable), ensuring timely 
responses from vendors when issues are encountered. 

From a hardware perspective, two levels of precautions will be taken. First, 
all system, security and network equipment come with 4-hour on site maintenance 
and support contract in the event of a problem. Additionally, Sentan's three 
main data centers will each contain spare hardware allocated to DNS, WHOIS, and 
SRS systems. 

Sentan believes this approach to be in the best interest of the .NET user 
community in terms of effective use of resources.

7. BACKUP ELECTRICAL POWER SYSTEMS
Our SRS and WHOIS data centers will be equipped with UPS power, capable of 
immediately supporting the entire data center and network, in the event of 
brief electrical surges and outages. For longer outages, a diesel generator 
capable of sustaining the entire operations building (including the data center 
and network) for 60 hours will also be available. Supplied with diesel fuel, 
generator power can be sustained indefinitely. Should the fuel supply be 
jeopardized, or any chance of failure is imminent, failover to the secondary 
site will be performed until power is restored. Therefore, system restoration 
time is zero.

Current UPS and generator capacity are shown in Exhibit 5.b.xviii-1:

All nameserver sites have UPS and backup generators of varying capacities. The 
Sentan architecture has been overprovisioned to be able to withstand multiple 
nameserver site outages and still be able to serve the load.

8.	PROJECTED TIME FOR SYSTEM RESTORATION 
If for some reason the Sterling Data Center had an unexpected disaster we will 
have the SRS back up and running in Charlotte, NC in 15 minutes or less. If we 
unexpectedly lost Sterling and Charlotte we will have the SRS back up and 
operational in Tokyo, Japan in 24 hours or less.

9. PROCEDURES FOR TESTING THE SYSTEM RESTORATION PROCESS 
Sentan will organize, perform and evaluate, with the participation of the SRS 
user community, all system restoration plans on an annual basis. An analysis of 
the results will be performed and recommendations made. Our operations experts 
will then carefully review these recommendations and processes will be changed 
as necessary if deemed to improve the effectiveness of our operation.

10. DOCUMENTATION REGARDING SYSTEM OUTAGES
Sentan will perform root cause analysis of hardware and software failures to 
determine and analyze the reason for any failure. Based on our findings, we 
will work with vendors to generate hardware service bulletins and software 
maintenance releases to prevent reoccurrence of these failures, as well as 
consistently reviewing our own processes, looking for better methods of 
recovering from or of preventing outages.

In addition, Sentan's proactive systems management processes include 
performance management, trend analysis, and capacity planning. These processes 
analyze system performance and utilization data to detect bottlenecks and 
resource utilization issues that could develop into outages. Monthly reports on 
the three processes keep the data center manager apprised of our performance 
against service level agreements and raise awareness of potential problems that 
could result in outages. 



(xix) Technical and other support. Support for registrars and for Internet users and registrants. Describe technical help systems, personnel accessibility, web-based, telephone and other support services to be offered, time availability of support and language-availability of support. Ability to support new and emerging technologies.

WHY SENTAN
· Global customer support sites, 24-hour, multi-lingual, multi-modal (voice, 
email, facsimile, etc.) support

· Innovative tools for registrar support

· Comprehensive support for new and emerging technology leveraging parent 
companies expertise

1. INTRODUCTION
Our professional, experienced, responsive, and versatile support team forms a 
critical bridge between the registry and our primary customers, the registrars. 
This support team utilizes an infrastructure that enables registrars to access 
a wide array of innovative and functional support tools. These tools will make 
a positive, material impact on the quality of registrar support which will 
enable registrars to better grow their businesses while enhancing competition 
and ensuring equal access.

The Sentan registry support team will be truly global in nature, with 3 support 
sites worldwide. This structure will provide global consistency of support with 
an unprecedented regional perspective. Additionally, in recognition of the 
importance of equal access and enhanced competition, we will support over 100 
different languages representing nearly all Internet users. While registrars 
are traditionally the primary consumer of registry support, a gTLD registry 
also provides support to registrants and general Internet users, as 
appropriate. The support requirement for these diverse groups is significantly 
different, as is the way in which each group accesses registry support 
resources. This section will describe the support team structure (including 
availability, accessibility, and languages) and the support that is provided to 
the registry user groups. Additionally, this section will also describe our 
support of new and emerging technologies.

2. PERSONNEL ACCESSIBILITY/SUPPORT FOR REGISTRARS
We organize our support resources into three tiers. Each tier is described as 
follows:

· Tier 1 - Receives customer inquiries, answers majority of questions, resolves 
standard issues;
· Tier 2 - Provides infrastructure and application support, resolves necessary 
escalations from Tier 1; and
· Tier 3 - Provides software-troubleshooting support, resolves necessary 
escalations from Tier 2.

Our Network Operations Center (NOC) provides for coordination between tiers and 
manages all system-wide infrastructure issues. Tier 1 support and NOC teams are 
staffed 24/7/365. Tiers 2 and 3 support are also available 24/7/365, either on-
site or on-call from Sterling, VA, USA. Customers of all types, typically 
interact with Tier 1 support, which liaises to Tier 2 and Tier 3 as necessary.

Our Tier 1 support for .NET will be deployed into 3 regional support centers 
strategically located in Tokyo, Japan; Rome, Italy; and Sterling, VA, USA, 
supporting Asia-Pacific, Europe/Middle-East/Africa (EMEA) and the Americas 
regions respectively. This global, multi-site approach to support is unique 
among registry operators. These locations provide global business hour coverage 
and local/regional expertise, and will deliver responsive and consistent 
registrar support. Customers will be able to receive responses to their 
incoming queries around the clock with this approach. 

Registrars, registrants, and Internet users can contact the customer support 
team by various means: telephone, email, facsimile or web. We will provide 
local telephone and facsimile numbers in each region. A toll-free number will 
be available in each location for those who are able to dial to it free. We 
will also use call routing technology to direct calls to the currently active 
global support center. That is, a call placed at midnight in North America will 
be routed to the Asia-Pacific support center. All regional support center 
telephone numbers will be available to all customers. 

All customer support personnel have access to a centralized customer 
relationship management (CRM) system (Siebel) for tracking service and customer 
issues, along with a centralized email system to monitor customer 
correspondence and requests. All members of the support staff (Tiers 1, 2, and 
3) are equipped with laptop computers and cell phones, so they can respond to 
inquiries and issues no matter where they are physically located.

Our current Tier 1 support team personnel have an average of over 4 years of 
registry experience and includes individuals who have worked for accredited 
registrars in the past. The team is composed of experienced professionals, each 
with over 10 years of experience in roles that require technical 
troubleshooting, problem solving, and interpersonal skills. This core group 
will form the anchor of our support team as we increase staff to support the 
additional responsibility of .NET.

When contacted by a registrar concerning an issue, the customer support 
specialist assigns it to 1 of 4 categories. The problem category determines the 
process for addressing and escalating the problem if it is not solved within 
defined time limits. These categories are:

· P4: questions: if unable to answer in real-time, provide answer within 8 
hours.

· P3: service issue, with work-around, effecting one registrar: if unable to 
solve at Tier 1, hand off to Tier 2 for resolution; solve in 4 hours or escalate

· P2: service issue, lacking work-around, effecting one registrar: diagnose and 
hand off to Tier 2 for resolution; solve in 2 hours or escalate.

· P1:  service outage effecting overall operations: immediate page of Tier 2 
and Tier 3 on-call engineers and management.

3. LANGUAGE SUPPORT
Our experience in global TLD operations gives us a unique understanding of the 
importance of supporting a wide variety of languages. Our customer support team 
will support Chinese, English, German, French, Italian, Japanese, Korean, and 
Spanish at the time of transition.

In addition to our in-house language expertise, our .NET customer support team 
will have access to a telephone interpretation service. This service will 
provide live telephone translation services in over 100 languages 24/7/365. 
This level of language support is indicative of the global nature of .NET 
operations and another demonstration of our commitment to customers in all 
parts of the world, especially emerging markets in Africa, the Middle East, and 
Asia.  Our support for multiple languages further extends beyond speaking. For 
example, we will translate our web WHOIS output into the following languages: 
Chinese, English, German, French, Italian, Japanese, Korean, and Spanish. We 
will also provide the primary Sentan website and registrar marketing materials 
translated into these languages.

4. SUPPORT FOR INTERNET USERS AND REGISTRANTS
In addition to being organized primarily to support registrars, the registry 
has an obligation to provide support for registrants and Internet users. The 
primary support organization for registrants and Internet users, are registrars 
and ISPs, respectively. We do not, however, seek to interfere with the 
registrar/ISP customer relationship. Based on NeuLevel's experience in TLD 
operations, we have found that the registry serves primarily as an enabler to 
assist registrants and Internet users in solving particular problems or more 
importantly, to provide them with accurate information so they can contact the 
appropriate entity to resolve their concern. Consequently, we place extensive 
focus on developing web-based FAQ documents and other information to help users 
help themselves.

The quality of these web-based resources not withstanding, registrants and 
Internet users can (and frequently do) use our email and telephone support 
capabilities. In most situations, we will answer a simple question and need not 
take any further action. If a caller identifies a problem with a particular 
entity, we make necessary contact with the appropriate entity and work to help 
solve the problem. The most common circumstances of such involvement are domain 
name transfers, bouncing email, or unreachable websites.

5. TECHNICAL HELP SYSTEMS/SUPPORT SERVICES
Two important web-based tools augment the Support Team's capabilities and are 
also provided to registrars: a web portal and the Registrar Administration Tool 
RAT). 

Web Portal - We will maintain a secure portal for registrars that includes:
· Operational notifications for planned maintenance or upgrades;
· Operational updates on incidents such as degradations or outages;
· General registrar business notices;
· Registrar Operations Guide;
· Frequently asked questions (FAQ); and
· Client toolkit downloads.

Access to the portal is controlled by login ID/password. The home page of the 
web portal includes notices to registrars of planned outages for maintenance or 
installation of upgrades. These notifications are posted 30 days prior to a 
maintenance event, in addition to active notification including phone calls and 
email to the registrars. Finally, 7 days and again 2 days prior to the 
scheduled event, we will use both a Web-based notification and email to remind 
registrars of the planned outage.

Registrar Administration Tool (RAT) - We will operate a secure web system that 
provides web-based access to the SRS, allowing registrars to easily manage 
domains, contacts, and hosts through a series of intuitive screens. The tool 
allows registrar personnel to more easily process transactions for themselves 
without needing to contact Registry Customer Support, which saves time for the 
registrar and enhances productivity. Given the obvious importance of high 
security on this facility, access to the RAT is controlled by two-factor 
authentication using RSA SecureID tokens and encryption of all data traffic 
(HTTPS). This allows registrars to closely control (by utilizing physical 
tokens) the accessibility of RAT.

In addition to these existing tools, our customer support infrastructure 
for .NET includes the following new/enhanced services:

· Ad Hoc Reporting
· CSR Text Chat
· AuthInfo Code Validator
· WHOIS Contact Validator
· Automated Registry-Registrar Messaging

We provide a summary of these capabilities here. Additional information can be 
found in Part 2:3.
 
Ad Hoc Reporting - A web-based tool that offers customizable reporting to all 
accredited .NET registrars. The tool will allow any registrar to access their 
data in the registry database and to compare their data and statistics against 
the overall registry averages. Through the use of this tool, Sentan will allow 
registrars to develop their own reporting formats and structure at no 
additional cost.

CSR Text Chat - A Customer Support "Chat" or instant messaging tool for 
all .NET accredited registrars provided at no additional cost. Based on the 
experience of NeuLevel staff in launching and managing the .BIZ registry, we 
have found that it is easy and efficient to communicate with non-English 
speaking registrar personnel via a chat tool. This is particularly true in 
cases where registrar staff may be very capable in written English but may have 
some difficulty in speaking the language. A text-based chat system combines 
email ease of expression with the immediacy of a telephone call.  In support of 
existing international registrars, and as Sentan launches a registrar outreach 
program to identify potential new .NET registrar candidates in underserved 
markets, including Africa and the Middle East, the CSR Chat Tool will become an 
important tool for better and more efficient communication. It will augment the 
multilingual voice support we will provide through our live, 24-hour customer 
support operations.

AuthInfo Code Validator - The AuthInfo Code Validator service that will help to 
make the .NET domain transfer process smoother and more efficient for both 
registrar and registrant. The intent of the AuthInfo Code Validator is 
consistent with the theme of portability, is instrumental in thick registry 
facilitation of domain transfers, and supports ICANN's recent policies 
concerning domain transfers. We would provide the AuthInfo Code validation 
through a secure web-based tool, which will provide access to all registrars, 
whether they are registering domains automatically or providing live registrant 
phone support during the registration process. In addition, we will develop an 
extension to EPP to perform this function over the EPP interface. NeuLevel and 
JPRS will introduce this to the IETF in an effort to have the extension 
accepted as an RFC.
 
WHOIS Contact Validator - The .NET WHOIS Contact Validator will be offered 
to .NET registrars on an opt-in basis at no additional cost. By producing and 
providing regular reports to participating registrars and to ICANN, this new 
service will help to address the increasing problem of inaccurate contact 
information for domain records and to help prevent fraud. The service cross 
checks multiple WHOIS data fields and a database of phone and address records 
of over 120 countries worldwide. Through this process, the service produces 
reports and a ranking system of likely incorrect or falsified domain contact 
data in the WHOIS records.

Automated Registry-Registrar Messaging - Sentan will institute a system of 
automated messaging for Registry Notices in the machine-readable RSS web 
contact syndication format. Numerous registrars have requested that all 
existing ICANN-accredited registries move to a more standardized system of 
messaging and that any such system be machine-readable so the messages can be 
processed automatically and sent by the registrar to their resellers and 
registrants. We believe this automated messaging service will help all 
registrars better inform customers and resellers about planned registry 
outages, events, services, etc. and will allow registrars of all sizes to 
compete more efficiently with one another. 

6. SUPPORT FOR NEW AND EMERGING TECHNOLOGIES
The careful introduction of new technology is an important responsibility of a 
gTLD registry. From the perspective of registry support, relevant new and 
emerging technologies include: IDNs and IPv6. We have extensive experience in 
supporting these technologies and ongoing plans to do the same. The area of new 
and emerging technologies is one that highlights the strength of Sentan's 
parent companies--NeuLevel and JPRS.

IDNs - Our track record in supporting IDNs includes NeuLevel's deployment of 
German names in .BIZ, JPRS support of Japanese names in .JP, and NeuLevel 
support of Chinese names in .CN and .TW (.TW starting in March, 2005); All of 
these initiatives are fully standards-compliant with ICANN guidelines, thus 
aiding their adoption in the marketplace. Our support goes beyond simply 
registering the names in a database. For example, in .BIZ, NeuLevel has fully 
enabled web tools, including the public WHOIS and the private RAT, to assist in 
the management of IDN names. 

This includes features such as:
· Accepting Unicode input strings and performing ACE translations behind the 
scenes;
· An online keyboard that includes German characters to make it easier to enter 
Unicode script;
· A Unicode-to-ACE and ACE-to-Unicode translator tool; and
· Providing the Unicode string (e.g. "XN--") for the IDN domain.

Additionally, all WHOIS output (web and "port 43") returns the following 
language information on an IDN name:
· Language code of the IDN;
· Unicode Hex representation of the Unicode characters in the domain; and
· Unicode HTML encoding of the Unicode characters in the domain.

These features indicate our understanding of the practical implications of 
IDNs. They are currently in production and are also part of our .NET solution. 
Our commitment to IDNs extends further to the area of enabling the end-user to 
utilize IDNs. Probably the largest single barrier to IDN adoption is the lack 
of IDN resolution support in Microsoft Internet Explorer. To help fill this 
void, we are currently providing financial support to a prominent open source 
project to develop an IDN resolver plugin for Microsoft Internet Explorer. 

In addition to these operational initiatives, JPRS, Sentan's parent company, is 
extraordinarily active in the development of standards for IDN. As an example, 
JPRS staff members were members of JET (Joint Engineering Team) that had very 
strong influence to the IDN standardization and service implementation. As part 
of JET, they evaluated several ACE proposals and recommended Punycode (AMC-ACE-
Z at that time) as the selection. They documented IDN registration guideline 
(JET guideline), and the result was published as RFC3743. JPRS staffs are very 
active in ICANN IDN discussions, with extensive credibility rooted in practical 
experience.

IPv6 - The NeuLevel SRS the foundation for .NET currently accepts IPv6 
addresses for hosts. These addresses are made available in the DNS as AAAA 
records as part of standard WHOIS output. Additionally, leveraging the 
operational experience of Sentan's parent companies, .NET will have DNS servers 
that operate on IPv6 technology.  The JPRS team's experience with IPv6 dates 
back to March 2000, when the .JP SRS began accepting IPv6 addresses and 
publishing them in the .JP DNS. Work with IPv6 continued, expanding into the 
placement of IPv6-addressed DNS servers on the Internet and on July 20th (PST), 
2004, IANA completed verification of the IPv6 addresses allocated for the four 
JP DNS name servers were formally registered in the Internet root.
   

6. Security and Stability

Criteria: The entity chosen to operate the .NET registry must: (i) maintain .NET registry functions efficiently and reliably, (ii) demonstrate disaster recovery capability and (iii) deliver high quality of service for all .NET users worldwide. Providing documentation for procedures insuring a very high level of security and stability is an absolute criterion.

(a) Provision for Registry Failure. Describe in detail how you would assure continuity of operations in the event of operational failure of the registry and make provision for contingencies and a failsafe back-up plan. A commitment to provide ICANN with escrowed data, in and of itself, will not satisfy the absolute criterion.

WHY SENTAN
· Fail-safe backup plan that includes a third geographically diverse SRS site 
for disaster recovery and continuity of operations

· Combined capability of 2 registry operators (NeuLevel and JPRS), each capable 
of operating the registry on its own 

· Step-by-step disaster recovery plan 

· Comprehensive data escrow plan   

Sentan is keenly aware of the importance of the smooth and uninterrupted 
operation of the .NET registry.  Despite the best efforts of any operator, an 
operational failure involving multiple simultaneous component failures, natural 
disasters, terrorism or war, or other catastrophic events are possible and 
therefore contingency plans must be in place to ensure operational continuity. 

EXTENSIVE DIVERSITY AND REDUNDANCY
Recognizing the mission critical nature of the .NET domain, the Sentan .NET 
infrastructure includes:

· 3 geographically diverse SRS sites (Primary, Secondary, and Disaster Recovery)
· 3 co-active WHOIS sites 
· 20 active DNS sites with presence on every continent except Antarctica
· 4 dark stand-by DNS sites (2 North America, 1 Asia, and 1 Europe)

SRS OPERATIONAL CONTINUITY 
SRS sites differ from DNS and WHOIS sites in that centralized control of 
database update transactions must be maintained. We believe that the mission 
critical nature of the .NET domain calls for a back-up and disaster recovery 
capability that simply cannot be addressed with two SRS locations.  Without the 
benefit of a third site, a catastrophic failure at one SRS location would leave 
the registry operator with a single-threaded solution for an extended period of 
time and would render the .NET SRS vulnerable to complete failure.  

Sentan's solution includes 3 geographically diverse SRS sites including a: 

· Fully redundant primary site in Sterling, Virginia, USA; 

· Secondary site that exactly mirrors the primary sites redundant configuration 
in Charlotte, North Carolina, USA; and 

· Disaster recovery site in Tokyo, Japan. 

All registry data is immediately replicated from the primary site to the 
secondary site. In addition, database transaction journaling will also be used 
to further ensure that no data is lost due to a failure. The secondary site 
will be a hot-site, capable of immediately initiating takeover of primary 
function in the event of an outage. 

In the event of a failure at the Sterling site that isn't mitigated by the 
local redundancy of the site, Charlotte will become the primary site and an 
immediate damage assessment will be performed. Should a problem at either 
Sterling or Charlotte require an estimated recovery time greater than 24 hours, 
the disaster recovery site in Tokyo would be brought online as the secondary 
site within 24 hours. In the unlikely event of both the Sterling and Charlotte 
sites failing simultaneously, the Tokyo site will become the primary site 
(either immediately, if it had already been brought online as the secondary 
site, or otherwise within 24 hours).

Sentan has trained and qualified personnel in both Sterling and Tokyo, each 
capable of independently operating and maintaining the .NET registry, if 
necessary. Personnel at both locations will have extensive training and will 
have disaster recovery planning documentation to reference in the event of a 
disaster recovery situation. 

DNS AND WHOIS RECOVERY
The nature of the DNS and WHOIS services are such that they can be operated co-
actively from multiple locations. In the event of a single site or even dual 
site failure, the service is still available as long as other sites remain 
operational. 

Sentan will deploy 3 co-active WHOIS lookup systems, residing in the 3 
operational sites. A failure at 1 or even 2 sites will not result in any 
interruption of the WHOIS capability.  Sentan will engineer the capacity of the 
service to be sufficient that 2 co-active sites can amply meet normal demand.

Sentan will deploy 20 co-active DNS systems, as well as an additional 4 backup 
(dark) sites throughout the world, effectively making single or even multiple 
failures virtually transparent to users.

In the extremely unlikely event that all 3 SRS/WHOIS sites fail simultaneously, 
repair efforts would then be focused on the site with the quickest time to 
repair. All of the equipment supporting .NET operation in these sites will have 
premium support contracts with Sentan's vendors.  Vendor technicians are 
contracted to be on site with any necessary parts within 4 hours of a hardware 
failure. 

STEP-BY-STEP REGISTRY RECOVERY PLAN
In the event of a registry failure where the primary and secondary sites are 
rendered inoperable:

· JPRS Tokyo-based staff will assume management and operation of the registry;

· The disaster recovery SRS system will be brought online within 24 hours;

· The WHOIS service will continue operation;

· The DNS service will continue normal operation;

· All registrars will immediately be notified and will receive status updates 
at regular intervals;

· ICANN will immediately be notified and will receive status updates at regular 
intervals; and

· Work will immediately begin on damage assessment and repair or replacement of 
the failed sites.

Although the plan will be well documented and training will be extensive, 
flawless execution of a plan requires practice.  To ensure personnel are 
prepared to execute in the event of a real catastrophic outage, we will conduct 
disaster recovery testing at least once a year using our secondary and disaster 
recovery sites and report the results, including any identified issues and 
associated action plans to ICANN. System recovery procedures are detailed in 
Part 2:5.b.xviii.

DATA ESCROW
It is important to remember, that in a thick registry model, registrant data is 
securely held by the registry in a centralized database.  Furthermore, since 
the proposed solution employs three SRS systems, 3 copies of the database will 
be retained within the registry infrastructure.  In addition, our solution 
includes online backup which can be downloaded into the production database in 
minutes if needed for data recovery.

In the unlikely event of a complete registry failure, ICANN will have access to 
all of the necessary data including registrant information to guarantee the 
registrant-to-domain name relationship is not lost.  NeuLevel has contracted 
with Iron Mountain, Inc. to provide data escrow services, which are fully 
compliant with existing ICANN contracts.  Data escrow will include a full set 
of data for each day of the week, and incremental data sets for all 7 days of 
each week.  Full and incremental data sets will be up to date and coherent as 
of 1200 UTC for each respective day.  For more information concerning data 
escrow please see Part 2:5.bxi. 

(b) Provision for Business Failure. Describe in detail what advance arrangements you will implement to ensure that, if your operation of the .NET registry becomes financially non-viable, the registry operations will be quickly, smoothly and efficiently transferred to another operator so as to minimize disruption of the registry functions.

WHY SENTAN
· Sentan has more than adequate financing and a solid business plan based on 
conservative assumptions, and upon award, will put an additional business 
continuity line of credit in place (See Part 2:4 for details)

· Access to substantial additional financial resources if required to fulfill 
its obligations under the ICANN Agreement (See Part 2:4)

· 2 financially strong and experienced registry operator parents, each of whom 
is individually qualified to assume operations of the .NET registry with 
ICANN's approval

· Includes the financial reporting mechanisms required to ensure ICANN has 
regular and ongoing visibility into our financial health

FINANCIAL STRENGTH
Sentan combines the financial wherewithal, stability, and experience of two 
proven and respected industry players, NeuLevel and JPRS. Sentan has more than 
adequate financing and a solid business plan based on conservative assumptions, 
and upon award, will put an additional business continuity line of credit in 
place (See Part 2:4 for details). Sentan's financials are particularly strong 
when you consider that its parent companies have already made, and will 
continue to make, the necessary capital investments required for the registry 
infrastructure.  Although the current funding is more than adequate, as 
detailed in the financial section of this proposal, Sentan has access to 
substantial financial resources if required to fulfill its obligations under 
the ICANN Agreement. 

Given the above, it is highly unlikely that Sentan would ever become 
financially non-viable. However, given the critical nature of the .NET 
infrastructure and the services provided by the registry, it is prudent to have 
advance arrangements in place to address even the remote possibility.  

PARTNERSHIP PROVIDES INHERENT BUSINESS CONTINUITY
In the unlikely event that Sentan were to become financially non-viable, either 
NeuLevel, its majority parent NeuStar, or JPRS, with the authorization of 
ICANN, could take over full operation of the .NET registry function. Given the 
experience and capabilities of Sentan's parent companies, the partnership 
approach we have taken in forming Sentan provides inherent benefits in terms of 
business continuity that a single registry operator simply cannot provide.  

MECHANISM TO PROVIDE ICANN ADVANCE VISIBILITY
Any business continuity plan that does not provide ICANN with ongoing 
visibility into the financial health of the .NET registry, introduces the 
possibility of a sudden and unexpected financial failure of the .NET registry 
operator. Regular updates concerning whether the registry operator's financial 
health is adequate to support the ongoing operations of the registry, would 
provide ICANN with advance notice so proactive steps can be taken to plan for 
corrective action or a possible transition. 

Of course, ICANN should not be burdened with the task of assessing future 
financial viability of the registry operator.  In order to provide ICANN with 
the visibility it needs for prudent planning, Sentan and NeuLevel (Sentan's 
technical registry operator), will undergo an annual financial statement audit 
by an independent auditor from an established, well-regarded audit and 
accounting firm. Consistent with any applicable disclosure laws or regulations, 
the audited financial statements, which will include the report of independent 
auditors, will be sent to an independent accounting firm who will provide ICANN 
a letter indicating whether the independent auditors' opinion letter was or was 
not "unqualified" with respect to the asserted audit, thereby indicating the 
financial viability of Sentan and NeuLevel.  In addition, Sentan's Treasurer 
will, on a quarterly basis, provide a self-certification that Sentan has not 
defaulted on the contract and has the financial viability to operate for at 
least the next six months. 

TRANSFER OF OPERATIONS PROCESS
Three critical elements of any transition are (1) sufficient notice; (2) 
detailed planning; and (3) cooperation of all affected parties. The following 
outlines the steps that will be taken to proactively monitor the financial 
health of Sentan and its technical registry operator, and to quickly initiate a 
smooth and efficient transition of registry operations should that become 
necessary. 

· Sentan and NeuLevel will undergo an annual financial audit by its independent 
auditor and ICANN will be notified of the results per the process above. 

· Sentan's Treasurer will, on a quarterly basis, provide a self-certification 
that Sentan has not defaulted on the contract, and that Sentan has the 
financial viability to operate for at least the next six months. 

· If Sentan fails to cure by methods such as procuring additional financing 
from its parents or other sources within 30 days, this would be considered 
default under the ICANN agreement and ICANN would have the right to terminate 
the agreement and commence transition planning.

· Sentan, NeuLevel and JPRS senior management and staff would fully cooperate, 
and work closely with ICANN and the gaining service provider (NeuLevel, 
NeuStar, JPRS or other) to effect a smooth transition including the transfer of 
all "institutional knowledge".

· Sentan, NeuLevel and JPRS to the extent possible, would retain key personnel 
required to manage a transition for a sufficient period and would waive any non-
compete clauses in the employment agreements of such key personnel to make them 
available for employment by the gaining registry operator.

· Sentan will, in accordance with its Registry Agreement with ICANN, escrow all 
data with Iron Mountain, NeuLevel's existing escrow provider, to ensure the 
security and stability of registrant and registrar data.

· A restricted license for proprietary software, unique business rules of 
operation and billing and administrative records would be made available to the 
gaining registry. As Sentan will run a "thick" registry and WHOIS, all domain 
data will be contained in a master database.

ENSURING THE SUCCESSOR IS FINANCIALLY STABLE
A logical starting point might be for ICANN to identify a list of successor 
registry candidates from the list of other acceptable applicants, however, we 
feel strongly that identifying a specific alternate, or "buddy" registry 
operator at the time of this proposal is neither appropriate nor beneficial to 
the stability and security of the Internet. The financial, operational and 
technical status of any such "buddy" could change significantly between the 
time of award and the time of transition. Our plan ensures that ICANN retains 
maximum flexibility and visibility to enable ICANN to identify a possible 
successor registry operator and does not prematurely commit ICANN to any one 
successor at the time of award.

(c) Describe in detail your arrangements to provide a secure environment in which the registry infrastructure is to be operated.

The applicant's response to Part 2, Section 6, Question c will remain confidential to ICANN and the independent evaluators. ICANN will use reasonable efforts to avoid publication or release of this information, but in no circumstance will ICANN's liability for any release of this information exceed the amount of the application fee.

[RESPONSE IS CONFIDENTIAL]
   

7. Additional Relative Criteria

The following are additional relative criteria: (i) the degree to which the applicant’s proposal promotes competition in the registration of domain names, (ii) the degree to which an applicant’s business model relies on multiple, rather than sole source, suppliers, to reduce the impact of failure by any one supplier, and (iii) the degree to which an applicant’s proposal results in improved implementation of, and support for, GNSO policies, such as transfers and deletes.

Provide a detailed explanation of the manner and degree to which your proposal accomplishes the three relative criteria described above.

WHY SENTAN
· Choosing Sentan promotes competition at the registry level with a new, 
innovative provider

· Sentan promotes competition at the registrar level through innovative 
programs and services

· Sentan delivers benefits to end users and efficient and responsive global 
service

Sentan brings together two established companies with a mission to promote 
competition in the management of domain name registration services. We show we 
will use a range of suppliers to satisfy our registry requirements. We will 
accelerate the effective implementation of policies formulated through ICANN's 
GNSO constituencies.

(i) Promotes Competition in Name Registration 

REGISTRY COMPETITION 
Competitive markets result in lower prices, better services, and more 
responsive service providers. Under the existing arrangements for .NET one firm 
controls 85% of the gTLD registry market and 60% of the overall domain market. 
In other industries this level of domination is unhealthy. 
Increased diversity of qualified registry providers will:

PROMOTE STABILITY. Separating the 3 largest gTLDs to 3 qualified suppliers will 
reduce the likelihood that an operational or business failure of one provider 
could impact multiple TLDs.

FOSTER BUSINESS/MARKET EFFICIENCY. A diversity of service providers will lead 
to the provision of more innovative and efficient services for registrars and 
Internet users.

CREATE AN ENVIRONMENT THAT DISCOURAGES MONOPOLISTIC BEHAVIOR AND ENCOURAGES 
INDUSTRIAL HARMONY. A concentration of operators with the power to control the 
marketplace or prevent beneficial change in the marketplace is undesirable. In 
contrast, having multiple competitive players encourages good industry 
citizenship and robust standards development.

RESULT IN BETTER SERVICE AND PRICING. Real competition at the registry level 
exerts market pressure on the quality and price of registry services.
Our selection would separate the .COM and .NET TLDs from being administered by 
the same company on the same infrastructure. It would place .NET on a highly 
reliable, secure, and proven registry platform. 
The JPRS and Neulevel partnership enhances global competition through 
substantive equity and operational diversity by a Registry that does not 
currently operate in the gTLD market.

REGISTRAR COMPETITION 
Our solution will enhance registrar competition in the following ways:

TRANSFERS. Name portability between registrars is critical to healthy registrar 
competition (particularly for new market entrants). In the current .NET 
environment, there are significant problems with transfers (these are well 
documented in ICANN forums). Failure rates are extremely high as there is not 
an automated standard for transfer authentication. Also, varying data formats 
between gaining and losing registrars result in numerous failures due to data 
incompatibility. Our accelerated EPP implementation will improve the efficiency 
and effectiveness of .NET transfers via the use of the EPP AuthInfo 
authentication code. Use of this code in the .BIZ space has resulted in 
dramatically lower (<3%) transfer failures. Our thick registry will also 
improve the efficiency and effectiveness of .NET transfers. A thick registry 
(centralized and standardized data) ensures consistency of data between losing 
and gaining registrars, obviating failures due to incompatible fields.

MARKET OUTREACH. Consistent with our Financial Plan we will implement a 
comprehensive program of outreach and education to stimulate the introduction 
of new registrar competitors. Particular focus will be placed on markets with a 
very low concentration of existing .NET registrars, notably Latin America, 
Africa, Middle East, and parts of Asia.

LANGUAGE DIVERSIFICATION. We will expand customer support, marketing materials 
and registry communications into languages other than English (Phase I - 
Japanese, French, Mandarin Chinese, Cantonese Chinese, German, Spanish, Korean 
and Italian) and Phase II (Arabic, Portuguese and Russian). This will better 
enable non-English registrars to compete. Funding for these programs is 
specified in our Business Plan. 

POLICY IMPLEMENTATION. Our superior policy implementation will create a 
predictable environment for registrars to compete. For example, the checkered 
implementation of IDN policy has made it difficult for existing .NET registrars 
to compete with IDNs. Sentan will improve this environment.

NEW SERVICES. By enhancing 8 existing services to registrars and introducing 7 
new services, (see Parts 2:3.a and 2:3.b.ii.) we will better equip .NET 
registrars to compete with each other and to promote .NET as an attractive 
alternative to .COM and other TLDs. 

DELETE BILLING. We will follow NeuLevel's lead in being the only gTLD registry 
to bill registrars at the end of the "Auto Renew Grace Period" rather than the 
standard practice of collecting fees at the beginning of the period. This will 
free cash reserves for registrars which can be used to better compete.

IPv6 DEPLOYMENT. Our accelerated IPv6 deployment will enable an improved 
competitive stance from registrars whose value add services are linked to 
deployment. This will be particularly beneficial for Asian registrars.
Finally, our lower price for .NET names and our cost effective delivery of 
registry services will enable our registrars to compete with registrars of 
other TLDs. 

(ii) Use of Supplier Diversity

Just as responsible registry diversity increases overall DNS stability, 
responsible sub-vendor diversity increases the stability of .NET. Sentan and 
its parent companies, fully understand the importance of careful supplier 
choice. Both companies maximize suppliers where this is technically, 
operationally, and financially prudent. 

Our solution maximizes the security and stability of .NET by responsibly 
diversifying hardware, software, and service vendors. In addition, our program 
creates competition with these vendors, driving them to improved quality and 
service. 

HARDWARE
Our technical operator runs DNS software on Dell/Linux, IBM xSeries/Linux, and 
Sun/Solaris platforms. EPP, Whois, and SRS run on Dell and IBM xSeries. They 
also use Sun and IBM servers for the database servers and EMC and IBM as the 
storage suppliers.

They have experience operating a variety of platforms for system, storage, and 
network. They use IBM (AIX and Linux), Sun (Solaris and Linux), and Dell 
(Linux) for servers; Cisco, Packeteer, and F5 for network switches and routers; 
and Nokia, CyberGuard, Netscreen, and Cisco for firewalls. They have 
established internal technical expertise and strong vendor relationships with 
all these suppliers. They maximize use of well-established open source software 
(e.g., Apache and Linux) to minimize software impediments to hardware diversity 
and they conduct a hardware refresh for each line of business every 3 years. At 
that refresh suppliers compete based on performance, technology, cost, and 
financial stability. 

SOFTWARE
Software is generally less interchangeable than hardware. Also, enterprise 
software typically represents significant capital investment. Despite these 
inherent difficulties we have minimized  dependence on specific vendor 
software. This is primarily achieved by use of standards-based, rather than 
proprietary-based interfaces. Software suppliers include:

SRS APPLICATION (EPP AND APP) SERVICES. Our SRS services were developed 
completely in house by skilled registry staff using C++, Sun Java Virtual 
Machine (JVM), and a host of open source tools. JVM is an industry standard 
that can easily port to other vendor's platforms, such as BEA, Borland, and 
IBM. Risk is minimized, and we can switch to different tools without 
jeopardizing stability.

SRS DATABASE. The SRS database is supplied by Oracle. As the world's leading 
supplier of software and information management, Oracle possesses the requisite 
technical know-how and financial strength to ensure stability. 

WEB SERVICE SOFTWARE. Our Web service is supplied by Apache Software 
Foundation. We use open source Apache web server running on the Linux OS 
platform. Apache is the most widely used web server on the Internet. Given its 
open source nature, supplier failure is extremely unlikely.

INTEGRATION SOFTWARE. Integration software enables portions of our distributed 
software to communicate. We use Tibco and IBM. Both are large, financially 
strong vendors with global customer bases. Additionally, we adhere to standards-
based interfaces to interact and we have architecturally segmented them behind 
encapsulated interfaces.

INFRASTRUCTURE MANAGEMENT. Our infrastructure management software provides 
monitoring, measurement, reporting, and alerting services for network, 
hardware, software, and applications. Suppliers are Concord, HP, and Micromuse. 
Each was selected for a specific niche to build a best-of-breed solution. The 
full scope of products overlaps considerably. Thus, should we experience 
failure of any one supplier, the other suppliers' products would fill the gap 
without impacting our service. Like our other vendors, these suppliers are well 
regarded in the industry and have wide deployments.

FINANCIAL SOFTWARE. Diversity is difficult in this category. Our financial 
software is supplied by PeopleSoft. We believe their takeover by Oracle is a 
demonstration of the strength of PeopleSoft products. We see no risk as:

· Oracle has made a binding commitment to support PeopleSoft applications for 
10 years.

· NeuLevel, is currently a major Oracle customer 

· Our agreement with PeopleSoft contains provisions that ensure ongoing support 
in the event of acquisition. 

SERVICE PROVIDERS

HOSTING SERVICES. While the primary data center will be in a NeuLevel facility, 
Sentan has provisioned hosting services from a globally diverse set of 
providers. Each supplier services no more than 2 of our data centers. 
Additionally, both the backup SRS data center and the disaster recovery SRS 
data center are provisioned from different suppliers. 

INTERNET CONNECTIVITY. All of our 24 global points of presence, SRS, DNS, and 
WHOIS have redundant Internet connectivity. Each site has at least 2 different 
ISPs providing access service. In total, we have connectivity from more than 10 
ISPs, including such leading vendors as UUNET, AT&T, NTT, KDDI, SingTel, Colt, 
Qwest, and Sprint. Additionally 16 of our sites are located in IXPs, where we 
have direct peering relationships with the Internet.

REGISTRY OPERATOR SERVICES. In addition to being JV owners, Neulevel and JPRS 
are also suppliers to Sentan. Neulevel will supply technical operations 
for .NET and JPRS will supply research and development services (particularly 
in the areas of enhanced DNS security and stability). It is worth noting 
however that JPRS perform technical registry operations for a large TLD (.JP) 
and Neulevel perform advanced R&D work in several areas. As such, Sentan has an 
additional layer of supplier diversity in that its primary service suppliers 
have potential interchangeability.

(iii) Improved implementation of, and support for, GNSO policies

Timely and successful implementation of ICANN policies has been limited in 
the .NET registry space. By reassigning .NET, ICANN can better achieve 
consensus policy implementation through improved contractual terms and an 
operator whose corporate culture is committed to policy compliance. Sentan's 
parent companies have long and successful records in consensus policy 
formulation and implementation. We will bring a more global and collaborative 
approach to policy development and implementation. Specifically, we will 
improve implementation in the following ways: 

TRANSFERS

SENTAN WILL MIGRATE .NET TO A THICK, EPP MODEL. As discussed above in 
(i) `Competition', Transfer policies are significantly more effective in a 
thick, EPP environment. The EPP AuthInfo code mitigates most of the problems 
associated with `apparent authority' and the thick registry model obviates 
problems associated with data format incompatibility. Registries utilizing 
thick , EPP systems have a proven track record of substantially reducing 
transfer disputes relating to unauthorized transfers. Per Part 2:8 `Transition 
and Migration Plan' we will provide tools and incentives for the accelerated 
adoption of EPP and thick data in .NET. 
Sentan will introduce a set of graduated enforcement mechanisms against 
registrars who fail to distribute AuthInfo codes.

To accelerate AuthInfo adoption in .NET, and subject to ICANN approval, we will 
introduce a set of graduated enforcement mechanisms against registrars who fail 
to comply with EPP transfer policies. 

If a violation is found, we 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 the violation is not cured, or if there is a fourth complaint in 
a one-year period, the registrar will be suspended for 30 days (or until such 
time the registrar is compliant).

SENTAN WILL IMPLEMENT AN AUTOMATED EPP TRANSFER UNDO MECHANISM. In cases where 
a registrar has accidentally initiated a transfer and wants to return the 
domain name to its original state. This will improve implementation of the 
Inter-Registrar Transfer Policy.

SENTAN WILL IMPLEMENT AN AUTHINFO VALIDATOR SERVICE. As detailed in Part 
2:3.a. `New Services' we will implement an AuthInfo Validator that provides 
simplified and secure validation of AuthInfo accuracy. This service will help 
to accelerate AuthInfo adoption and promote transfers compliant with ICANN 
policy. 

SENTAN WILL DEVELOP AND DISTRIBUTE AN EXTENSIVE FAQ ON TRANSFER POLICY. We will 
create and distribute comprehensive web-based FAQ on EPP-based transfers 
including links to registrars' transfer practices.

SENTAN WILL PROVIDE BETTER POLICY EDUCATION THROUGH MULTI-LINGUAL 
COMMUNICATIONS. As detailed in Part 2:5.b.xix we will provide technical support 
in multiple languages. This will improve the comprehension of Transfer policy 
by non-English registrars and provide a better basis for compliance.

DELETES/  REDEMPTION GRACE PERIOD  

SENTAN WILL DISCOURAGE EARLY DELETIONS BY BILLING AT THE END OF THE AUTO RENEW 
PERIOD. We will follow NeuLevel's lead in being the only registry to bill 
registrars at the end of the "Auto Renew Grace Period" rather than the standard 
practice of collecting fees at the beginning of the period. We believe the 
practice of collecting fees up front drains registrar resources and places 
undue financial pressure on registrars to delete names in order to receive a 
refund. We believe collecting fees at the end of the Renewal Grace Period will 
relieve the pressure to delete names and give registrants more time to renew.

SENTAN WILL MANDATE A REDEMPTION GRACE PERIOD (RGP). The RGP was implemented by 
a number of gTLD Registries to allow registrars to restore names that were  
accidentally deleted. Despite being an extremely beneficial service, the RGP is 
not a "consensus policy" and registrars are not bound to provide it. We believe 
the RGP should be mandatory for all registrars. Therefore we will, subject to 
ICANN approval, require all registrars to implement the RGP.

SENTAN WILL REQUIRE EVIDENCE OF CONSENT TO RENEW NAMES. The current Expiring 
Names Policy requires that, absent a registrant's consent to renew (or 
transfer) a name, it must be deleted. To further the intent of this policy we 
propose requiring that registrars delete all names unless they have evidence of 
an "affirmative act" by the registrant (to either renew or transfer it) during 
the Auto Renew Period. 

SENTAN WILL PROVIDE PUBLIC REPORTS OF NAMES PENDING DELETION. We will provide 
public reports of all names pending deletion. We believe this additional 
transparency will help support adherence to the deletes policy. 

IDNs

We will improve implementation of IDN policies by:

· Deploying a "1 tag - 1 table" solution to ensure compliance with ICANN and 
international policies; 

· Implementing bundling for the Chinese language tag consistent with relevant 
stakeholders' concerns and implementations performed by leading Chinese 
registries such as CNNIC (.CN) and TWNIC (.TW); 

· Funding ISC's IDN plug-in project to ensure availability of an open source 
IDN plug in; and 

· Introducing new registrations in a language only when there is agreement by 
the relevant stakeholders for that language regarding language-specific 
registration policies.

WHOIS

MODIFIED THICK DISPLAY. The WHOIS database has become an important resource to 
a range of users including ISPs, intellectual property holders, registrars and 
law enforcement. WHOIS data consists of personal and business contact 
information, including telephone numbers, physical and e-mail addresses. In 
providing this data, many registrants are unaware it becomes publicly available 
on the internet. 

We committed in Part 2:5.b.xii to implement a fully compliant Thick Display if 
required by ICANN. We believe, however, that in order to best balance the needs 
of various user groups, a "modified Thick Display" should be implemented 
in .NET, subject to ICANN approval. This display, would contain enough 
information to contact the registrant but will also provide the registrant with 
improved privacy protection. We have modeled our proposed WHOIS display after 
several ccTLD models. 

WHOIS CONTACT VALIDATOR. Accurate WHOIS information is an ICANN policy of 
particularly importance to law enforcement, intellectual property, business, 
ISP, registrar and consumer groups. To better implement this policy we will 
introduce a new registry service, the .NET WHOIS Contact Validator (see Part 
2:3.a). 

IRIS. RFC3912 defines the WHOIS protocol known as the Internet Registry 
Information Service (IRIS). The most important improvements of IRIS over 
traditional WHOIS are set forth in Part 2:5.b.xvii. Aside from modernizing the 
WHOIS service, the ICANN community, in Task Forces 1-2, co-chaired by 
NeuLevel's Jeff Neuman, is investigating ways the IRIS could address the 
numerous privacy concerns associated with the display of registrant data.

The IRIS protocol should not be mistaken for a policy solution requiring the 
protection of a registrant's personal data. Rather, the IRIS protocol is a 
technical means to implements policies developed by the ICANN community. As 
stated in Part 2:1, Sentan will actively participate in the WHOIS policy 
development process to assist in the creation of such policies.

While policy is being developed, we believe .NET has a responsibility to be a 
leader in IRIS technical adoption and show the potential of the protocol to 
assist in policy implementation. Therefore, we commit to deploy IRIS for .NET 
within one year of transition. We will continue to provide indefinite support 
for the WHOIS protocol. We will work with the Internet community and ICANN to 
help determine potential implementations of IRIS, including its security 
features. 
   

8. Transition and Migration Plans

Criteria: Applicants should document their plan for (i) migrating .NET from the current registry operator (if applicable) with specific attention paid to maintaining existing functional capabilities as defined at the time of the RFP, including the existing RRP and (ii) for implementing support for Version 1.0 of EPP.

Present a detailed plan for the transition of the registry function from the current facilities and services provided by VeriSign, Inc., to the facilities and services you propose. Issues that should be discussed in this detailed plan include:

8.0  INTRODUCTION TO TRANSITION

WHY SENTAN
· No interruption in DNS during transition

· No interruption in WHOIS during transition
· A minimal planned 18-hour outage of the SRS for cutover operations

· Integrated approach to operator transition, RRP-EPP migration, and thin-thick 
migration minimizes registrar cost

· Requires well-defined and minimal cooperation by Incumbent
· Comprehensive contingency plans and risk reduction strategies

· Experienced staff and proven facilities to ensure stability throughout 
transition

· Multiple checks and audits to verify accuracy of data

Sentan has developed a comprehensive plan to transition the operation of 
the .NET registry from the current facilities and services provided by the 
Incumbent. With an emphasis on the overall stability and integrity of the 
registry, this plan maintains existing functional capabilities in .NET, and 
provides support for both the existing RRP protocol and EPP 1.0.

In addition to the operations transition plan, we have developed detailed plans 
for 2  related migrations: the migration of the SRS protocol from RRP to EPP 
1.0 and the migration from the current thin registry model to a thick registry 
model. In the context of our solution for .NET, these independent activities 
are fundamentally linked. Our transition and migration program integrates these 
3 plans, and acknowledges the benefits gained by undertaking the effort to 
migrate the data model and protocol simultaneously.

Our plan has emphasis on gradual change and minimizes the number of flash-cut 
events. The program provides maximum stability for Internet users, registrants, 
and registrars. Additionally, the plan requires only a minimal level of 
cooperation from the Incumbent. Compared to the .ORG transition, our plan 
provides for greater schedule and operational flexibility for registrars, 
allowing registrars to perform important migrations within a window, as opposed 
to on a fixed date. Overall, such flexibility decreases risk, improves 
stability, and lowers costs for registrars. To ensure success, the program also 
incorporates multiple contingency plans, data accuracy checks, process 
monitoring, quality control audits, and success measurement features. 

Recognizing the importance of complete operational stability during the .NET 
transition, we have already begun executing our plan in several key areas, 
specifically infrastructure readiness and RRP support. These efforts 
demonstrate our level of commitment to a successful transition and our 
understanding of the need to reduce schedule-driven risk. This combination of 
commitment and understanding demonstrates why Sentan offers the best 
opportunity for a seamless, stable, and secure transition.

Sentan's technical provider, NeuLevel, has achieved success in managing the 
complexity of creating gTLD operations. Their experience in transitioning 
the .US ccTLD, along with a careful analysis of the .ORG transition, was used 
to arrive at a detailed, practical, and proven transition plan for .NET. This 
directly relevant experience, coupled with the depth and breadth of our 
resources, makes Sentan highly qualified to offer a seamless and stable 
transition of the .NET registry.

We describe our transition and migration program in a series of sub-sections:

8.1--Steps of the plan for transition of the registry function, including 
sequencing and scheduling;

8.2--Duration and extent of any interruption of any part of the registry 
function;

8.3--Steps in the plan to migrate from a thin to a thick registry model;

8.4--Contingency plans;

8.5--The effect of the transition on (a) .NET registrants and registrars, (b) 
Internet users seeking to resolve .NET domain names, (c) performance of 
registration system, and (d) performance of the resolution system;

8.6--Any cooperation requested from the Incumbent;

8.7--Our relevant experience performing similar transitions; and

8.8--Proposed criteria for the evaluating the success of the transition.

In the subsequent proposal section, we provide a detailed description of our 
RRP/EPP protocol migration support plan. For ease of evaluation, we have 
identified the protocol migration section as Part 2:8.9.

Our transition and migration will:
· Maintain existing functional capabilities;
· Maintain existing performance levels; and
· Minimize, if not eliminate, service interruption to all users.

We will ensure the stability and integrity of .NET during transition with a 
well-balanced approach that includes:
· The right people: a seasoned and experienced registry staff;
· The right technology: an existing, scalable, and robust registry system; and
· The right plan: comprehensive in scope, offering registrar flexibility, and 
providing for contingencies.


8.1 STEPS OF THE PROPOSED TRANSITION, INCLUDING SEQUENCING AND SCHEDULING
Sentan combines the unmatched expertise, resources, and industry experience of 
2 leading domain name registry operators, NeuLevel, Inc. (with the .BIZ gTLD) 
and Japan Registry Services Co. Ltd (with the .JP ccTLD). Together, Sentan's 
parents have 8 years of experience in high-volume domain name registry 
operations, including transitioning existing Internet domain registry 
operations.

Sentan has already begun proactive transition-related activities in advance of 
the selection to ensure .NET is transitioned on-schedule in June 2005. With 
highly reliable and secure registry infrastructure and ample personnel to draw 
upon, Sentan will transition .NET on schedule with the highest levels of 
security, stability, and diversity.  The following transition plan provides 
evidence that Sentan is the ideal and best choice to do so. 

TRANSITION MANAGEMENT 
Sentan recognizes that the technical transition period is critical, and that 
management of the transition must be done in a way that guarantees stability. 
Our plan calls for all transition activities to be managed by NeuLevel's 
experienced registry staff. During this critical phase, Sentan employees will 
be working side-by-side with seasoned NeuLevel staff in Sterling, Virginia. 
This includes the Sentan front office employees, and the regional customer 
support and registrar relations teams. Centralizing the transition management 
will:
· Ensure a stable transition by fully leveraging NeuLevel's experienced staff;
· Provide a single source of support to registrars;
· Provide closely coordinated, multi-disciplinary support; and
· Provide valuable training to new employees.

Sentan will offer the Incumbent one of NeuLevel's experienced customer service 
representatives to work side-by-side with the Incumbent's support team (at the 
Incumbent's facilities) for several weeks prior to the transition and during 
the technical cutover itself. While this is not necessary for Sentan to effect 
a secure and stable transition, we believe this will greatly assist the 
Incumbent in responding to registrar inquiries concerning the transition. 
Furthermore, it will provide continuity for any support issues that span the 
cutover boundary and are transitioned to Sentan.

NeuLevel's transition management approach reflects our understanding that 
things may go wrong without proper planning and preparation. We have learned 
the best way to mitigate risk and navigate through complex activities is to 
clearly discern the most critical deliverables and impacts from the outset for 
ongoing focus and decision-making. NeuLevel's transition management approach 
places emphasis on risk assessment and contingency planning to facilitate 
making decisions. Since NeuLevel's technical staff will manage the issues that 
arise with a transition, NeuLevel's program managers will regularly compare 
progress against the most critical deliverables to make daily decisions about 
priorities and issue resolution. 

TRANSITION--KEY ACTIVITIES, STEPS, SEQUENCING AND SCHEDULING
Clear communication is essential for a successful transition. This includes 
internal communication between the successor registry, the Incumbent registry 
and the geographically dispersed registrars. Sentan believes the successor 
operator's primary mission is to keep all stakeholders informed of upcoming 
events and current progress. This is why our plan includes focus on transition 
management as an independent category with unique deliverables including:

· Regular and clear communication of status, upcoming events, and issues;

· Face-to-face planning and key milestone hand-off meetings with the Incumbent 
to clearly define expectations, identify and resolve issues, and confirm 
progress;

· Scheduling of activities in a manner that focuses on the accomplishment of 
deliverables in each category;

· Identification of all stakeholder impacts, and proactive risk mitigation 
including:

· Quickly communicating and resolving issues; and

· Educating stakeholders through the use of regular meetings between the 
Incumbent and Sentan, one-on-one registrar communication, and informational web 
sites;

· Strictly managing compliance with all external milestones and delivery dates 
working toward early delivery of items that most impact stakeholders;

· Regular progress, risk, and issue assessments to proactively adopt a 
contingency approach or resolve unforeseen problems;

· Working with geographically dispersed registrars utilizing one-on-one 
registrar relations staff, customer service staff, and established 
communication vehicles; and

· Internal and external dry runs of every technical migration to ensure smooth 
transitions.

Summarized in Exhibit 8-1a, the overall transition sequence and schedule is as 
follows. (See Exhibit 8-1b for a graphical view of the sequence and schedule):

Prior to award:
· DNS: Deploy new nameservers
· SRS & Database: Deploy RRP to OT&E environment and begin registrar testing
· Registrar Relations: Create Sentan informational web site
· Transition Management: Begin Asian and European employee searches 

MARCH 2005 (POST-AWARD)

DNS:
· Obtain initial copy of zone file from the Incumbent
· Deploy and test translator of Incumbent's DNS dynamic update file 

SRS & Database:
· Obtain initial registry database export from the Incumbent
· Begin data analysis and development of database import program
· RRP prototype testing and refinements continue

Customer Support:
· Set up new customer service offices

Policy & Legal:
· Commence ICANN contract negotiations
· Conclude outstanding vendor contract negotiations
· Initiate coordination discussions with Incumbent

Transition Management:
· Initiate communication plan
· Initiate planning meeting with Incumbent
· Obtain a list of authorized registrars from Incumbent

APRIL 2005

DNS:
· Continue dynamic update testing and add additional NeuLevel nameserver sites, 
whose names are not yet listed in the root zone

WHOIS:
· Deploy production WHOIS servers

SRS & Database:
· Establish weekly database export from the Incumbent
· Begin shakeout testing of all production systems, including Sterling, 

Charlotte and Tokyo
· Complete development of database import program and begin system testing
· Launch OT&E for registrar certification

Customer Support:
· Customer Support training

Registrar Relations:
· Prepare and distribute transition packages for registrars
· Registrar sign-up begins
· Conduct registrars seminars and webinars

Policy & Legal:
· Finalize new registrar agreements
· Long-term agreements for offices in Asia and Europe
· Continue coordination discussions with Incumbent

Transition Management:
· Registrar Certification testing begins 
· Provide regular status updates

MAY 2005

DNS:
· Deploy and test translator of the Incumbent's incremental DNS update file
· Generate, test, and finalize DNS zone from database import program

WHOIS:
· Shakeout testing of WHOIS sites
· Generate, test, and finalize WHOIS database from database import program

SRS & Database:
· Data analysis and development of database import program
· Establish weekly database exports from the Incumbent
· Continue shakeout testing of all .NET production systems

Customer Support:
· Hire new CSR employees for regional offices
· Customer support training

Registrar Relations:
· Begin registrar connectivity tests
· Continue registrar seminars and webinars

Policy & Legal:
· Continue to finalize new registrar agreements

Transition Management:
· Continue registrar certification testing
· Set up registrar debit accounts
· Provide regular status updates

JUNE 2005

DNS
· Finalize zone file generation from database import program

· Begin DNS transition:

· b.gtld-servers.net nameserver removed from IANA root zone.  b.dns-ops.net 
added to IANA root zone.

· {c-e}.gtld-servers.net nameservers removed from IANA root zone.  {c-d}.dns-
ops.net added to IANA root zone.

· {f-i}.gtld-servers.net nameservers removed from IANA root zone.  {e-f}.dns-
ops.net added to IANA root zone.

· {j-l}.gtld-servers.net nameservers removed from IANA root zone.  {g-h}.dns-
ops.net added to IANA root zone.

· {m-a}.gtld-servers.net nameservers removed from IANA root zone.  {i-a}.dns-
ops.net added to IANA root zone.

WHOIS
· Finalize WHOIS database generation from database import program

SRS & Database
· Establish daily database exports from the Incumbent
· Finalize data analysis & database import program
· Finalize .NET production systems and "clean" database
· Prepare SRS for rolling start (June 15th)

Customer Support
· CSR training
· Provide CSR to work with Incumbent support team

Registrar Relations
· Continue registrars seminars and webinars
· Continue registrar connectivity tests

Transition Management
· Initiate rolling start of contact operations
· Ongoing registrar certification, provisioning and testing
· Provide regular status updates
· Employee training as required
· Verify registrar credentials in SRS & Firewall
· Final registrar connectivity tests


JULY 2005 - TRANSITION CUTOVER

Technical Transition

Begins at 22:00:00 on 6/30/05

1. Open external status teleconference for ICANN, registrars and Incumbent
2. Incumbent shuts down .NET SRS (00:00:00 on 7/1/05)
3. Incumbent generates database export
4. Incumbent verifies integrity of the export file
5. Incumbent delivers export file to secure NeuLevel file server
6. NeuLevel receives file and verifies integrity of the data
7. NeuLevel runs database import program
8. NeuLevel performs data integrity check
9. NeuLevel generates and validates DNS zone file
10. NeuLevel generates and validates WHOIS database
11. WHOIS database deployed to all WHOIS servers
12. NeuLevel starts all SRS processes
13. NeuLevel opens firewall to all Registrars for normal production operations
14. Cutover complete: 18:00:00 on 7/1/05

TRANSITION PREPARATION DETAIL
A smooth and successful transition will rely upon the successor's advanced 
preparations and planning. This phase includes all activities required to 
prepare for the technical and operational transition of the .NET registry. As 
Sentan's registry operator, Neulevel proactively initiated its transition 
preparations in late 2004 and will continue the effort through evaluation, 
award, and up to the transition date. 

The objectives of transition preparation are to ready all the hardware and 
software, finalize all business operations and procedures, and fill open Sentan 
positions. In addition, NeuLevel will begin augmenting its staff in key areas. 
The following provides a detailed description of the transition plan, beginning 
in January 2005 and through transition and beyond.  

OVERALL SYSTEMS PREPARATION
NeuLevel is uniquely qualified to conduct the .NET transition. This is 
evidenced by the following key facts:

· NeuLevel has already started expansion of its DNS network, spread across more 
than 20 geographic locations. Additional information concerning our DNS 
infrastructure can be found in Part 2:5.b.ii.

· NeuLevel is already prepared to support both RRP and EPP 1.0, in parallel. 
Supporting both environments provides registrars with maximum flexibility and 
allows for a seamless transition. Registrars will be able to migrate to the 
Sentan Registry with virtually no changes to their existing systems. Additional 
information concerning support for RRP and EPP 1.0 can be found in Part 2:8.9.

· NeuLevel has already designed and deployed an RRP OT&E environment. This 
environment has been designed to be identical to the environment registrars use 
today with the Incumbent. Registrars are initiating testing, and will continue 
through the pre-transition period, until we are satisfied that the 
implementation exactly replicates the Incumbent's offering. 

In addition to a fully functional OT&E environment, NeuLevel will offer an 
interactive test environment for those registrars who wish to confirm their 
interoperability with the new registry system. We will work with registrars to 
offer an additional pre-transition connection period prior to the official 
transition date. During this time, registrars can test credentials, digital 
certificate installation, and operational readiness of registrar systems and 
networks. Such an approach proved valuable to registrars during the .US launch 
and supported universally, concurrent, equivalent access for the first-come, 
first-served (FCFS) launch. Connections to the SRS will be allocated in a fair 
and equitable manner to avoid any registrar transactions delays. All registrars 
will receive an equal number of connections. Our traffic management 
capabilities will be leveraged to ensure fair and uninterrupted service across 
all .NET registrars. 

Moreover, Sentan will offer a full complement of registrar support services, 
including:

· Customer support staff available 24/7/365 via toll-free phone, e-mail, and 
chat;

· Multilingual customer support offered in over 100 languages;

· Global outreach and education activities conducted by senior registrar 
relations staff with participation by technical or operations personnel as 
needed; 

· Technical tools and documentation including registry toolkit and credential 
creation;

· Registrar service interface via a personalized .NET registrar website;

· Interactive test environment with full functionality and test script 
documentation;

· Pre-launch connectivity environment with 24/7/365 technical support staff; and

· Marketing and media-relations staff.

TRANSITION DETAIL
The cutover of the .NET registry will occur during the Transition Phase of the 
overall plan. During this phase, Sentan and NeuLevel will execute all steps 
necessary to transition the SRS and database, DNS, WHOIS, and all supporting 
functions such as billing and reporting. Sentan has designed a thorough, 
detailed plan to accomplish this in a manner that eliminates any impact to the 
registrants and Internet users, and minimizes any burden on registrars. 

The following contains details related to the transition of DNS, the SRS and 
database, WHOIS, and customer service. A detailed time-line outlining the steps 
of the transition follows the descriptions below, and is illustrated in Exhibit 
8-1b.

DNS PREPARATIONS 
As detailed later this section, our DNS transition plan calls for a gradual 
phasing of DNS nameservers from the Incumbent to Sentan, while maintaining the 
current update process. NeuLevel will request that the Incumbent provide 
dynamic DNS updates in an agreed-upon format during the transition period.

With the introduction of dynamic DNS updates by the Incumbent, Sentan must have 
the capability to publish dynamic incremental updates for the Incumbent during 
transition, switching to internal updates upon the transition date.

The .NET community would be best served with a phased DNS migration with a 
transition that is transparent to the .NET stakeholders and does not compromise 
the security and stability of the .NET domain space. 
		
The proposed "rolling" migration would occur over a period of several weeks, 
beginning in mid-June and conclude on the transition date. The plan requires 
cooperation from the Incumbent operator in only a few key areas, including a 
coordinated plan to remove and add DNS nameserver entries from the IANA root 
zone and providing NeuLevel with dynamic DNS feeds. In the event the Incumbent 
fails to provide the necessary cooperation, we have a contingency plan which is 
outlined in Part 2:8.4.

Our plan features no disruption of DNS resolution, and importantly, the DNS 
nameservers are never out of synchronization with one another. To accomplish 
this, we will gradually replace the Incumbent's .NET nameservers with Sentan 
nameservers in the IANA root zone.  When a replacement is made, the Incumbent 
will operate them after cutover, long enough to account for client caching.  

Unlike during the .ORG transition when zone updates were performed in bulk once 
or twice per day, the Incumbent for .NET is dynamically updating their 
nameservers in near real-time, as NeuLevel does in .BIZ.  Thus, even though we 
will be adding NeuLevel sites and removing the Incumbent's sites over time 
during transition, dynamic updates must still be pushed to all of the 
nameservers, both NeuLevel's and the Incumbents. 

Since the Incumbent operates the SRS before transition, it is the only source 
of these updates. If the Incumbent fails to provide incremental updates during 
transition, two options exist for handling a lack of dynamic DNS updates: 
first, the Incumbent could return to the bulk update process and DNS updates 
were pushed in bulk twice per day to their own nameservers as well as to the 
NeuLevel nameservers. Second, the Incumbent can continue with its current 
process of providing incremental dynamic DNS updates and provide the same 
incremental update to NeuLevel in the format of their choice.  NeuLevel would 
then use a dynamic update translator that would convert the Incumbent's updates 
and translate them into the standard IXFR format that is compatible with 
NeuLevel nameserver software. This translator would be necessary as the 
Incumbent operates proprietary nameserver software that is likely to be 
incompatible with the IETF standard mechanism. 

Even though it is operationally easier to implement, the bulk update option is 
the least desirable. It would require a reconfiguration of the service by the 
Incumbent, and would impact registrants and Internet users. Consequently, we 
are proposing the dynamic update translator option. While this involves 
additional effort, it is necessary to ensure the continuation of current 
service levels.

Immediately following award, we will initiate discussions with the Incumbent to 
begin receiving updates via the Incumbent's dynamic update process.  NeuLevel 
will translate the data format into one our nameserver software can read, and 
subsequently push the updates out to our DNS servers.  This process will go 
through continual testing during the period of award (March) to the start of 
DNS transition in June.

The following are key DNS deliverables during the transition phase:

· Full testing of zone file hosting and transfer functionality;
· A plan for changes to the IANA root zone for the entire transition timeline;
· A gradual transition of geographically dispersed nameservers; and
· Full support for dynamic DNS updates throughout the transition period

NeuLevel operates 24 nameserver sites utilizing a mixture of Anycast and 
Unicast.  The Incumbent operator currently operates 13 gTLD servers ({a-m}.gtld-
servers.net), while NeuLevel will represent our 24 sites with 9 nameservers ({a-
i}.dns-ops.net). It is important to note that NeuLevel will operate three of 
these nameservers in an Anycast configuration. These three Anycast nameservers 
are equivalent to 18 geographically dispersed nameserver sites. In addition to 
these 18 Anycast sites, NeuLevel will operate 6 Unicast sites. Additional 
details concerning the NeuLevel's DNS configuration can be found in Part 
2.5.b.ii. 

SRS AND DATABASE CUTOVER  
The transition of the SRS and database is a central part of the transition 
plan.  The plan addresses the following transition criteria:
· Minimize SRS downtime;
· Comprehensive testing and data migration dry runs;
· Ability to transition within the proposed cutover window;
· Support for existing RRP and EPP 1.0; and
· Support all existing business rules and policies.

A successful transition minimizes the impact on registrars and registrants. 
NeuLevel's plan calls for an 18-hour cutover period on all SRS activity. This 
cutover period is necessary to freeze the existing data, create a full export 
of the database, prepare the data to be loaded into Sentan's SRS database, and 
test the integrity of the data. The cutover activities will not impact DNS 
resolution in any way and will be transparent to Internet users.

The Sentan plan calls for all existing registrars to transition using the 
protocol of their choice.  Our plan supports both, RRP and EPP 1.0 providing 
for an easy cutover for registrars. 

Registrars also require a window of time to reconfigure and test their 
interfaces against the new registry. This pre-defined period of time supports 
all registrars to ensure concurrent equal access at the exact time 
administrative services are restored.

Although SRS transactions will be halted for a short period of time, the 
cutover period will not interrupt critical domain services such as DNS, WHOIS, 
and emergency DNS zone updates. While the SRS is unavailable for normal 
operations, we will have a fully-staffed help desk to facilitate emergency DNS 
zone updates. Thus, our SRS transition plan will not impact end-users or 
registrants' ability to use .NET.

INTERNATIONALIZED DOMAIN NAMES (IDNS)
The Internet as a whole, and domain names in particular, have a greater need 
than ever for true globalization. NeuLevel firmly understands this need, and 
will not only support existing IDNs as part of the transition, but will also 
improve upon the service, as follows:

· To improve the service to the .NET users, Sentan will adopt a "1 tag-1 table" 
solution. Each language that we support will have its own tag and its own 
table. This is in complete compliance with ICANN guidelines. 

· All existing names in the .NET database at cutover will be grandfathered in 
the new .NET database with NeuLevel. See Part 2:5.b.xvii for further 
information on IDNs. 

WHOIS SERVICE
The .NET WHOIS service offers information to registrants, end users, and 
registrars. Sentan will transition WHOIS without any interruption.  Our plan 
calls for a transition under which the Incumbent continues to operate the WHOIS 
service through the cutover period until the conclusion of the database 
transition. After completing the database load, we will create a new WHOIS 
database and begin resolving queries immediately upon completion of the 
moratorium. WHOIS servers will be updated dynamically from this point forward. 
At that time, the Incumbent should refer all users of their WHOIS to ours.

Until all registrars have completed the migration from thin to thick, we will 
only display "thin" data in WHOIS. Sentan considered displaying thick WHOIS 
data, and allowing domains that have not been updated or migrated to show 
domain contacts as "Unknown." We determined that this had the potential to 
create confusion for registrants and WHOIS users. The .ORG transition report 
supports this conclusion.

CUSTOMER SUPPORT
Immediately upon award, Sentan will begin filling open positions in its Asia-
Pacific and EMEA offices. Local recruitment agencies have already been 
contracted, and are currently recruiting qualified personnel. Sentan will be 
staffing its Asia-Pacific and EMEA office with multi-lingual customer support 
representatives (CSRs). 

Sentan plans to hire the new CSRs in early May, and train them at NeuLevel's 
Sterling, Virginia headquarters. By providing training in Sterling, these CSRs 
will benefit from working side-by-side with NeuLevel's experienced customer 
service team. At the conclusion of hands-on involvement in the transition 
phase, they will be deployed to the Asian and European offices. 

ON-GOING TRANSITION ACTIVITY DETAILS
The third phase of the transition includes various activities that occur after 
that technical transition on July 1. These activities include grace period 
extension, billing and collections, registrar relations, completing transition 
to Sentan international offices, and conducting post-transition evaluation and 
reviews.

As some SRS transactions (i.e. transfers) require several days to complete, and 
are impacted by various grace periods, certain preparations are needed. To best 
serve the registrants, the Incumbent will provide the historical context of all 
domains to allow us to accurately calculate grace periods that cross over the 
transition.  After the cutover period, as a service to registrants, Sentan will 
simply extend all in-progress grace periods by 24 hours. This will minimize 
registrar and registrant concern regarding the precise end time of these grace 
periods. The following describes the grace periods and how in-flight 
transactions will be impacted:

· Add/Transfer/Renew Grace Delete Periods (5-days)--All domains created, 
transferred or renewed within 120 hours prior to the cutover period will have 
their deletion grace periods extended by 24 hours. A list of affected domains 
will be provided to registrars at the conclusion of the cutover period.  
Additionally, during the first 5 days of operation all deletes during the add 
grace period will be put into Redemption Grace Period (RGP), rather than being 
deleted.  This will ensure protection of the name in the event there is a 
dispute.

· Transfer Ack/Nack Period (5-days)--The ack/nack period for all pending 
transfers initiated within 120 hours prior to the moratorium will be extended 
by 24 hours. A list of all affected domains will be provided to registrars at 
the conclusion of the cutover.

· Redemption Grace Period (30-days)--The redemption grace period will be 
extended for 24 hours for all domains that are within the grace period at the 
time of the cutover. A list of all affected domains will be provided to 
registrars at the conclusion of the cutover.

· Auto-renewals--All domains expiring during the cutover will be auto-renewed 24 
hours following the conclusion of the cutover. Following the cutover, all 
domains within the 45-day auto-renew grace period will receive a 24-hour 
extension to the grace period.

· Domain Drops - All domain drops that would have occurred during the cutover 
period will occur 24 hours after the conclusion of the cutover. A list of 
domains and precise drop times will be provided to registrars.

BILLING AND COLLECTIONS
The billing and collection of registration fees is an important part of the 
registry's operations, and there are some unique considerations the successor 
must take into account during the transition. 

Sentan's approach is to ease the initial registrar funding requirements by 
setting the minimum funding level lower than normal for the first two weeks 
following transition. Registrars will likely be required to keep a funded 
account at the Incumbent up until the transition date. At the same time, 
registars will need to pre-fund their debit accounts at Sentan prior to the 
transition. For some period of time a registrar may find that it will require 
two funded .NET debit accounts (one with the Incumbent and one with Sentan). 
For some registrars, this may be financially burdensome. Our plan will aid 
registrars in transitioning from the Incumbent to Neulevel with minimal 
financial difficulty impact.

Sentan has identified situations in which billable transactions processed by 
the Incumbent in the final days before the transition will be deleted within 
the applicable grace period following the cutover date. In these situations, 
the registrar will be entitled to the applicable credit. The various types of 
transactions where this may occur include: auto-renew deletes, add deletes, 
transfer deletes, and renew deletes. The majority of these credits will be the 
result of auto-renew deletions due to the auto-renew grace period (45 days) for 
which the Incumbent is still holding funds. 

We estimate that the total amount of the credits for all types of delete 
transactions could exceed US$1 million. Sentan will issue the appropriate 
credit to registrars, based on the Incumbent's then-current pricing. We will 
then submit a detailed statement to the Incumbent for reimbursement to Sentan 
for the credited amount. This is appropriate because funds collected prior to 
the cutover date for domains that are deleted within the acceptable deletion 
grace period term would have been returned by the Incumbent to the registrar 
had the cutover not occurred, or should it have occurred a week or month 
later.  They are not like funds collected by the Incumbent for ongoing 
registrations (i.e., existing names in the .NET database) in that these refunds 
are for services never provided.

Under the existing .NET agreement, the Incumbent would have returned the domain 
transaction fees in question to the registrar. As such, the Incumbent is not 
entitled to keep those fees, even in the event the registry operations 
transitioned to a new service provider. Sentan will extend these credits to 
affected Registrars to eliminate any financial burden during the transition 
phase, but Sentan will need compensation from the Incumbent for those credits.

In the event the Incumbent is not cooperative and refuses to reimburse Sentan 
for the credits, we will provide, at our own expense, credits for any 
transaction that occurred within the 7 days prior to the cutover date, provided 
that the applicable grace period is still in effect. This would include all 
deletions of adds, transfers and renews that occurred in the 5 days prior to 
transition. In addition, it would include deletions of all auto-renews that 
occurred during the 7 days prior to transition. During its initial planning 
meetings with the Incumbent, Sentan will raise this issue and seek its 
concurrence. If the Incumbent indicates its intent to not provide reimbursement 
for the credits, Sentan will send an announcement to all registrars informing 
them of our intent to only credit for deletions of transactions that occur in 
the 7 days prior to transition. Advance notice will allow registrars to make 
the necessary adjustments to their internal processes so that deletions may be 
submitted prior to transition.

REGISTRAR RELATIONS 
Our transition plan takes into account the needs of geographically dispersed 
registrars, smaller, less-resourced registrars, and those registrars seeking 
accreditation. It also supports varying degrees of technical know-how, staffing 
and industry participation.

Sentan is committed to facilitating registrar competition, globalization of 
service offering, and a focus on service excellence. Sentan's objectives in 
this area include:

· Fair, equal, and high-value service across all accredited registrars;
· Widespread and new registrar participation;
· State-of-the-art registry services; and
· Customized services.

Our technical operator, NeuLevel, has a solid reputation in the registrar 
community as an experienced registry. It currently has existing relationships 
with over 150 .NET registrars, who collectively account for over 98% of the 
current .NET domain registrations. The experience gained from serving these 
registrars has been invaluable  in creating our registrar relations transition 
plan.  This comprehensive initiative includes plans to:

· Provide details about contract award and the Sentan proposal to registrar 
community;
· Begin outreach program to elicit registrar ideas about .NET transition 
activities;

· Commence contract compliance program to sign Registry-Registrar Agreements 
with all ICANN-accredited registrars for .NET;

· Provide regular transition status reports with updated schedule and registrar-
related issues and risks;

· Work with registrar financial contacts to walk through billing processes and 
establish such deliverables as reports and accounts;

· Work with registrars to obtain digital certificates and other registry 
credentials;

· Work with registrars to ensure compliance with existing .NET registry 
Toolkit, and making improvements as required;

· Offer an online test environment with technical support staff available to 
assist registrars with testing; 

· Clearly and regularly communicate deadlines and cutover details; and 

· Facilitate a transition forum where registrars can ask questions regarding 
the service transition.

POST-TRANSITION EVALUATION
In the months immediately following the technical transition, and throughout 
the protocol migration, Sentan will conduct a thorough review and post-
evaluation of the transition process. Throughout the entire transition period, 
through all three phases, a dedicated person will be assigned to document the 
entire transition process. We will provide  weekly status reports, posted to 
our website. In addition, a full transition evaluation report will be provided 
to the ICANN community following completion of the technical transition, with a 
follow-up report at the conclusion of the RRP to EPP and thin to thick 
migrations. Additionally, details concerning evaluation reporting can be found 
in Part 2:8.8.


8.2  DURATION AND EXTENT OF ANY INTERRUPTION OF ANY PART OF THE REGISTRY 
FUNCTION
The time period of any interruptions to Registry Functions will be limited to 
the cutover period, currently planned for 18 hours beginning at or about 
23:59:59 PDT June 30, 2005.

SRS operations, DNS dynamic updates, WHOIS dynamic updates, and any web-based 
registrar administration system will be interrupted during the cutover period.  
During the cutover event, we will have a fully staffed help desk to facilitate 
the propagation of emergency DNS updates while the SRS is down.

The Incumbent's WHOIS service will remain operational during the cutover 
period, serving data that reflects the last transactions made to the SRS before 
the cutover begins.  At the end of the cutover period, the Sentan WHOIS will be 
launched and the Incumbent's WHOIS will be disabled.  Individual users 
connected to the Incumbent WHOIS at the time of its shutdown will need to 
reconnect to the Sentan WHOIS.
 
There will be no interruption to DNS resolution during transition.


8.3 IF A THICK REGISTRY MODEL IS INTENDED, THE STEPS FOR MOVING FROM THE 
CURRENT THIN REGISTRY MODEL TO A THICK REGISTRY MODEL.
As described in Part 2.:5.b.xii, Sentan proposes that the .NET registry operate 
on a thick model.  This section contains the migration plan for moving the 
registry from thin to thick models.  This involves adding contact data to all 
domains created under the thin model and applying business rules that require 
the existence of contact data for all new domains. 

The migration of .NET to a thick registry model is not the first such migration 
for a sizable gTLD.  Our approach builds on and improves previous migration 
efforts in .ORG.  Our plan allows each registrar to:

· Sequence migration steps in a custom fashion;
· Migrate on a schedule of its own choosing (subject to an overall deadline);
· Unilaterally change its migration schedule;
· Gracefully transition without a flash cut; and
· Use a standard EPP 1.0 client, with no migration-driven extensions.

We selected a gradual transition with a registrar-oriented schedule to provide 
flexibility to the registrar community.  The key to this approach is the 
ability to provision contact data without having to move fully to a thick 
model.  This avoids the need for a disruptive flash cut.

BACKGROUND: DATA MODEL COMPARISON
The current thin data model for .NET is significantly different from our 
proposed thick model.  The following summarizes the main impacts of thick data 
collection on 3 types of thick registry objects (Domain, Host, and Contact) and 
compares thin to thick in the context of the registry data model. 

DATA DIFFERENCES BETWEEN THIN AND THICK
Object (Entity) Type--Domain 
Thin 
· References to NameServer entity(s) are optional
· No data linking the domain to contact information for registrant,
  administrative, technical or billing contacts
· No data element to hold authorization information

Thick 
· References to Host object(s) are optional
· References to Contact object(s) for Registrant, Admin Contact, Tech Contact,
  Billing Contact required for creation 
· AuthInfo code for authorization

Object (Entity) Type--Host
Thin
· No differences 
Thick
· No difference 

Object (Entity) Type--Contact
Thin
· Not applicable
Thick
· Includes name, postal address, city, state/province, postal code, country,
  email, phone number(s), etc.

As shown above, a key difference 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 significant to data model migration.  
There are other differences regarding details such as status fields and date 
information.

PREPARING FOR MIGRATION: DATABASE CONVERSION
The conversion to a thick registry model begins with the loading of the .NET 
database into the NeuLevel SRS at cutover.  During the conversion each data 
element in the SRS is handled in a defined way; some elements are directly 
imported, some elements are converted, and some are auto-populated.

In order to accommodate the lack of Contact data, the constraints on the Domain 
object are relaxed.  Thus, the newly imported Domains do not hold any 
references to Contact objects.  In this discussion, such Domain objects are 
known as "Thin Domains".  Fully populating all Thin Domains with required 
references to Contact objects is the overall goal of the data population effort.

Another important data element is the AuthInfo code. The AuthInfo code is 
needed for authenticating transfer requests using the EPP interface.  Since 
this element is not present in the thin model, it must be auto-generated on 
conversion.  Our import process generates a strong random AuthInfo code and 
populates it. 

An alternative approach, which would leave the AuthInfo code unpopulated, would 
require the sponsoring registrar to provision an AuthInfo code before the 
domain is transferred.  We do not favor this approach as it could negatively 
impact a registrant's ability to transfer a domain.  Our approach allows the 
sponsoring registrars the flexibility of later changing the AuthInfo code, but 
does not require them to do so.

STEPS IN PERFORMING REGISTRY DATA MODEL MIGRATION
As described below in 8.9, the move from RRP to EPP 1.0 enables the move from 
thin to thick.  There are three stages of EPP migration:
· 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; and
· Stage 3 - The final stage, enforcing the thick data rules.

Using these stages, a registrar follows these steps to migrate:

Step 1: Achieve certification at either EPP 1.0 Stage 2 or 3.  SRS business 
rules for both Stage 2 and 3 allow the management of Contact objects.  SRS 
business rules for Stage 2 optionally allow Contact object references to be 
provisioned with Domain objects, while rules for Stage 3 require such 
provisioning for Domains.

Note: SRS permits EPP 1.0 in a thin mode via Stage 1.  This stage is for 
registrars that are just beginning the protocol migration.  (Please see Section 
8.9 for a full explanation of EPP 1.0 Stages 1, 2, and 3.)

Step 2:  Create Contact objects in the SRS for each of the contacts in its 
WHOIS database that are associated with a .NET domain as either an 
administrative, technical, or billing contact; or a registrant.  Working at its 
own pace, a registrar can populate this contact data.

Step 3:  For each sponsored Thin Domain, transform it into a Thick Domain 
object by using the Update Domain command to add required Contact references 
for the registrant along with the administrative, billing, and technical 
contacts.  SRS business rules permit this task to be done incrementally for 
each Domain.  That is, the registrar can issue multiple Update Domain commands 
and partially provision the required Contact references.  This approach exists 
to provide the flexibility in the rate and sequencing of these updates. 

Each registrar must accomplish two milestones to complete the data model 
migration process:

· All Domain objects sponsored by the registrar have required Contact 
references (the registrant along with at least one administrative, billing, and 
technical contacts); and

· Operating at EPP 1.0 Stage 3: This is the ongoing mode of EPP operations and 
enforces all business rules regarding Domain objects requiring Contact object 
references in the registrant field along with the administrative, billing and 
technical contacts.

After a registrar has accomplished these 2 milestones, its data model migration 
is complete.

For the registry as a whole, the data model migration period formally begins on 
transition day (cutover).  Due to the support of EPP 1.0 Stages 2 and 3 on 
transition day, a certified registrar can begin data model migration 
immediately upon cutover. Key milestones for data model migration occur as 
follows:

· End of EPP 1.0 Stage 1 support: February 1, 2006 (Transition + 7 months):  
After this date, all registrars will be operating on EPP 1.0 Stage 2 or 3;

· End of EPP 1.0 Stage 2: March 1, 2006 (Transition + 8 months):  After this 
date, all registrars will be operating on EPP 1.0 Stage 3; and

· End of data model migration period: April 1, 2006 (Transition + 9 months):  
After this date, all registrars must have thick data for all sponsored domains.

Upon the completion of the data model migration period, all domains should have 
associated contact data. A registrar that has failed to populate contact data 
for its sponsored domains will be non-compliant with the registry-registrar 
agreement.

PROGRESS REPORTING
To ensure accurate progress information, we will provide each registrar 
certified at EPP Stage 2 or 3 with a monthly report listing sponsored domains 
that lack contact data. This will be known as the "Thin Domain" report. Each 
registrar's Thin Domain report will only list the domains it has sponsored that 
lack a full complement of contacts. A registrar that has populated its entire 
set of sponsored domains will receive a report that lists no names. Information 
about each registrar's sponsored domain status will be confidential. The Thin 
Domain report will help registrars understand the amount of work remaining in 
the data model migration effort. We anticipate registrars will segment their 
sponsored thin domains and populate them using EPP during periods of low retail 
volume.

During the last eight weeks of the migration, the frequency of the Thin Domain 
report will be increased to once per week. The registry customer support 
offices will work closely with registrars that have not completed data model 
migration.

Given that thin domains can be transferred without being fully populated with 
contact data, it is possible for a registrar to accomplish the goal of 
migration and then assume sponsorship of Thin Domains via a transfer 
operation.  In this case, the gaining registrar would simply provide the 
contact information following the completion of the transfer.

ASSISTING THE TRANSITION
Our plan also calls for the following registrar-focused initiatives:

· Incentive for Migration--One of the challenges of allowing registrars to 
determine the timing of data model migration is the natural tendency to allow 
other important registrar activities to take precedence over the migration. To 
provide an incentive to registrars to complete the migration in advance of the 
required dates, Sentan offers two 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 experience. We have 
carefully designed it to provide incentives for registrars to promptly complete 
the migration.

· "Rolling Start" for Contact Creation--As described in 8.1, we propose 
a "Rolling Start" method of SRS launch.  This approach, which opens the SRS in 
advance of transition day for Contact operations, has two key benefits.  It (i) 
provides registrars a means to test connectivity into the successor SRS and 
(ii) lets registrars pre-load Contacts, initiating their data model migration 
even in advance of transition.

· Data Scrubbing Service--To assist registrars with this migration, we will 
provide a free data contact data "scrubbing" service. This service will allow a 
registrar to submit contact data in a defined XML or CSV format to the 
registry. The registry will apply relevant syntactic changes to reformat the 
data to be compliant with EPP contact edits. The reformatted data will be 
returned to the registrar (in XML or CSV format). Thus reformatted, the contact 
data will reflect the EPP contact data edits.


8.4	CONTINGENCY PLANS IN THE EVENT ANY PART OF THE PROPOSED TRANSITION 
DOES 
NOT PROCEED AS PLANNED.
NeuLevel and its parent company, NeuStar, have direct, recent, and relevant 
experience with contingency planning.  We critically evaluate all completed 
programs to improve our systems, processes, education, and approach.  The .BIZ 
launch supported improvements in our registry implementation approach that are 
effectively incorporated in our .NET transition plan

The .NET transition contingency list below provides mitigation activities as 
well as contingency plans.  The contingency plan is flexible, and will be 
continuously evaluated and updated as the transition progresses, new 
information is uncovered, or a new issue presents itself.  

Risk: Incumbent fails to support "rolling" DNS nameserver migration.
Mitigation:  Early, joint planning to maximize Internet stability.
Contingency plan: Flash cutover of DNS. 

Risk: Incumbent fails to provide incremental dynamic DNS updates during 
transition
Mitigation:  Provide flexible options to either accept Incumbent's format or 
allow. Incumbent to determine data feed format.
Contingency plan: Bulk update of DNS during transition.

Risk: Incumbent fails to provide database export at regular intervals during 
transition.
Mitigation:   Early, joint planning to determine agreeable data format; 
automate data delivery to minimize manual intervention.
Contingency plan: Utilize Incumbent's escrow data.

Risk: Inconsistent format of Incumbent's data export.
Mitigation:  Establish schedule of daily delivery 21 days before cutover; 
design import software to be readily adaptable.
Contingency plan: Adapt data import software.

Risk: Protocol issues with our implementation of RRP.
Mitigation: Establish RRP OT&E in January 2005, establish comprehensive test 
plan, test with registrars.
Contingency plan:  Adapt software and continue testing.

Risk: Incumbent fails to provide information on various current business 
operations (registrars, services, trouble tickets, disputes, etc.).
Mitigation: Establish clear list of requirements; provided flexibility in 
delivery format.
Contingency plan: Work with other parties (registrars, etc.) to establish 
operational context.


8.5	THE EFFECT OF THE TRANSITION ON (A) REGISTRANTS AND REGISTRARS; (B) 
INTERNET USERS; (C) PERFORMANCE OF REGISTRATION SYSTEM; (D) RESOLUTION SYSTEM
The transition of the .NET to Sentan will result in a new era of globalization, 
transparency, standards compliance, and accountability in the operation of this 
prominent TLD.  The entire community will reap the benefits of our plan to 
manage .NET in a way that is policy-compliant and responsive to the needs of 
registrars, registrants, and Internet users.

In this section, we describe the overall effect of the transition on 
registrants, registrars and Internet users; the performance of the registration 
system; and the performance of the resolution system.  Given our significant 
investment in pre-transition activities, the comprehensive nature of our 
transition plan and the quality of our contingency planning, the effects during 
cutover (as detailed above in 8.2) will be minimal for these stakeholders.

REGISTRANTS AND REGISTRARS
Centralized ("thick") registration data - Registrants will benefit from the 
registry's thick data model by having a single, authoritative source for WHOIS-
based registration data.  This eliminates the current need to visit both 
the .NET registry WHOIS and a registrar WHOIS to retrieve registration data.  
Registrars will benefit from the registry's thick data model and WHOIS by its 
elimination of the technical need to offer their own WHOIS service. This 
contributes to overall lower registrar costs by allowing the development, 
operations, and hosting resources to be diverted to other efforts. In addition, 
the thick registry model makes domain contact data more auditable, as all such 
data is centralized.

Dynamically Updated WHOIS - Registrants will benefit from our introduction of 
dynamic update to WHOIS by being able to see changes to the SRS in near-real 
time.  Currently, the frequency of WHOIS updates varies widely among 
registrars.  Since DNS is also updated dynamically, for the first time WHOIS 
and DNS will reflect data at the same point in time and will be synchronized.

In this way, there will be less confusion on this issue, since changes to WHOIS 
and DNS are synchronized.    Registrars will indirectly benefit due to a 
reduction in the number of questions about WHOIS data inconsistencies.

Global Support--The Sentan registry support team will have three offices 
worldwide and provide global consistency of support with a regional focus. Due 
to the importance of equal access and enhanced competition, we will support 
over 100 languages 24x7 with the assistance of our translation service provider 
and 7-10 core languages with our in-house support personnel. We will have 
offices in Tokyo (at Sentan Headquarters), Sterling (co-located with NeuLevel) 
and Rome. These offices will conduct existing Registrar Support, new Registrar 
Outreach, support of ICANN's Policy Development Process. By locating a support 
office in Rome, we have identified a central location for support and outreach 
in Europe, the Middle East and Africa. All three offices are located in cities 
where qualified, multi-lingual support personnel and a suitable infrastructure 
exist to enable high-quality service. Sentan's parents have provided Registrar 
support services for 4 years in support of .BIZ and .JP.

Improved Transfers--After transition, registrants and registrars will experience 
a variety of improvements in the model for domain transfers.  The registry's 
thick data model will eliminate the contact data format mismatches that are 
common in the current thin data model.  The addition of the EPP AuthInfo code 
will significantly lower transfer reject rates.

IDNs--Current IDN registrations will not be affected by the transition.  After 
transition, using a "1 tag, 1 table" solution, Sentan will begin accepting IDN 
registrations in 10 languages in which the relevant stakeholders have agreed 
upon language-specific rules.  For Chinese-language IDNs, language-specific 
rules exist with the relevant stakeholder community, but the current .NET 
approach to bundling does not fully comply with these rules.  The current .NET 
IDN policies are also problematic for languages that currently lack language-
specific policies.  For both of these scenarios, we will freeze registrations 
with plans re-launch registrations in the near future as relevant stakeholder 
policies are finalized.  

New Services--Registrars will benefit from a variety of additional registrar 
services.  There are described in Part 2:3.a and include:
· AuthInfo code validator;
· WHOIS contact validator; and
· Automated registry-registrar messaging.

INTERNET USERS
Centralized ("thick") registration data - Internet users will benefit from the 
registry's thick data model by having a single, authoritative source for WHOIS-
based registration data.  This eliminates the current need to visit both 
the .NET registry WHOIS and a registrar WHOIS to retrieve registration data.

IDNs - (see above). 

PERFORMANCE OF REGISTRATION SYSTEM:
When the .NET SRS is re-activated after the cutover window, the performance 
Service Level Agreement (SLA) requirements will be significantly higher than 
required by Appendix D of the current .NET Registry Agreement, as shown below:

Monthly Metric		Current Apx D	Sentan		Improvement
----------------------------------------------------------------------
Unplanned outage	4 hrs		20 min		12x less
Extended planned outage 12 hrs/yr	8 hrs/yr	1.5x less
Check domain		3 sec avg	95%<500 msec	6x faster
Add domain		5 sec avg	95%<1 sec	5x faster

PERFORMANCE OF RESOLUTION SYSTEM:
Sentan's transition plan ensures there will be no interruption of the .NET 
resolution system.  Once transition is complete, the performance Service Level 
Agreement (SLA) requirements will be significantly higher than are required by 
Appendix D of the current .NET Registry Agreement.  In fact, the current 
Appendix D does not require the Incumbent to meet a specific response time for 
DNS resolution, whereas Sentan has committed to aggressive SLAs for DNS (See 
Part 2:5.b.xv).  

8.6 THE SPECIFICS OF COOPERATION REQUIRED FROM THE INCUMBENT.
The NeuLevel transition plan, described above in 8.1, requires only minimal 
levels of cooperation from the Incumbent, consistent with its obligations under 
the current .NET Registry Agreement.  However, as described in 8.4, NeuLevel 
can perform this transition without Incumbent cooperation while maintaining the 
security and stability of .NET.

To provide assurance of a successful transition of the .NET registry, the 
NeuLevel transition plan requires the following involvement from the Incumbent:

1. Cooperation in the transition of the SRS database, including:

· Agreement on the format of the .NET database export, to include full registry 
data related to domains, including applicable dates, nameservers, and 
audit/history tables; and the execution time to produce the same;
· Delivery of an initial production database export within one week of award in 
the agreed-upon format;

· Delivery of weekly full data exports until 21 days before cutover; and

· Delivery of daily full data exports starting 21 days before cutover.

2. Cooperation in the transition of the DNS, including:

· Delivery of an initial copy of the Incumbent's .NET DNS zone;

· Real-time, incremental .NET DNS updates via its DNS software, using a 
mutually agreeable secure mechanism; and

· Coordination with NeuLevel on the timely sunset of the Incumbent's .NET 
nameservers, operating them after cutover long enough to account for client 
caching.  

3. Cooperation in the transition of WHOIS, including:

· Coordination with NeuLevel on the timely sunset of the Incumbent's .NET WHOIS 
service, operating it for at least 18 hours after cutover; and

· More than 18 hours after cutover, update its .NET WHOIS services to indicate 
that Sentan is the authoritative source of .NET WHOIS information. 

4. Cooperation in the transition of various business operations issues, 
including:

· Delivery of a list of all .NET registrars (current and pipeline), with 
current contact information;

· Delivery of information on all services provided to .NET registrants and 
registrars;

· Delivery of all data related to all open .NET customer tickets; and

· Delivery of all data related to pending or on-going legal or other disputes 
related to .NET, including domain and transfer disputes.

5. Cooperation in the planning for and execution of a smooth cutover, including:

· Participation in a project planning meeting within one week of award to 
jointly review our entire transition plan to ensure a mutual understanding; and

· Availability of dedicated resources to quickly resolve issues, with special 
focus on the cutover period.

8.7  ANY RELEVANT EXPERIENCE OF THE APPLICANT AND THE CONTRACTED SERVICE 
PARTIES IDENTIFIED ABOVE IN PERFORMING SIMILAR TRANSITIONS
NeuLevel, Sentan's technical operator, and its parent NeuStar, have the 
relevant experience in registry operations with a history of successfully 
providing similar deliverables to the telecommunications industry. NeuLevel's 
technical staff is one of the few teams with significant experience in 
successfully transitioning an existing major TLD and in launching a new one--and 
operating both to the highest levels of service, performance, and industry 
standards.

NeuLevel has the proven capabilities to deliver technically superior, highly 
reliable, and fully scalable registry solutions. As the parent company of 
NeuLevel, NeuStar's accomplishments and experience with transitioning mission-
critical registry operations are also relevant.   Following is a list of 
significant accomplishments:

· The successful transition, launch, and administration of the .US TLD in 2002;

· The successful migration to EPP 1.0 in the .biz TLD in 2004; and

· The successful transition of .US locality space registration management to an 
automated system in 2003.

Additionally, we provide a summary of NeuLevel and NeuStar's experience in 
transitioning a wide variety of mission-critical services.  These experiences 
are very similar to the .NET registry transition in that the service itself was 
critical to the industry, demanded detailed planning and flawless execution 
working with technically complex systems under extremely aggressive deadlines.

THE .US TLD TRANSITION FROM VERISIGN
The award of the .US TLD provided our technical team with the experience of 
transitioning an existing and operating domain from VeriSign.  While the most 
visible part of this transition was the seamless transition of the 
responsibility for DNS resolution, the effort also entailed a wide variety of 
additional transition tasks, including:

· The establishment of a registrar outreach development and accreditation 
program (previously the .US registration process did not involve 
registrars);

· Registrar accreditation; and

· The development and launch of an innovative ("sunrise") intellectual 
property protection program.

During this effort, the team learned many lessons about the efficacy of various 
strategies and tactics in the transition of an existing TLD, such as ways to 
quickly certify large numbers of registrars and to smoothly migrate DNS 
responsibility from one operator to another.  Sentan will leverage this 
knowledge and incorporate it into our planning efforts.  These lessons 
contribute to our understanding of the requirements for the success of the .NET 
migration. For example, as a result of this experience, our staff has gained 
the ability and knowledge to:

· Work cooperatively with VeriSign in the successful transition of a TLD;

· Design and implement a successful transition plan that minimizes 
disruptions, manages risk factors, and on-time completion;

· Forge positive relationships with a diverse registrar community;

· Build a highly reliable, scalable, and robust registry system and 
associated tools/applications; and

· Positively respond to changes in requirements.

This transition was accomplished under extraordinarily tight timeframes.  The 
first .US nameserver was launched within a week of contract award.  And the 
expanded .US space was launched in less than six months after contract award.

United States Department of Commerce requirements for a diverse registrar 
community were successfully met by the accreditation of 58 registrars; 21 of 
who were not previous ICANN-accredited registrars.  Additionally, relationships 
and international presence helped to solicit the active participation of four 
European, three Asia-Pacific, and two Middle Eastern registrars at the time of 
transition.  The deliverables and value-added services identified in the 
following all contributed to a stable, smooth transition and launch.

DELIVERABLE:  Transition of DNS servers with no disruption to resolution.
RESULT/BENEFIT:  Provided a seamless transition that was transparent to 
Internet users.

DELIVERABLE:  Enhanced Sunrise and Launch Toolkits which included robust 
quality edits and content verifications.
RESULT/BENEFIT:  Early and comprehensive error reports provided registrars with 
ample time to correct applicant errors

DELIVERABLE:  Improved Toolkit delivery process and technical documentation.
RESULT/BENEFIT:  Efficient registrar turn-up and certification.

DELIVERABLE:  Provided United States Patent and Trademark Office (USPTO) 
reference data files.
RESULT/BENEFIT:  Minimized late error detection, thus supporting the registrar-
requested Sunrise extension without delaying First-Come, First Served (FCFS) 
launch.

DELIVERABLE:  Early release, extended use, and expanded technical support of 
interactive test environment.
RESULT/BENEFIT:  Ensured 100% concurrent access by all registrars at moment of 
FCFS launch.

DELIVERABLE:  Proactive certification and credential support.
RESULT/BENEFIT:  Avoided last minute certification requests and problems 
facilitating equal access at FCFS launch.

DELIVERABLE:  Full internal launch dry-runs.
RESULT/BENEFIT:  Helped to fine tune our launch efforts to ensure a flawless, 
on-time launch.

DELIVERABLE:  Pre-launch connectivity period with full 24/7 technical support.
RESULT/BENEFIT:  Provided registrar connectivity testing and 24/7 technical 
support to identify and resolve all credential and connection issues prior to 
launch.

DELIVERABLE:  A perfectly timed FCFS turn-up.
RESULT/BENEFIT:  Provided 100% equal access across registrars around the world.

DELIVERABLE:  A stable, highly available online system.
RESULT/BENEFIT:  Supported 5 million transactions within the first 24 hours 
without any degradation in service.

Additionally, NeuStar was able to offer an online first-come, first-served 
(FCFS) "landrush" of the expanded .US space.  Other registries have supported 
such periods with a batch process to mitigate concerns about system capacity 
and general stability.  NeuStar, however, gained enough experience testing the 
robustness of our system to comfortably offer a real-time launch without delay 
between the selection of sunrise trademark owners and an open .US offering.  
NeuStar successfully supported this landrush in which 5 million transactions 
were flawlessly executed in the first 24 hours. 
 
THE EPP 1.0 MIGRATION IN .BIZ
After the adoption of the EPP 1.0 standard by the IETF, NeuLevel finalized the 
development and testing of its SRS to support the new version of the protocol.  
The SRS had supported EPP (pre-standardization) since its launch in 2001.

In order to provide maximum flexibility for its sizable community of 
registrars, NeuLevel developed its software to provide the capability to 
operate both EPP 0.4 and EPP 1.0 in parallel, allowing each registrar to 
seamlessly migrate to EPP 1.0 on a schedule of its own choosing.  Registrars 
determine a testing schedule that meets their needs, and when ready to migrate 
its production operations to EPP 1.0, contact customer support to schedule a 
cutover time.

Not only was NeuLevel the first gTLD registry operator to launch production 
support of EPP 1.0, but its approach of simultaneously supporting both versions 
of the protocol is unique among gTLD operators who have announced support for 
EPP 1.0.  At least one other prominent operator has adopted a flash-cut 
approach to EPP 1.0 support, requiring all registrars to conform to an 
established schedule.

THE .US LOCALITY SPACE REGISTRATION MANAGEMENT SYSTEM TRANSITION
Under its previous administrator, the .US locality space was managed using a 
manual process that stored registration information (provided by delegated 
managers) directly in zone files, which were deployed directly on nameservers.  
This approach suffered from a number of shortcomings.

Upon taking over responsibility for .US, NeuStar placed a priority upon 
maintaining resolution capabilities and promptly deployed the .US zone 
information on a stable and high-performance platform.  As an interim measure, 
the team managed registrations manually, providing responsive customer service 
that, even with a manual process, dramatically improved the responsiveness to 
requests from delegated managers.

Subsequently, the team undertook the task of migrating the registration 
management process from the previous zone file-based mechanism into a database-
oriented system.  This effort integrated the management of .US locality names 
into the SRS that manages the 2nd-level names.

After extensive testing, the domains and registration information were migrated 
into the SRS.  This migration had a number of beneficial side effects for 
the .US locality space, including:

· Dynamic update for DNS changes;
· Establishment of a WHOIS for .US locality names;
· Storage of registration information in a database; and
· Establishment of an audit trail for changes to registrations.

Despite overhaul of the entire implementation of the space, there were no 
negative operational impacts to Internet users, registrants, or delegated 
managers.

A BROAD BASE OF ADDITIONAL TRANSITION EXPERIENCE
In addition to the extensive background in performing transitions in the domain 
name registry environment described above, NeuStar has a broad base of 
experience in transitioning a wide variety of telecommunications systems.  
Deadline-driven and highly coordinated migrations are the norm in this 
industry.  Its position as a central coordinator of telecommunications 
resources affords many opportunities to exercise these highly developed 
capabilities. Typical examples of such transition experience includes:

· The overnight migration/conversion over 10 million records data, with 
100% accuracy, into a new system to support the administration of the North 
American Numbering Plan in 2003;

· The migration/conversion of databases/systems supporting state-based 
number pooling administration to a new system supporting national number 
pooling administration in 2002;

· The migration of the Number Portability Administration Center systems 
to a major new software release, involving data conversion for hundreds of 
millions of records, system deployment, and coordinated testing in 2004; and

· The ongoing quarterly migration/conversion of systems for 
telecommunications service order, occurring in response to industry-driven 
interface changes.

This track record of successful transitions demonstrates a proven base of 
individual and organizational transition experience that further bolsters our 
extensive credentials in the domain name registry environment.

8.8 ANY PROPOSED CRITERIA FOR THE EVALUATION OF THE SUCCESS OF THE TRANSITION
Clear and measurable criteria for success are an important aspect of any well-
designed plan.  They define the threshold for success and provide an objective 
way to assess the outcomes.  Properly defined and measured success criteria can 
be used to create a blueprint for future transitions.

The Sentan team's experience with mission-critical transitions, combined with 
our careful analysis of the .ORG transition, has led to the creation of this 
transition plan for .NET.  The plan was designed around the overall goals of 
the transition, priorities built upon stakeholder needs, and risk evaluation 
based on probability and impact. 

We propose that criteria be organized around the key stakeholders in the 
transition of .NET, including:

· .NET registrants;
· .NET registrars;
· Internet users; and
· ICANN and the Internet community.

Additionally, we propose that the transition program be the subject of a 
comprehensive transition report to made available to ICANN.

This section describes our proposed criteria and the proposed contents of the 
transition report.

STAKEHOLDER CRITERIA FOR .NET REGISTRANTS
Size of registrar community - Our proposal includes a variety of strategies and 
tactics to provide equal access and promote competition among registrars. Given 
these efforts, we propose measuring the size of the .NET registrar community by 
regular public reports.

Price of registration - Given our proposed lowering of the .NET wholesale 
registration price, we propose measuring retail registration offerings to 
detect changes in price and/or value of product bundles.

STAKEHOLDER CRITERIA FOR .NET REGISTRARS
Registration system - Our proposal includes a fully redundant, highly scalable 
SRS infrastructure.  Given this implementation, we propose measuring:

· Transaction load;
· Availability; and
· Performance.

Satisfaction - Key portions of the transition plan are organized around making 
the transition smooth and low-cost while delivering more value to the registry 
service.  After conducting a pre-transition survey to gauge expectations, 
Sentan will conduct a registrar survey following the registry cutover, and then 
again at the completion of the RRP-EPP protocol migration and thin-to-thick 
data model migration.  In addition, after the conclusion of the thin to thick 
migration, Sentan will conduct a survey of registrants who have recently 
transferred a .NET domain to evaluate their experience with EPP-based transfers 
in a thick registry.

Program Uptake - Our proposal includes a number of new services that are being 
made available to registrars on a no-fee, opt-in basis.  Given the voluntary 
nature of these programs, we propose measuring:

· Rate of adoption;
· Level of use; and
· Renewal rate.

Transfers - Our proposal includes migrations to thick data and to EPP 1.0 to 
improve the transfer process.  Given these changes, we propose measuring:
· Rate of transfers;
· Rate of transfer rejections; and
· Rate of transfer disputes.

STAKEHOLDER CRITERIA FOR INTERNET USERS
DNS Resolution--Our proposal includes a large number of nameserver sites that 
are strategically located and provisioned with high bandwidth.  Given this 
implementation, we propose measuring:
· The speed of resolution;
· The availability of the resolution system;
· Query volume; and
· Query growth.

STAKEHOLDER CRITERIA FOR ICANN AND THE INTERNET COMMUNITY
Globalization - Our proposal includes a variety of programs designed to 
make .NET names more attractive to users around the globe and includes a 
migration to a thick registry model (providing information about the location 
of registrants).  Therefore, we propose measuring:
· Number of names by region/country;
· Growth rate of names by region/country;
· Renewal rate by region/country; and
· Average term by region/country.

Names under management - Given our proposed lower wholesale price and registrar 
outreach programs, we propose measuring:
· Number of names;
· Growth rate of names;
· Renewal rate; and
· Average term.

IDN registrations - The current .NET policies for IDNs do not comply with IETF 
standards and ICANN policies.  Given our revised, fully compliant approach to 
IDNs, we propose measuring (by language):
· Number of IDN registrations;
· Growth rate of IDN registrations;
· Renewal rate; and
· Average term.

IPv6 - The availability of IPv6 capabilities in the .NET registry has important 
strategic implications for the Internet.  Given our support of IPv6, we propose 
measuring:
· Growth rate of IPv6 hosts in the zone;
· Growth rate of domains using IPv6 hosts; and
· Growth rate in queries for IPv6 hosts.

POST-TRANSITION REPORT
The post-transition reports communicate valuable lessons, and may further 
assist the implementation of future transitions.  Providing meaningful and 
detailed information will maximize the utility of these reports.  

Sentan recommends that the post-transition report include the following 
concepts:

Description of the transition process:  Includes a full description of the 
transition process as implemented.  A clear rendition of the transition is 
critical to providing a picture of the transition planning and execution 
phases.  This section should include:
· Planned implementation steps and timeline;
· Actual implementation steps and timeline;
· Description of any problems or deviations from the plan; and
· An analysis of the transition.
	
Impact of the transition:  Includes an analysis of the transition's effect on 
registrars, registrants, registry operations, and Internet users.  This section 
should include:
· Snapshots of .NET at the time of transition and during the months 
following transition;
· An analysis of the OT&E process, including data on registrar testing;
· An analysis of problems encountered and complaints received from 
registrars, registrants and Internet users;
· An analysis of registrar performance following transition;
· Summary of any technical problems encountered around cutover, 
including any outages; and
· A report on DNS problems or discrepancies.
	
Migration from RRP to EPP 1.0:  Includes an analysis of the protocol migration 
effect on registrars.  Careful analysis will provide invaluable lessons learned 
for future transitions and provide insight into future best practices.  This 
section should include:
· An analysis of the registrars using each protocol offered (RRP and EPP 
1.0) at the time of transition;
· A description of any problems related to multiple protocols;
· An analysis of the ability of registrars to effect a smooth migration, 
including data on time to migrate; 
· An analysis of the effectiveness of the migration incentive program; 
and
· A description and analysis of the impact to domain transfers.

Migration from Thin to Thick Registry:  Includes an analysis of the protocol 
migrations effect on registrars and WHOIS.  Careful analysis will provide 
invaluable lessons learned for future transitions and provide insight into 
future best practices.  This section should include:
· An analysis of the migration progress of each registrar;
· A description of any problems operating mixed thin and thick data 
simultaneously;
· An analysis of the ability of registrars to affect a smooth migration, 
including data on time to migrate;
· An analysis of the effectiveness of the migration incentive program; 
and
· A description and analysis of the impact to WHOIS.


Provide a detailed description of your plan for supporting RRP at the time of transition, for supporting EPP 1.0, and for providing registrars with a smooth, low-cost migration path from RRP to EPP.

WHY SENTAN
· Currently available RRP test environment for .NET-demonstrating our 
readiness and commitment
· Seamless RRP support at transition-providing continuity of operations 
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
Sentan will use the infrastructure provided by NeuLevel, our technical 
operator, to support both RRP and EPP 1.0 and to provide registrars with a 
smooth, low-cost, 8-month migration path from the RRP to EPP 1.0.

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

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 in protocol migration to proceed at its 
own pace, not being required to wait for other registrars to migrate.

AVAILABILITY OF PRE-TRANSITION RRP TEST ENVIRONMENTS
Sentan recognizes that registrars have interacted with the .NET registry for 
many years using RRP. Thus, we will enable registrars to use existing RRP 
client software, unmodified, to interact with our RRP service. That is, while 
basing our code on RFC 2832 and RFC 3632, we will bring our software into 
compliance with the de facto .NET protocol, rather than holding that the RFCs 
might take precedence over the current de facto operating mode of the .NET 
registry.  (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.)

To proactively address RRP support, NeuLevel has already launched an RRP OT&E 
environment.  Various active .NET registrars are initiating testing efforts 
using their existing RRP clients.  NeuLevel is incorporating their feedback 
on .NET interface compatibility.  This OT&E launch demonstrates Sentan's 
capability and commitment to a smooth transition. 

NeuLevel will also have an RRP scripted server within 30 days of selection. A 
scripted server is the environment for certification testing. It supports a 
documented suite test case suite, checks the client's RRP input, and provides a 
defined set of responses. Successfully completing these steps is a 
certification requirement unless the registrar had been previously RRP 
certified by the incumbent; for such registrars, certification will be 
automatically granted. 

Upon gaining RRP certification (tested or grandfathered), a registrar can begin 
OT&E testing. 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
Registrar pre-transition testing will fully exercise NeuLevel's RRP service. By 
incorporating test feedback, the software will become completely compatible 
with the Incumbent's.  Consequently, when the .NET SRS is cutover 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 be adopt flexible policies in supporting 
registrars' 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 as an EPP platform and it has been operating reliably 
and at scale since 2001. Additionally, to support protocol evolution, it 
simultaneously supports multiple provisioning protocols (now including RRP) 
without adapters or proxies.  No other EPP-based SRS has consistently shown 
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 program includes the migration of .NET to a "thick" 
registry data model along with the migration from RRP to EPP. 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 in terms of 
opportunity cost.

Registrars vary widely in market focus, operational ability, size, and 
financial condition. Given this, it is not possible for an operator to design a 
one-size-fits-all migration plan that is low-cost for all registrars 
simultaneously. An inflexible plan will necessarily benefit registrars of a 
particular profile, contradict the principal of equal access, and fail to 
promote competition.

Plan features oriented toward flexibility-oriented features include support for 
RRP and variations of EPP 1.0 during migration; 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
The following summarizes the essential impacts of a thick data 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 not required for creation, but required for 
inclusion in the zone.
-EPP 1.0: References to Host object 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, the key difference between the protocols, in the context of thick 
model, is the Contact and its relationship to the Domain. 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 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 the thin data 
model;
· Stage 2: A stage for Contact data population with partial enforcement 
of the thick data model; and
· Stage 3: The final stage enforcing the thick data model.

These stages are all compliant with the EPP 1.0 RFCs and 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 to complete the migration. The key differences between 
the stages from the perspective of the EPP contact object and its relationship 
to the domain object are:

-Stage 1: Contact operations not allowed; Domains don't accept Contact 
references in thin model;
-Stage 2: Contact operations allowed; Domains optionally accept Contact 
references; and
-Stage 3: Contact operations allowed?  Domains require Contact references.
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 
simpler than Stage 2 or 3 certification. We anticipate this will be the initial 
certification level chosen by 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 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.

Due to the migration to thick data, we decided to make Contact references 
optional for Domains 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 need to flash cut to 
the thick model. We recognize that a flash cut could hurt operational stability 
for these registrars and are thus providing Stage 2.

Stage 3: EPP with the thick data 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 and 
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. 

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.2, Exhibit 8-2b. The variety of 
possible paths from RRP to EPP 1.0 Stage 3 is depicted in Part B:8.1, Exhibit 8-
2a.

We expect a variety of progressions and different schedules will be used. This 
flexibility is a key feature in our plan. Our registrar relations team will 
work closely with registrars to tailor a custom migration schedule for each 
registrar. Our goal in developing this flexible approach is to make the 
transition smooth for individual registrars. Based on our experience, the best 
way to achieve this is to allow registrars to set scope and timing.

Given the principle of equal access, newly accredited registrars during 
migration will have the option of certifying 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 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 configuration. 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 until it transitions to a 
supported protocol. No changes will be made to the registrar's sponsored (e.g. 
they will not be removed from the zone). As always, the registry customer 
support staff will be available to perform emergency DNS changes to the 
registrar's sponsored names.

INCENTIVE FOR MIGRATION TO EPP 1.0 AND THICK DATA
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. Sentan will provide a unique 
incentive to encourage registrars to complete the migration to EPP 1.0 Stage 3 
and to fully populate thin domains quickly: rebate programs called Fast Track 
Group A and Fast Track Group B. Each rebate program has 2 deadlines: one for 
certification and one for completing protocol conversion and domain data 
population.

Fast Track Group A
· Rebate is US$ 0.05 per .NET name under management on the date the 
program ends.
· Rebate will be credited to the registrar's account no later than 60 
days after program end.
· Program ends on transition date plus 3 months.
· To qualify, a registrar must:
· Complete certification for EPP 1.0 Stage 3 before transition date plus 
1 month;
· Complete protocol conversion to EPP 1.0 Stage 3 before program's end; 
and
· Populate all sponsored domains with contact data before program's end.

Fast Track Group B
· Rebate is US$ 0.03 per .NET name under management on the date the 
program ends.
· Rebate will be credited to the registrar's account no later than 60 
days after program end.
· Program ends on transition date plus 4 months
· To qualify, a registrar must:
· Complete certification for EPP 1.0 Stage 3 before transition date plus 
2 months;
· Complete protocol conversion to EPP 1.0 Stage 3 before program's end; 
and
· Populate all sponsored domains with contact data before program's end.

In constructing these rebate programs, we have collected feedback from 
registrars on previous transition experiences. We have carefully designed these 
programs to provide incentive to complete certifications and transition 
promptly.

MAINTAINING SMOOTH FLOW OF TRANSFERS
Our migration plan fully addresses transfers and will seamlessly allow 
transfers to proceed as usual throughout the protocol migration period.  Unlike 
previous RRP-EPP protocol migrations, our implementation of transfers does not 
require any changes or extensions to standard protocols.

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. The transfer models differ in two key ways: EPP uses the AuthInfo code 
to validate a transfer request, while RRP has no validation mechanism. And EPP 
includes a transfer notification and response mechanism within the protocol, 
while RRP uses email.

INITIAL USE OF RRP TRANSFER RULES
The current transfer process in the .NET registry is based on RRP rules. These 
do not enforce any SRS-based validation of the initial transfer request. To 
ensure a smooth transition, we will maintain RRP transaction semantics from 
transition day until the end of RRP support.  During this period of RRP-based 
transfers, the SRS will pass unvalidated transfers directly to the losing 
registrar.  Thus, we expect transfer rejection rates to be consistent with 
existing transfer rejection rates within .NET.  While some registrars will be 
using EPP to submit transfers, the business rules will not reject invalid 
transfer requests before they are sent to the losing registrar.

A registrar will perform transfer requests according to the standard for its 
protocol, without knowing the protocol being used by the losing registrar.  
That is, an EPP-based registrar will send transfer requests that fully comply 
with EPP formats, including the AuthInfo code.  During the RRP-based transfer 
period, the SRS will not validate the AuthInfo code before notifying the losing 
registrar. 

A registrar will also receive transfer notifications and respond to them 
according to its protocol, without knowledge of the protocol being used by the 
gaining registrar.  That is, an EPP-based registrar will retrieve notifications 
via the Poll command and respond to requests via the EPP Transfer command.  An 
RRP-based registrar will receive notifications via email and respond to 
requests by the RRP Transfer command.  The SRS will perform this adaptation 
transparently in a way that is transparent to both EPP- and RRP-based 
registrars.

TRANSITION TO ON-GOING USE OF EPP 1.0 TRANSFER RULES
Concurrent with the expiration of RRP support, all registrars will be using EPP 
1.0, the transfer process will shift to be based on EPP 1.0 rules, and SRS will 
validate the AuthInfo code supplied with a transfer request.  Transfer requests 
with valid AuthInfo codes will be accepted and generate a notification for the 
losing registrar (each of which will be using EPP to retrieve the 
notification).  Invalid requests will be rejected and returned to the 
originating registrar without generating a notification.

Currently, the .NET registry does not store an AuthInfo code for a domain.  
Since the registry is moving to EPP 1.0 transfers, each domain will have 
AuthInfo code.  To bootstrap the AuthInfo codes, NeuLevel will generate a 
strong random AuthInfo code for each domain during the initial SRS database 
load.  (Each registrar must still acquire and distribute the codes to 
registrants.)

EPP-based registrars can use the Info command to retrieve the AuthInfo code and 
the Update command to update the same.  Each RRP-based registrar will receive a 
report, delivered securely, containing the AuthInfo codes for all domains it 
sponsors.  Additionally, all registrars can use the Registrar Administration 
Tool (RAT) to securely query and update the AuthInfo code for any domain it 
sponsors.


   

Please check that you have completed all the following steps to ensure you have fulfilled the requirements of the Request for Proposals:

  1. Submitted by wire transfer the application fee
  2. Downloaded and completed all the application materials.
  3. Affirmatively evidenced your agreement to all terms and conditions included in the Request for Proposal.
  4. Printed, signed and sent to ICANN the final copy of your application.
  5. Kept a copy for your records.

When you complete this application and finalize it for sending to ICANN, you will need to confirm the following:

  1. By checking this box the applicant agrees (if selected as the successor registry operator for .NET) to the following:
  2. By checking this box, the applicant certifies that (a) he or she has full authority to make this application on behalf of the applicant and to make and fulfill all agreements, representations, waivers, and undertakings stated in this transmittal form and accompanying materials; copies of the documents demonstrating this authority are attached and (b) all information contained in this application transmittal form and accompanying documents is true, accurate and complete to the best of the person's and the applicant's knowledge and information. The undersigned acknowledges on his or her own behalf and that of the applicant that any material misstatement or misrepresentation (or omission of material information) will reflect negatively on any application.

  3. By checking this box, the applicant acknowledges that there are five parts of the Request for Proposals that have been thoroughly reviewed and considered in their entirety by the applicant. The applicant (or, if there are multiple applicants, each applicant) understands that failure to fully follow instructions or the requirements set forth for each of the documents transmitted with this Application Form will be a factor negatively affecting consideration of this application.

  4. By checking this box, the applicant (or, if there are multiple applicants, each applicant) hereby authorizes ICANN to:
  5. By checking this box the applicant (or, if there are multiple applicants, each applicant) understands that difficulties encountered by ICANN in verifying, elaborating on, supplementing, analyzing, assessing, investigating, or otherwise evaluating any aspect within or related to this application may reflect negatively on the application. In consideration of the review of the application conducted on behalf of ICANN, the applicant (or, if there are multiple applicants, each applicant) hereby releases ICANN (and each of its officers, directors, employees, consultants, attorneys evaluators, attorneys, accountants, and agents, hereinafter jointly referred to as "ICANN Affiliated Parties") from any and all claims by any applicant that arise out of, are based upon, or are in any way related to, any action, or failure to act, by ICANN or any ICANN Affiliated Party in connection with ICANN’s review of this application, investigation or verification, any characterization or description of applicant or the information in the application, or the decision by ICANN to determine the next .NET registry operator. Each applicant further indemnifies ICANN and the ICANN Affiliated Parties from any and all liability to applicant in any way related to or in connection with, any of such matters, provided, however that this shall not diminish any preexisting contractual rights a party may have to challenge such matters.

  6. By checking this box the applicant (or, if there are multiple applicants, each applicant) hereby authorizes ICANN and ICANN Affiliated Parties to publish on ICANN's web site, and to disclose or publicize in any other manner, any materials submitted to, or obtained or generated by, ICANN and the ICANN Affiliated Parties in connection with the application, including ICANN's (or their) evaluations and analyses in connection with the application or ICANN's investigation or evaluation of the application, other than the confidential material included in Part 2, which will remain confidential to ICANN and the independent evaluators. The applicant(s) further certify that it has obtained permission for the posting of any personally identifying information included in the application materials. The applicant understands and acknowledges that ICANN does not and will not agree to keep any portion of the application or materials submitted with the application confidential except for the material specifically identified in Part 2. The applicant (or, if there are multiple applicants, each applicant) grants ICANN and ICANN Affiliated Parties a license to use any copyright or other intellectual property that applicant may have in any portion of the application for this purpose.

  7. By checking this box the applicant (or, if there are multiple applicants, each applicant) hereby gives ICANN permission to use the applicant's name, descriptive materials and/or logo in ICANN's public announcements (including informational web pages) relating to top-level domain space expansion.

  8. The applicant agrees that the applicant information, certified by the undersigned (a) that he or she has authority to do so on behalf of the applicant and, on his or her own behalf and on behalf of the applicant, (b) that all information contained in this proposal is true and accurate to the best of its knowledge and information. The applicant understands that any material misstatement or misrepresentation (or omission of material information) will reflect negatively on any application of which this proposal is a part and may cause cancellation of any selection to operate a registry based on such an application.

Signature: ___________________________________________________________________________
Title: ___________________________________________________________________________
Organization: ___________________________________________________________________________
Date: ___________________________________________________________________________


Please report any problems with this application to
net-rfp@icann.org

© 2005 The Internet Corporation for Assigned Names and Numbers