ICANN | .NET Application Form

2. Applicant's Business and Other Associated Activities DENIC eG is the registry for domains under the Top Level Domain (TLD) .de, and is a central and important interface of the Internet. Established in 1994, and organized as a cooperative in 1996, DENIC has successfully managed the rapid growth of .de domains over the past decade - with .de registrations now numbering more than eight million. Under DENIC's stewardship, .de has grown to become the most requested country code TLD (ccTLD), and the world's second largest TLD after .com. To handle this, a stable, highly dependable infrastructure has been set up. DENIC is based in Frankfurt, Germany, and has 85 employees. DENIC is a not-for-profit organization, and administers its services without the intention of making a profit, and for the benefit of all parties with an interest in the Internet. DENIC takes seriously its responsibilities and obligations, as recommended in RFC1591: * It "has a duty to serve the community;" * It must "be able to carry out the necessary responsibilities, and have the ability to do an equitable, just, honest, and competent job;" * "Significantly interested parties in the domain should agree that the designated manager is the appropriate party." DENIC's entire work is neutral, impartial, independent, informed, responsible and non-discriminating and in conformity with the internationally recognized standards for running a domain registry. It will maintain its close cooperation with its registrars as it continues to strive to fulfill its duties towards the German and the Global Internet Community. Thanks to its expertise, DENIC has in recent years gained much trust and respect not only in Germany but also internationally. DENIC is in permanent contact with other national and international bodies, organizations and associations who are concerned with the Internet and maintains an active dialogue with representatives of the Internet Community. The services provided by DENIC are ergonomic, high-performance, safe and always available. DENIC attempts to achieve these prerequisites by the use of high- quality hardware and software components on the one hand and a clear infrastructure with the greatest possible redundancy on the other hand. Modern and highly capable hardware alone guarantees neither quality nor technical competence. This also applies at DENIC: the employees are the most important resource. Continuous advanced training "on the job" and external qualification ensure an up-to-date level of knowledge of the employees at all times. Highly capable hardware equipment, the use of up-to-date software and flat hierarchies provide a modern, positive working environment and thus the necessary foundation for successful work. For this very reason DENIC has also become the operator of the ENUM trial for the German call-number space (.9.4.e164.arpa).

(i) The Person or Persons Who Will Have Direct Responsibility for the Business Operations of the Registry 1. Sabine Dolderer, Full Time Member of the Executive Board Sabine Dolderer is a CEO of DENIC eG since April 2001. Ms. Dolderer has been with DENIC since its inception - beginning in 1994 when it was managed by the University of Karlsruhe computing center, and through its founding as a cooperative in 1996. She was General Manager of DENIC from 1997- 2001, and has served in the position of Director since then. Ms. Dolderer worked from 1990-1997 as a scientific assistant at the University of Karlsruhe computer center, where she was responsible for central communication services such as e-mail, news, and Internet access. In 1994, she took on the additional responsibility of the "DENIC" project, for which the University of Karlsruhe performed the technical engineering responsibilities on behalf of the top German Internet Service Providers (ISPs) until 1999. In her career, Ms. Dolderer has made significant contributions to the design and further development of the domain administration system for the TLD .de. Her expertise on domain administration is recognized not only in Germany but also abroad. She is a member of various international organizations, having served on the board of many of them during her career. Ms. Dolderer has been Acting Treasurer of CENTR (Council of European National Top Level Domain Registries) for the period 2000-2004. Ms. Dolderer received her education at the University of Karlsruhe, where she obtained her degree in Informatics/Computer Science. 2. Andreas Bäß, Full Time Member of the Executive Board Andreas Bäß has been a member of the DENIC Executive Board since the foundation of the cooperative in December 1996. Being at first an honorary member, he was appointed as full-time director by the DENIC Supervisory Board in February 2003. His work is focused on technical aspects at DENIC. From 2002 until 2003 Andreas Bäß was working as a freelance consultant in the areas of service level management, system security and risk management. Before this, he had been working as Technical Sales and Distribution Manager for Value Added Software GmbH since 2001. Prior to this, Andreas Bäß was Technical Managing Director at VIA NET. WORKS Deutschland GmbH since 1998. In this role he was responsible for the Integration of GTN into the worldwide group of VIA Networks companies, the setup of an European data backbone for the support of all VIA subsidiaries and their customers and the integration of the other German VIA subsidiaries into the German backbone. In 1994 Mr. Bäß was one of the founders of the Gesellschaft für Telekommunikations- und Netzwerkdienste (GTN) that merged with VIA NET. WORKS Deutschland GmbH in 1998. From 1994 to 1997 Andreas Bäß was managing director and in charge of the setup of a technical infrastructure to provide Internet services based on Unix Servers and Cisco Routers, the setup of a franchise distribution system and the registration of the trade name "DPN Deutsches Provider Network" all over Europe. Before this Mr. Bäß had numerous other positions as system programmer, system engineer and technical director at different companies. Mr. Bäß has an education as Professional for Business Information Systems.

(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 The Executive Board will have direct responsibility for the business operations of the registry.

(iii) The Top Two Financial Officers of the Applicant 1. Juanita Köberich, Head of Accounting As Head of Accounting, Juanita Köberich is in overall charge of financial operations at DENIC. Juanita Köberich responsibilities include but are not limited to financial accounting, cost accounting and balancing. Ms. Köberich is with DENIC since July 2003 and holds the role of Head of Accounting since then. Before Juanita Köberich joined DENIC, she gained 18 years of work-experience in the accounting departments of several other companies, including software and hardware companies. During this time she was the Head of Accounting Departments for 13 years. Ms. Köberich holds a degree in Business Administration with majors in Organization and Controlling. 2. Heinrich Hildmann, Deputy Head of Accounting As Deputy Head of Accounting, Heinrich Hildmann is responsible for the accounts payable and accounts receivable at DENIC as well as for all day-to-day financial transactions of DENIC. Heinrich Hildmann is with DENIC since April 2001 and holds the role of Deputy Head of Accounting since he joined DENIC. Before Heinrich Hildmann joined DENIC, he gained 19 years of work-experience in the accounting department of the consulting company G+E and with the components supplier Alfred Teves GmbH (now Continental Teves AG & Co. oHG). Mr. Hildmann holds a degree in Business Administration from the Johann Wolfgang Goethe University, Frankfurt.

(iv) The Person with the Principal Technical Responsibility for the Operation of the Registry Joachim Strohbach, Head of Operations As Head of Operations, Joachim Strohbach is in overall charge of technical operations at DENIC, in other words responsible for all technical aspects of performing registrations, domain administration, the name server service, the integration of new processes into operational work, support for registrars and monitoring services. Under his leadership, DENIC introduced IDNs under .de in March 2004 and expanded its name server network to full world-wide coverage. He is with DENIC since 1999 and became Head of Operations in 2001. This department is made up of 14 employees. Before joining DENIC, Mr. Strohbach worked in the IT-departments of a major German tour operator for several years. Joachim Strohbach studied Computer Science at the University of Stuttgart.

(v) Other Executives or Management Persons with Significant Influence 1. Heinz-Gerhard Montag, Head of System Development Heinz-Gerhard Montag is with DENIC since November 2002. He is head of DENIC's software development and has more than 20 years of experience in the IT industry. He is responsible for managing the software development team (ten staff members) and defining the development strategy. Prior to DENIC he has held a variety of senior management positions in software development, professional services, strategy and planning in the software industry. His previous experience includes serving as Technical Manager for Client Service and Professional Service of Legent (1987 - 1995) with about 80 reporting staff, Technical Director at Computer Associates (1995 - 1996), Director Internet Security at Emprise e-commerce Services and General Manager at Emprise Technologies (1997 - 2000, since 1998 also Managing Director). From 2000 to 2002 he was Technical Manager at PentaSafe Security Technologies GmbH. He has an education as Professional for Business Information Systems. 2. Michael Weiss, Head of System Administration Michael Weiss has lead the System Administration Group at DENIC, comprised of 13 staff members, since 2001. He is responsible for the conception, provision, maintenance, and quality management of all infrastructure used at DENIC. Graduated from the University of Karlsruhe as a physicist in 1989, he worked in his first years after the university as a software engineer. Starting 1992 he was a Managing Director of ICOS Computersysteme, which focused on IT-Consulting in the field of Networks and System Integration, and System Manager at the scientific Gmelin-Institute, a part of the Max-Planck-Society, before he joined DENIC in 1998 as system administrator. 3. Stephan Welzel, General Counsel Stephan Welzel has been DENIC's general counsel since July 1999 and was additionally appointed authorized signatory for DENIC in 2001. He is admitted to the bar in all German states. After earning his law degree from the University of Hamburg in 1992 he completed the series of clerkships necessary for the bar exam clerking i. a. for the Hamburgian District Attorney's Office and the German Federal Office of Sea-Navigation and Hydrography as well as for judges at the Court of Appeals and State Supreme Court of Hamburg. Subsequently, he worked for a law firm specializing in intellectual property law and dealt with his first domain name case in 1997. At DENIC, Stephan Welzel supervises the legal staff and is responsible for all legal matters and co-responsible (with an Executive Board member) for all policy issues on both the national and international levels. He has attended all ICANN meetings since August 1999 and been actively involved in various ccTLD community issues. Since 2002 he has been chairman of the Legal & Regulatory Group of the Council of European National Top Level Domain Registries (CENTR). He is a member of the Committee on Telecommunication and Media of the German Federal Chamber of Commerce and the Committee on the Information Industry of the Chamber of Commerce of Frankfurt. He regularly publishes articles in law journals and has recurring speaking appointments on domain name issues at several universities as well as in other national and international fora.

(vi) Directors or Persons with Equivalent Positions 1. Ines Balthes, Honorary Member of the Executive Board Ines Balthes has been an honorary member of the Executive Board of DENIC since September 1999. Ines Balthes is a manager in the Technology Projects division of SAP AG based in Germany. She is responsible for global network projects including implementation of remote access solutions for training systems, implementation of business television solutions for internal communication and the wireless LAN deployment at SAP. Ines Balthes holds a Masters degree in Mechanical Engineering. 2. Stephan Martin Deutsch, Honorary Member of the Executive Board Stephan Deutsch became an honorary member of the Executive Board of DENIC in April 2004 after serving as Vice Chairman of DENIC's supervisory board for six consecutive years, starting in July 1998. In his position he is instrumental in helping to define the cooperative's overall strategy. Mr. Deutsch is also Head of Corporate Communications for Europe, Middle East and Africa (EMEA) at global communications company MCI (NASDAQ: MCIP) holding a position as Senior Manager for International Public Relations since 2001. In this position he is responsible for all the company's media communications in more than 20 countries. Before this, Mr. Deutsch held various management positions at UUNET Technologies' European and German operations since 1997. He also was one of the founding members, in 1993, of Germany's first commercial ISP, EUnet, where he helped define the ISP's systems administration and IT concept and structure as well as customer service and support communications before accepting positions in Marketing and Event Management. From an educational perspective, he is maintaining a study of Computer Science, Business Administration and Electronics / Electrical Engineering at the University of Dortmund, Germany. He is an author of various articles in IT magazines and Internet books and a regular speaker at international conferences (e.g. Resilience 2004 conference, October, London, on Business Continuity in the Financial Sector). Moreover, Mr. Deutsch has been one of the founding members of the German ASP Konsortium dedicated to introducing the concept of web based and on-demand software and application service provision. He was serving as a Director at the consortium's Executive Board for the statuary electoral turn of two years from 2000 to 2002. The ASP Konsortium merged recently with another German Internet body, the Electronic Commerce Forum, ECO. 3. Carsten Schiefner, Honorary Member of the Executive Board Carsten Schiefner became an honorary member of DENIC's Executive Board in July 1998. Apart from his activities on the DENIC Executive Board, Mr. Schiefner was responsible for external relations at RIPE NCC in Amsterdam until July 2004. In this role Mr. Schiefner maintained existing and established new contacts with governmental and industry bodies on national as well as international levels. Furthermore, Mr. Schiefner was responsible for the coordination of and led all activities related to the ENUM Tier 0 registry for e164.arpa. Before starting his employment with RIPE NCC in 2002, Mr. Schiefner was with Primus Telecommunications GmbH and its predecessors since 1996. During this time he was responsible for the creation of an External Affairs department, the overall management of the group's IP address allocations as well as the administrative overall co-ordination of the peering activities of the Primus group in Europe. From 1988 until 1996 Mr. Schiefner held different positions at Siemens AG in Germany. Carsten Schiefner received his academic education at the "Freie Universität Berlin", where he studied Computer Science and Communication Science. In 2001 Mr. Schiefner was elected as a member of the spokespersons' council of DE-CIX, the German Internet exchange point in Frankfurt. Supervisory Board Being a cooperative under German law, DENIC has an honorary Supervisory Board made up of five distinguished persons elected by the General Assembly of the DENIC registrars. The Supervisory Board appoints and supervises the Executive Board. It is not directly involved in day-to-day business, but serves as an institution of competence and closely cooperates with the Directors on all relevant issues. All members of the Supervisory Board are well known for their expertise and experience in domain administration and therefore strongly add to the high quality of DENIC performance. 4. Sebastian von Bomhard, Chairman of the Supervisory Board Sebastian v. Bomhard, member of the Supervisory Board of DENIC eG from the very beginning, has been chairman of that board continuously since 1998. Mr. v. Bomhard also is founder and Alleinvorstand (CEO) of the SpaceNet AG in Munich, Germany. SpaceNet has been serving Internet solutions for business customers in Germany since 1993. In addition, since 2004 Mr v. Bomhard is a member of the Supervisory Board of the KoSiB eG, the cooperative society of IT security related companies in Bavaria. Before 1993 Mr. v. Bomhard worked as consultant, IT instructor and author for various IT magazines. His focus was on C, SQL, Unix, Internet Technology and The Art of Computer Programming. Mr. v. Bomhard studied Mathematics and Logics in Heidelberg, Berlin and Vienna. He gained his university diploma as Magister rer. nat. at Vienna university for his work on a stacking axiomatic calculus for pseudorelative complementary lattices. 5. Ulrike Jendis, Member of the Supervisory Board Ulrike Jendis had been a member of the Supervisory Board from the very beginning in December 1996 until April 2001 and was reelected to the Supervisory Board in April 2004. From April 2001 until April 2004 she served DENIC as an honorary member of the Executive Board. Ulrike Jendis is managing director of Cable &Wireless Telecommunication Services GmbH for Germany, Austria, Russia and the Nordic countries. Before holding this position, Ulrike has been working for Cable & Wireless since 1991 in several other positions. Prior to this Ms. Jendis worked for the government of Oberbayern in Munich from 1988 to 1991 and for UNICEF in New York from 1986 to 1988. During this time she held positions as auditor as well as assistant program officer. From 1977 to 1986 Ulrike Jendis worked as an economic expert for the regional government of Hannover as well as a lecturer at the Ludwig-Maximilian- University and the University of the Federal Armed Forces in Munich. Ulrike Jendis studied Business Administration and History of Arts at the Ludwig- Maximilian-University in Munich. 6. Elmar Knipp, Member of the Supervisory Board Elmar Knipp has been a member of the Supervisory Board of DENIC eG since July 1998. Elmar Knipp is managing director of Knipp Medien und Telekommunikation GmbH, mainly responsible for technology and strategy. Together with his twin brother, Dietmar Knipp, he founded the company in 1994. In 1997, Knipp entered the domain market and has since gained experience in all areas of this business. This includes acting as a registrar, as registry operator for sTLDs and also as software vendor for registry systems. He holds 50% of Knipp's shares. Elmar Knipp is vice president of CORE as well as one of the directors of Afilias. Elmar Knipp studied Computer Science and Business Administration at the University of Dortmund. (Elmar Knipp has resigned from any activities regarding the DENIC .net bid, because he has a conflict of interest.) 7. Eric Schätzlein, Member of the Supervisory Board Eric Schätzlein has been a member of DENIC's Supervisory Board since April 2001. Eric Schätzlein is Schlund + Partner's CTO for Domain Services. In 1995, Mr. Schätzlein co-founded Schlund + Partner and has been with the company ever since. He joined the management board of Schlund in 2001 as Chief Technical Officer and is responsible for Schlund's domain services department. Being one of Germany's Internet pioneers, Mr. Schätzlein worked with the German Top Level Domain registry DENIC and helped develop DENIC's automated domain registration. In its current version, this system has registered more than eight million .de domain names. Mr. Schätzlein has designed and implemented Schlund + Partner's domain registration and DNS system, which has to date registered some 3.8 million domain names. He has also co-designed Schlund + Partner's com/net/org registrar system and is familiar with the NSI-RRP and EPP. Mr. Schätzlein has been working with European and international ccTLD registries like Nominet UK, DENIC, SWITCH and nic.at for many years. Since December 2003, Mr. Schätzlein has been a member of the advisory council of the Austrian ccTLD registry, nic.at. He is also a member of the Board and Executive Committee member of Afilias Ltd., but has refused himself on all .net related issues at Afilias. He has attended various workshops on political, legal, and technical domain name issues, e.g. ICANN Studienkreis, Domain Pulse, ECLIP as well as RIPE meetings. Mr. Schätzlein is a private member of ISOC. Mr. Schätzlein holds a Bachelor's degree in Computer Science from the University of Karlsruhe, Germany. 8. Angela Wilson, Member of the Supervisory Board Angela Wilson has been a member of the DENIC's Supervisory Board since 1999. Ms. Wilson is managing director and founder of transnet, a Munich based local ISP that has focused on small and medium sized business customers since 1994. Before this, Angela Wilson accumulated multiple experiences in the area of public relations for political and economical institutions including the EU. Since 1989 she also is the publisher and owner of MunichFound, Bavaria's only city magazine in English. In addition to her business ventures she has been an elected member of the city council of Munich for the last ten years. Angela Wilson studied Political Science and Philosophy at the universities of Bonn and Munich.

(vii) Control of Outstanding Voting Power There is no person or entity that 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.

4. Applicant Organization Type DENIC's was set up as a registered cooperative under German law in December 1996 by an initiative taken by the industry concerned and has its headquarters in Frankfurt. This form of self-administration is entirely in harmony with the open structures of the Internet as a global medium, since it is based on the principles of the decentralized distribution of responsibilities and resources as well as self-regulation through the interest groups concerned. Setting up DENIC as a cooperative made it possible to maintain an open structure for the registry, as new registrars can join the cooperative at any time, and the entirety of registrars has a very extensive influence and the means of shaping it. DENIC's membership comprises organizations administrating domains for their customers and who feel an active commitment to providing, within the principles of self-regulation, a key service for the whole German Internet Community as well as to the global community - namely, the operation of the registry for .de. DENIC is not profit oriented, but rather sees itself as a neutral service provider for everyone having an interest in the Internet. This duty is also enshrined in DENIC's statute: § 2 Purpose and subject (1) As registry, the cooperative administers and operates Internet domains, in particular under the Top Level Domain .de, and administrates all related functions. This includes, for example, the provision and maintenance of the corresponding systems, consultancy for and training of the members, support for and informing of the holders of registered domains and attendance to the interests of the cooperative as well as those of the entire German Internet community. (2) In accordance with the internationally acknowledged standards for the operation of a country code Top Level Domain, the cooperative also fulfils its function for the benefit of all who are interested in the Internet, and does not pursue the realisation of profits. It merely uses its revenues to cover its costs and to secure its own existence.

1. ICANN Policy Compliance Highlights: * DENIC will comply with all policies set by ICANN for the TLD .net. * DENIC will participate constructively in ICANN's gTLD policy-making process. * A compliance officer will be assigned. * A process to guarantee policy compliance and integration will be implemented. DENIC as the registry for .de has ten years of experience in establishing policies for the .de-zone. These policies have been developed in an open, transparent, bottom-up and consensus driven process according to the practices described in RFC1591 closely relying on the participation of the German Internet community. These processes of policy-making resemble the policy-making processes adopted by ICANN for the gTLDs. DENIC as a ccTLD registry had no reason to participate in this part of ICANN's policy-making for gTLDs, but has always supported ICANN's work in general in a very constructive and supportive fashion by commenting and sharing its experience. A reasoned example for this are DENIC's ongoing contributions to the shaping of the ccNSO and the improvement of the ccNSO related parts of the ICANN bylaws. As the registry for .net, DENIC will of course intensify this participation and comply with all existing and all future gTLD consensus policies of ICANN. (a) Participation in ICANN policy-making process DENIC considers it a basic principle of the administration of .net that the operator of the registry participates constructively in the ICANN policy-making process. Therefore, as the .net registry DENIC will contribute in various ways to the development and enhancement of policies affecting .net in particular as well as the Internet at large. * Attending ICANN's regular meetings: DENIC is already known as a registry attending all regular meetings and will continue doing so as .net registry. * Participating in ICANN's working groups: As the .net registry DENIC will even further increase its participation in different ICANN working groups. * Active participation in policy development: As the .net registry DENIC will remain an active and constructive partner in ICANN's policy development process. DENIC also commits to comply with all policies set by ICANN for the TLD .net. (b) Compliance Officer DENIC will appoint a .net policy compliance officer based in the legal department with close contact to operations and system development. The compliance officer's role will be to ensure that DENIC conforms to the standards set forth in its contracts with ICANN and the registrars as well as the applicable ICANN policies at all times. The compliance officer will act as point of contact for ICANN and other parties for any complaints on DENIC's compliance with ICANN policies. The registry officer's tasks will include to: * Ensure that all relevant operational plans and programs are compliant with ICANN's policies * Ensure that new ICANN policies get implemented completely and without delay * Monitor potential conflicts of interest and initiate actions to actively avoid or remedy such conflicts * Train staff to comply with policies that the registry is bound by * Actively monitor the registry's impartiality and the equality of treatment of all registrars (see part 2-2-a: Methods of Providing Registry Services) * Deal with complaints on DENIC's policy compliance from ICANN or third parties (first answer on complaint will be given within one working day) (c) Compliance of Existing / New DENIC Processes with ICANN's Policies DENIC knows that the most efficient way to ensure policy compliance is to thoroughly review operational plans prior to their implementation. For policies regarding .de, DENIC already has a process in place to assure such reviews. Based on this process, DENIC will complete the following tasks prior to the June 30, 2005: 1. In a first step, all technical and operational processes planned to operate .net will be reviewed by the compliance officer. They will be reviewed with respect to their compliance with existing / planned ICANN policies and any requirements of the .net registry agreement. A rigorous process will oblige every department to report all relevant plans to the compliance officer before implementation of these plans. 2. The compliance officer will check the reported plans for possible influences on any existing or planned ICANN policy or requirements of the .net registry agreement and will create an internal report on the review of every plan and program. 3. Only if this report attests compliance with existing / planned ICANN policies and the requirements of the .net agreement, the plans will be approved for implementation. If the compliance officer identifies any violation of ICANN policies or requirements of the .net agreement, the departments involved in the creation of the plan will be instructed to either abolish the plan, or to modify the plan in a way so that no conflicts with ICANN policies or requirements of the .net agreement arise. A plan not having been approved by the compliance officer will again go through the whole approval process after once the concerned department has modified it. (d) Compliance of Existing DENIC Processes with New ICANN Policies Whenever ICANN will decide on a new policy for .net, DENIC will do everything to guarantee a quick and smooth implementation of this policy. In order to achieve this, DENIC will implement the following process for .net prior to June 30, 2005. This process is based on a process DENIC already has in place for policies regarding .de. 1. Whenever ICANN decides on a new policy for .net, the compliance officer will check all existing processes for possible violations of the new policy. 2. The compliance officer will create an internal report on the review. 3. If this report attests compliance of existing processes with the new policy, no further action will be taken. If the compliance officer identifies any violation of the new policy by existing processes, the departments involved in the concerned process will be instructed to modify it in a way so that no conflicts with the new policy arise. These changes will be treated like planned technical and operational processes and therefore go through the process described in the prior chapter (Compliance of Existing / New DENIC Processes with ICANN's Policies). (e) Implementation of ICANN's Inter-Registrar Transfer Policy As described above, DENIC will spend a great deal of attention on the implementation of all ICANN policies. As the other policies, ICANN's Inter- Registrar Transfer Policy will be implemented from the first day of operations on. Generally it has to be mentioned, that each registrar working with DENIC regarding its position as registry provider for .net, will have to define its preferred way of communication. Therefore, the registrars can choose among EPP and RRP (for more details regarding these two protocols refer to part 2-5-b-iv: Registry-Registrar Model & Protocol). In the following, the protocol chosen by each registrar will be called "preferred way of communication". Because EPP and RRP are both protocols used for the registration of domains, the registrars only need one interface for multiple services. By using these protocols, the highest possible degree of security is guaranteed to avoid fraud. By the use of these protocols, equivalent access therefore also can be guaranteed to the machines managing the inter-registrar transfer process (for a detailed description of mechanisms used to provide equivalent access see part 2- 2-a: Equivalent Access for Registrars). When DENIC receives a "transfer" command from the gaining registrar, DENIC will transmit an electronic notification to both, the gaining registrar and the loosing registrar. The gaining registrar will receive the note with the protocol he used to transmit the "transfer" command. The notification for the loosing registrar will be transmitted using the poll command when the preferred way of communication is EPP (for more details regarding the two protocols refer to part 2-5-b-iv: Registry-Registrar Model & Protocol), or using e-mail when the preferred way of communication is RRP. There are three possible ways the loosing registrar can react on this notification: * The loosing registrar sends a NACK protocol command via the registrar's preferred way of communication within five calendar days * The loosing registrar sends a "confirmation" command via the registrar's preferred way of communication within five calendar days * The loosing registrar does not react on the notification within five calendar days In case of a "confirmation" command or no reaction of the loosing registrar, DENIC will complete the requested transfer. In case of a NACK protocol command of the loosing registrar, DENIC will not complete the requested transfer. After DENIC has updated its database, it will send electronic notifications to both, the gaining registrar and the loosing registrar. The notifications will be send using the poll command when the preferred way of communication is EPP, or using e-mail when the preferred way of communication is RRP. If DENIC receives one of the notices as set below, it will undo a transfer after it has occurred. In such case, the transfer will be reversed and the domain data reset to its original state. DENIC will undo the transfer within five calendar days of receipt of the notice except in the case of a registry dispute decision, in which case DENIC will undo the transfer within 14 calendar days unless a court action is filed. The notice required will be one of the following: * Agreement of the loosing registrar and the gaining registrar sent by e-mail, letter or fax that the transfer was made by mistake or was otherwise not in accordance with the procedures set forth in this policy; * The final determination of a dispute resolution body having jurisdiction over the transfer; or * Order of a court having jurisdiction over the transfer. SRS, the technical infrastructure that is used for the provision of all other registry services, will also be used for the provision of inter-registrar transfers (for a more detailed description of the infrastructure used for the SRS refer to part 2-5-b-i: Facilities and Systems).

2. Equivalent Access for Registrars

Highlights:

* DENIC has several measures in place to provide equivalent availability of 
registration as well as equivalent availability of technical and other support 
for all registrars.

* DENIC established a code of conduct as well as a several statutory and 
contractual guarantees to put the equal treatment of registrars on a formal 
base.

* DENIC will provide additional documentation describing the differences 
between the protocols during the transition.


(a) Methods for Providing Equivalent Access

Given the importance of .net for the whole of the Internet, DENIC is determined 
to administer this TLD in a way that is impartial and equitable towards all 
registrants and registrars. This requirement tallies completely with the way in 
which DENIC has put its self-perception into action for many years as the 
operator of .de.


(i) Methods to provide equivalent access for all registrars

Equivalent Availability of Registration

All of DENIC's systems have been devised so that they offer the same conditions 
for all registrars, and it is impossible for anyone to snatch any kind of 
advantage, be it technical, financial or organizational. DENIC will deploy 
these same tried-and-tested systems and mechanisms for the administration 
of .net.
An excellent practical example for equal treatment of registrars was the 
introduction of IDNs under .de on March 1, 2004. It was decided to organize 
this as a "big bang" in accordance with the principle of "first come, first 
served", and all of DENIC's more than 200 registrars faced exactly the same 
starting conditions for accessing the electronic registry system.

Measures to guarantee this equal treatment were:

* Starting January 15, 2004, a test environment was made available to all 
registrars. So everybody had the chance to investigate and test every aspect of 
the system in advance and to synchronize their systems to the given conditions.
* Only one mail server was used to receive the incoming mails. Each of these 
mails was signed by a receipt stamp with the accuracy of a microsecond. In this 
sequence, the received orders then were processed.
* Every registrar was given the same bandwidth to access the mail server that 
received the incoming orders. Therefore every registrar had exactly the same 
opportunity to send orders to DENIC.

As a result of these measures, the number of requests processed per time was 
distributed very evenly over the registrars. Even within the peak loads in the 
first full hour of registration (from 15:00 to 16:00 CET) every DENIC registrar 
had equivalent access to the registration.
This example proved, that DENIC, even in times with very high peak loads, is 
capable of guaranteeing equivalent access for every registrar.

To guarantee equivalent access for all accredited registrars, DENIC as .net 
operator will implement different measures.

For registration services these measures will include but not be limited to:

* DENIC will offer the same interfaces to every registrar (EPP and RRP; for 
more detailed information refer to part 2.5.b.iv: Registry-Registrar Model & 
Protocol)
* Each of the two protocols offered for registration (EPP and RRP) will be 
treated equally (for more detailed information refer to part 2.5.b.iv: Registry-
Registrar Model & Protocol)
* Resource controlling mechanisms will be applied in a neutral way (e.g. 
maximum number of parallel sessions per registrar)

For whois services, DENIC will guarantee equivalent access for all accredited 
registrars, by assigning the same maximum number of possible queries per unit 
of time to the whois service to every accredited registrar.
Therefore accredited registrars have to deposit the IP addresses with DENIC, 
from where the queries will come from. Only queries coming from these IP 
addresses will be able to obtain the increased access control limits held ready 
for accredited registrars. For more detailed information on the whois service, 
refer to part 2-5-b-xii: Whois Services.

Equivalent Availability of Technical and Other Support

Technical and other support covers areas such as registrar administration, 
report generation, web portals, mailing lists and newsletters, helpdesks, 
training, test environments, toolkits, emergency support, escalation policies, 
support for new technologies and proactive interaction with the registrars in 
other relevant areas (for more detailed information on all these areas of 
support refer to part 2.5.b.xix: Support).
To give all accredited registrars equivalent availability in all these areas, 
means to guarantee the same opportunities for registrars speaking different 
languages, working in different locations and different time zones.

Language:

* The web portal will be available in Arabic, Chinese, English, French, German, 
Korean, and Spanish.
* Mailing lists and newsletters will be made available in English, French, 
German, Korean and Spanish
* Training activities will be held in English and German. Also training 
materials will be offered in these two languages.
* The helpdesk will offer services in English 24/7/365. From 5 to 19 UTC the 
helpdesk will also offer services in German. For French, Korean and Spanish a 
call back service will be available.

For more detailed information on all these areas of support and the languages 
these services are offered for, refer to part 2.5.b.xix: Support.

Location:
* Trainings will be held in the U.S. as well as in Germany. If there is 
sufficient demand for trainings in other countries, DENIC will initiate 
activities to meet these demands, too.
* Decisions on the locations for events concerning new technologies will be 
made depending on the individual event. To guarantee that the events serve the 
needs of the registrar community best, decisions will be made jointly by the 
registrars and DENIC.

For more detailed information on all these areas of support and the locations 
these services are offered for, refer to part 2.5.b.xix: Support.

Availability:

* The helpdesk will be available 24/7/365.
* The web portal will be available 24/7/365.
* The test environments will be available 24/7/365.
* The emergency support will be available 24/7/365.

For more detailed information on all these areas of support and the 
availability of these services, refer to part 2.5.b.xix: Support.


(ii)	Code of Conduct

The following Code of Conduct forms an integral part of the contract with ICANN:

.net TLD Code of Conduct 

DENIC will at all times operate as a trusted third-party provider of registry 
services. The importance of .net as a critical Internet infrastructure requires 
that the operator of the .net registry conducts itself in a fair, efficient, 
and neutral manner. Therefore, in its provision of neutral registry services 
(as defined by the ICANN in its model .net registry agreement), DENIC will 
comply with the following registry code of conduct.

1. DENIC will conduct periodic reviews of its policy and operation structures 
to ensure continuing operation of the .net TLD in the interest of the global 
Internet Community.

2. DENIC will not, and will require that its subcontractors do not, directly or 
indirectly, show any preference or provide any special consideration to any DNS 
registry operator or ICANN-accredited registrar in the .net registry versus any 
other DNS registry operator or ICANN-accredited registrar in the .net registry, 
including a registry or registrar owned by a member of DENIC.

3. All ICANN-accredited registrars in the .net registry shall have equivalent 
access to registry services provided by DENIC as set forth in Appendix H of the 
registry agreement.

4. DENIC 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 DENIC 
that also operates as a provider of registrar services shall maintain separate 
books of account with respect to its registrar operations separate from those 
of DENIC.

6. Neither DENIC, 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. DENIC 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 DENIC's business services will not be shared 
with employees of any DNS registry operator or ICANN-accredited registrars, 
except (a) as necessary for registry management and operations or (b) if such 
information is made available to all DNS registry operator employees and ICANN-
accredited registrars on the same terms and conditions or except (c) for DENIC 
board members within the framework of their auditing duties.

9. No full time member of DENIC's Executive Board will simultaneously serve on 
the Executive Board of an ICANN-accredited registrar that obtains registry 
services from DENIC.

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

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

12. DENIC will ensure that with regard to .net no user data from or proprietary 
information of any registry operated or controlled by DENIC is disclosed to any 
other registry operated or controlled by DENIC.

13. DENIC will conduct internal neutrality reviews on a regular basis. In 
addition, DENIC and ICANN may mutually agree on an independent party that ICANN 
may hire, at ICANN's expense, to conduct a neutrality review of DENIC for 
ensuring that DENIC and its owners comply with all the provisions of this 
registry operator Code of Conduct. The neutrality review may be conducted as 
often as once per year. DENIC will provide the auditor with reasonable access 
to information and records appropriate to complete the review. The results of 
the review of the auditor will be provided to ICANN and shall be deemed to be 
confidential and proprietary information of DENIC.


(iii)	Other Commitments to Ensure Equivalent Access for all Registrars

Statutory Guarantee

As a registered cooperative ("eingetragene Genossenschaft", eG), DENIC is 
virtually a synonym for equivalent access for all registrars to the registry's 
resources without any form of discrimination whatsoever. The cooperative model, 
in which the registrars as a whole are members and thus jointly form the 
registry, satisfies one of the most fundamental democratic principles and 
constitutes an essential commitment to equality of treatment.

Thanks to direct control vested in the cooperative's various statutory bodies, 
the registrars directly influence the shape of its services and policies. This 
model has had an extremely successful track record in recent years for the 
administration of the .de TLD in a highly competitive environment and, indeed, 
it has been one of the key contributors to the enormous success of the .de TLD. 
The twofold duty of impartiality and equal treatment is firmly anchored in the 
Cooperative's statutes.

To quote, by way of example, some of its most important provisions:

* "§ 9 Rights and obligations of members
(1) Each member shall have the right to be involved in the organization of the 
cooperative and to make use of the services of the cooperative subject to the 
provisions of the Genossenschaftsgesetz (Cooperative Act) and this statute."

* "§ 13 The Executive Board
(4) It (the Executive Board) shall in particular have the obligation to ensure 
proper and reliable performance of the service of the cooperative for the 
members, including support of them."

DENIC will feel no less bound by this principle in administering the .net TLD 
and will make strictly the same technical, personnel and administrative 
services available to all registrars.

There should be no conflicts of interest, since DENIC itself will not be acting 
as a registrar for .net and any current DENIC registrars who are not ICANN-
accredited registrars will not be able to make any .et registrations.

Contractual Guarantee

DENIC will conclude agreements with all ICANN-accredited registrars, and these 
agreements will lay down the precise terms and conditions for access to the 
registry services. Additionally these agreements will include the corresponding 
service levels. All the information about individual registrars which DENIC 
happens to acquire in the course of its activity as the .net administrator will 
be treated with absolute confidentiality. This confidentiality provision will 
form an integral element of both the agreements concluded with the registrars 
and the employment terms and conditions between DENIC and its employees.

DENIC will nominate either one of its employees or an external consultant to 
actively monitor the registry's impartiality and its equality of treatment for 
all registrars. If an accredited registrar or any third party have any 
complaints in this regard, there will be a compliance officer (for more 
detailed information on the compliance officer, refer to part 2-1: Compliance 
with ICANN Policies) defined who they can address this issue to. This 
guarantees the quickest possible handling of any complaints.

The Technical Advisory Council, whose members are determined by the registrars, 
is yet another instrument for ensuring that the registrars' interests are 
effectively put into practice and that the principle of equal treatment is 
fully adhered to.

(b) Registry-Registrar Protocol Highlights: * DENIC will be able to provide test systems for both the EPP interface as well as the RRP to EPP proxy well in advance of the transition date. * A three-step procedure will be followed to accomplish the migration from a thin to a thick registry. (i) Protocols The incumbent .net registry is planning to migrate its .net registrars from RRP to the EPP 1.0 standard as described in RFCs3730 to 3734, and later updated by RFC3915. All necessary extensions will be handled regarding RFC3735. In order to fully complete this task, all proprie-tary modifications of RFC3632 which have not been made public by VeriSign (current RRP Version 2.1.2), must be fully disclosed. Protocols for Going Live on July 1, 2005 DENIC is committed to adhere to the standards set forth by the IETF and will build its operation of the .net registry based on the EPP protocol. Registrars will be able to use the EPP protocol starting from the first day of operations by DENIC. However, DENIC understand the need to provide for a smooth transition for all currently accredited registrars, including those planning to migrate from RRP to EPP on a later date. Therefore, DENIC will provide a RRP to EPP proxy which will be available from the first day of operations and will remain available for six months. Please refer to part 2-8: Transition Plan for full details. Test Systems DENIC is already investing in building the RRP to EPP proxy prior to ICANN's decision on the successor registry for .net. By making this investment DENIC will ensure that as soon as the .net bid has been awarded, DENIC will be able to provide test systems for both the EPP interface as well as the RRP to EPP proxy in order to enable registrars to plan and test the transition to the new registry provider well in advance of the transition date. Please refer to the Transition Plan (part 2-8: Transition Plan) for details concerning the Transition Testbed which will be created for registrars. DENIC anticipate a smooth transition with minimal effort on the part of the registrars. The test systems will also be maintained during operations, so registrars can always test new software implementations at an early stage. Support for Registrars In order to make the transition from RRP to EPP as straightforward as possible, DENIC's technical team will provide additional documentation describing the differences between the protocols during the transition. DENIC will also interact with the registrar community, in order to discover whether any additional software or documentation would make the transition more straightforward. Additionally, DENIC will provide for sufficient helpdesk capacities during the time of testing and transition, in order to be able to handle peak demands from registrars at all times. Please refer to the Transition Plan for details of when Support facilities will be available during the transition. (ii) Transition from RRP to EPP and "Thin" to "Thick" A three-step procedure will be followed to accomplish the migration from a thin to a thick registry. * At the moment of the turn over, contact provisioning will be possible via EPP and domains can optionally reference contacts. This step is planned to last six months. * In a second phase, contact references are mandatory for every create, update or renew domain commands. This step is planned to last six additional months. * In a third phase, that is, one year after DENIC's taking over .net registry services, do-mains without contact references will be considered invalid. Sponsoring registrars will be contacted and required to update these domains in a timely manner. During the thin-to-thick migration process, domain names without contact references will be displayed in whois with an additional line including the naming of the authoritative whois service as defined by the sponsoring registrar. The entire .net registry will be migrated to a full thick model by the end of the first year. Until then, DENIC's whois will continue to return thin data for unmigrated domains. Thin and thick data will coexist for this period of time. After one year, DENIC will have all thick model data from the registrars, and whois users will be able to gather all thick model information from DENIC whois without the need to reference registrar whois. It will be impossible to provision thick information via the RRP interface, thus the RRP to EPP migration is closely coupled with the thin to thick migration. DENIC will run an RRP-to-EPP proxy for all registrars for their time using the thin model, but no later than by the end of the third phase mentioned above, this proxy will not be operative anymore. For further information regarding the transition refer to part 2-8: Transition Plan.

[[Note to evaluators regarding all appendices: Enclosed are DENIC's suggestions for appendices C 4, C 5, D, E, O, P, O and R. DENIC is also open to discuss modifications of the other appendices of the existing .net agreement (e.g. C 2, C 3) in negotiations with ICANN.]] [[Note to evaluators: Please note that this list differs from the list of documents currently updating 1034 and 1035 since some of those do no longer have practical relevance (DNSSEC 2065, 2535) or do not apply to either name servers in general (1101) or to the particular registry system architecture (NOTIFY, IXFR, DynUpd). DENIC is aware of the fact that certain aspects of the current set of DNS specifications are subject to discussion and review within the responsible IETF working group(s). DENIC is prepared to actively contribute to the protocol development process. Should DENIC facilitate, endorse or support DNS software development or produce such software on its own, DENIC will ensure to the extent possible that such software be compliant to then state of the art IETF standards and be subject to interoperability tests.]] .NET REGISTRY AGREEMENT: APPENDIX C 4 NAME SERVER FUNCTIONAL SPECIFICATIONS Name servers operated by DENIC for the NET TLD shall conform to STD 13 (currently RFC1034, 1035) as amended and/or clarified by RFC2181, RFC2308, RFC2671, RFC3596, and RFC3597 where applicable. In addition, DNSSEC support will be based on the specification that passed the IESG on September 27, 2004. RFC numbers have not yet been assigned and the Internet Draft names are not to be cited.

.NET REGISTRY AGREEMENT: APPENDIX C 5 PATCH, UPDATE, AND UPGRADE POLICY Any release provided by DENIC will have a dotted schema: that of a major number, a minor number and a patch level (X.Y.Z) * The first integer (X) is the major version number. Change in the major number indicates a significant change in the software features * The second integer (Y) is the minor version number. Change in the minor number while the major number stays the same indicates a change that introduces noteworthy new features. * The third integer (Z) is the patchlevel, which can consist either of a single patch or several patches. A change of the patchlevel - while the minor and major numbers remain unchanged - indicates a change that does not introduce anything new but fixes bugs. Patches do not require changes to the client applications developed by the registrars. DENIC, in its sole discretion, will deploy patches during scheduled and announced Shared Registration System maintenance periods. For Updates and Upgrades, DENIC 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 DENIC 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. DENIC 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.

.NET REGISTRY AGREEMENT: APPENDIX D PERFORMANCE SPECIFICATIONS DENIC complies to the following SLA metrics: Total Registry Outage per Month: 6 hours Unplanned Registry Outage per Month: 3 hours Unplanned Registry Outage per Year: 9 hours Planned Registry Outage per Week: 2 hours Unplanned Registry Outage (per event): < 90 minutes Major Upgrade Outage: 6 hours (twice per year) Check Domain Average: < 100 ms (excluding round trip time) Add Domain Average: < 300 ms (excluding round trip time) Average Update Latency of Dedicated Public whois: Less than 1 second Notes: * Two "Major Upgrades" per year are allowed, each of which may last 6 hours. * Registry Operator and ICANN will discuss in good faith addition of appropriate metrics for name server packet loss and round trip times. * Planned Registry Outages: 2 hours per week and no more than 6 hours per month * Unplanned Registry Outage per year implies a 99.9% availability of the registry service * Update latency is valid for more than 98% of the updates; max. latency of 1 minute for 99.999% of the updates In addition, Registry Operator offers the additional Performance & Support Specifications illustrated in Figure 1 as SLAs.

.NET REGISTRY AGREEMENT: APPENDIX E SERVICE LEVEL AGREEMENT (SLA) Registry Operator strives to provide a world-class level of service to its customers. This Service Level Agreement provides metrics and remedies to measure the performance of the .net registry and to provide accredited and licensed registrars with credits for certain substandard performance by the .net registry under the parties' registrar License and Agreement. (A) Definitions 1) Calendar Day - a calendar day is the timeframe from midnight to the following midnight, beginning and ending at 00:00:00 Universal Time Coordinated (UTC). Each day counts as a calendar day, including weekends and public holidays. 2) Calendar Week - a calendar week is the timeframe of seven days from the first calendar day of a week to the last calendar day of that same week. The first calendar day of a week is Monday, the last calendar day of a week is Sunday. 3) Calendar Month - a calendar month is the timeframe from the first calendar day of a month to the last calendar day of that same month. 4) Planned Outage - a planned outage shall mean a pre-announced occurrence when a part or all of the Registry Service (RS) will be taken out of service for maintenance or care. 5) Major Upgrade Outage - a major upgrade outage shall mean an additional planned outage of extended duration for major systems or software upgrades. 6) Unavailability of Registry Service (RS) - unavailability of the registry service shall mean that the registry service is not operational. The registry service is not operational if either: a) a registrar cannot successfully establish a session with the RS gateway; establishing a session with the RS gateway shall be defined as: 1) Successfully complete a TCP session start 2) Successfully complete the SSL authentication handshake 3) Successfully complete the registry registrar protocol ("RRP") command and respectively EPP. b) the registry does not complete check and add domain commands according to (B) 4). Notwithstanding the foregoing a planned outage, a major upgrade outage, or an outage due to a force majeure does not count as RS unavailability. Neither does it count as RS unavailability, if the inability to complete said actions is caused by problems outside the responsibility of .net registry. 7) Availability of Registry Service - availability of registry service shall mean that .net registry is not in a state of unavailability as defined in (A) 6). 8) Registry Service (RS) availability per month - RS availability per month shall mean the percentage of time of RS availability during a calendar month based on the total time within that calendar month. 9) Unplanned Outage Time - unplanned outage time shall mean the following: a) the amount of time recorded between a trouble ticket first being opened by the .net registry in response to a registrar's claim of registry service unavailability for that registrar through the time that the registrar and .net registry agree the RS unavailability has been resolved with a final fix or a temporary workaround, and the trouble ticket has been closed. This will be considered RS unavailability only for those individual registrars impacted by the outage. To determine the total RS unavailability time, the unavailability times for the different registrars will only be accumulated, if the unavailability times do not overlap. b) the amount of time recorded between a trouble ticket first being opened by the .net registry in the event of RS unavailability that affects all registrars through the time when the registry resolves the problem with a final fix or a temporary workaround, and the trouble ticked has been closed. c) the amount of time that a planned outage exceeds the time limits established in (B) 2). d) the amount of time that a planned outage occurs outside the window of time established in (B) 1). 10) Monthly Unplanned Outage Time - monthly unplanned outage time shall be the sum of minutes of all unplanned outage time during a calendar month. Each minute of unplanned outage time subtracts from the available monthly planned outage time as established in (B) 2) and up to the limit given therein. 11) Registry Service (RS) Gateway - the RS gateway is the device within Registry Operator's network which terminates the TCP sessions used for RRP commands. 12) whois Service - whois service shall mean the .net registry whois service running on TCP port 43 of whois.denic.net. 13) Service Reply Time - the service reply time is the time between the last byte of a service request being received from the registrar at the machine processing the requested service, and the last byte of the reply to that request being sent out from that machine back to the registrar. Consequently, service reply time does specifically not include time incurred through network round trip times and delays outside the responsibility of .net registry. (B) SERVICE LEVELS 1) Planned outages will usually be scheduled weekly during the following period of time: Wednesday between 06:00:00 and 13:00:00 UTC (the "planned outage period"). This planned outage period may be changed from time to time by the .net registry, in its sole discretion, upon prior notice to each registrar. 2) Planned outages will not exceed 2 hours per calendar week nor more than a total of 6 hours per calendar month. 3) Notwithstanding the limits established in (B) 2), each year Registry Operator may incur 2 additional planned outages of up to 6 hours each during the planned outage period for major upgrade outages. 4) A RRP check domain command must be executed within a service reply time of less than 100 milliseconds in 95% of all cases and/or a RRP add domain command must be executed within a service reply time of less than 300 milliseconds in 95% of all cases, per calendar month. 5) The .net registry will provide a 99.9% RS availability during each calendar month. (C) RESPONSIBILITIES OF THE PARTIES 1) Registrar must report each occurrence of alleged RS unavailability to the .net registry customer service helpdesk by opening a trouble ticket in the manner required by the .net registry (i.e. by e-mail, fax, telephone) in order for an occurrence to be treated as RS unavailability for purposes of the SLA. 2) In the event that all registrars are affected by RS unavailability, the .net registry is responsible for opening a trouble ticket and immediately notifying all registrars of the trouble ticket number. 3) Both registrar and the .net registry agree to use reasonable commercial good faith efforts to determine the cause of any alleged RS unavailability. If it is mutually determined to be a .net registry problem, the issue will become part of the unplanned outage time. 4) .net registry will perform monitoring from at least two external locations as a means to verify that all RRP commands can be successfully completed. 5) Registrar must inform the .net registry any time its estimated volume of transactions (excluding check domain commands) per calendar month will exceed registrar's previous calendar month's volume by more than 25%. In the event that registrar fails to inform .net registry of a forecasted increase of volume of transactions of 25% or more and the registrar's volume increases 25% or more (over the previous month); and should the total volume of transactions added up (by the .net registry) for all registrars for that calendar month exceed the .net registry's actual volume of the previous calendar month's transactions by more than 20%; and should the ratio of successful to unsuccessful registry attempts (based on registry attempts per registrar and month) exceed 99%, then registrar will not be eligible for any SLA credits (as defined in section D) in that calendar month. Registry Operator will charge an additional service fee for increased system load, if the 99% ratio mentioned before will be exceeded. The registrar provides such forecast at least 30 days prior to the first day of the next month. In addition, the .net registry agrees to provide monthly transaction summary reports. 6) The .net registry will notify the registrars of planned outages outside the planned outage period at least 10 calendar days in advance of such planned outage unless the outages occurred due to security and/ or stability issues. In addition, the .net registry will use reasonable commercial good faith efforts to maintain an accurate 30-calendar-day advance schedule of possible upcoming planned outages. 7) The .net registry will update the whois service nearly real-time. The .net registry will notify registrars in advance when changes to the whois service update schedule occur. 8) The .net registry will allow external monitoring of the RS via an acceptable means to both parties. 9) The .net registry will initiate the registry zone file transfer process eight times a day. These initiations will be equally distributed over the day. The .net registry will notify the registrars in advance when changes to the schedule occur. The .net registry will notify the registrars regarding any scheduled maintenance and unavailability of the .net name servers. 10) The .net registry will use commercially reasonable efforts to restore the critical systems of the RS within 12 hours in the event of a force majeure and restore full system functionality within 24 hours. 11) The .net registry will publish weekly system performance and availability reports. These reports will include system reply time for the RRP check domains command and RRP add domain commands for all registrars as well as a summary of RS availability for the previous week. This will also apply for EPP. (D) CREDITS: 1) If RS availability is less than the limit established in (B) 5), the .net registry will provide a credit to the affected registrar(s) who have complied with sections (C) 1) and (C) 5) above as follows: (i) In the case of RS unavailability as described in (A) 6) b), a credit will be given for the sum of the percentage points of total RRP add and check commands that fall below the 95% performance threshold established in (A) 6) b), if the 99% ratio of successful to unsuccessful requests is not exceeded. For each affected registrar, this credit will be calculated by multiplying the percentage points below 95% by the registrar's monthly add domain volume times the average initial registration price charged to that registrar during the month. The maximum credit to each registrar shall not exceed 5% of the registrar's total monthly add domain volume times that average registration price. (ii) In the case of RS unavailability as described in (A) 6) a), and following the calendar month when the unplanned outage began, the .net registry will provide a credit to the registrar by multiplying the registrar's monthly add domain volume times the average initial registration price charged to that registrar during the month and multiplying that product by the percentage of time that the monthly unplanned outage time exceeded 0.6% of the minutes in the calendar month. The maximum credit to each registrar under this subparagraph shall not exceed 10% of the registrar's total monthly add domain volume times that average registration price. Under no circumstances shall credits be applied when a registrar experiences RS unavailability caused by problems outside the responsibility of the .net registry. (E) MISCELLANEOUS: 1) As an addendum to the Registry-Registrar Agreement (RRA), no provision in this addendum is intended to replace any term or condition in the RRA. 2) Dispute Resolution - Any disputes arising under or in connection with this Agreement, including requests for specific performance, shall be resolved through binding arbitration conducted as provided in this Section pursuant to the rules of the International Court of Arbitration of the International Chamber of Commerce ("ICC"). The arbitration shall be conducted in the English language and shall occur in Paris/ France. There shall be three arbitrators: each party shall choose one arbitrator and, if the two arbitrators are not able to agree on a third arbitrator, the third shall be chosen by the ICC. The parties shall bear the costs of the arbitration in equal shares, subject to the right of the arbitrators to reallocate the costs in their award as provided in the ICC rules. The parties shall bear their own attorneys' fees in connection with the arbitration, and the arbitrators may not reallocate the attorneys' fees in conjunction with their award. The arbitrators shall render their decision within ninety days of the initiation of arbitration. For any litigation brought to enforce an arbitration award the sole place of venue shall be Paris/ France; however, the parties shall also have the right to enforce a judgment of such a court in any court of competent jurisdiction. For the purpose of aiding the arbitration and/or preserving the rights of a party during the pendency of an arbitration, each party shall have the right to seek temporary or preliminary injunctive relief from the arbitration panel or a court in which case Paris/ France is the sole place of venue. The initiation of such court proceedings shall not be a waiver of this arbitration agreement. 3) Any interruption of RS that occurs, as a direct result of the current .net Registry-Registrar Agreement (RRA) Sections 2.12, 5.4, or 6.3 or any other applicable contract term of the current .net, will not be considered RS Unavailability per this SLA.

.NET REGISTRY AGREEMENT: APPENDIX O WHOIS SPECIFICATION - PUBLIC WHOIS Overview The whois service is compliant with RFC3912. The primary whois services substantially consist of three components: * Port 43 public whois services (thin and thick during migration, thick only afterwards) * Public web-whois service * Port 43 registrar whois services The two public whois services are described in more detail below. Registry Operator's whois service is the authoritative whois service for all second-level Internet domain names registered in the .net top-level domain. This service is available to anyone. Registry Operator will initially operate the .net registry whois in a manner consistent with a "thin" registry. The whois output for thick data sets is described below. For domains with only a thin set of data, the contact references in the domain object will not be shown. In order to access contact data, clients will have to follow the referral included in the domain output to reach the authoritative whois server supplied by the sponsoring registrar. The entire .net registry will have been migrated to a full thick model at the end of the first year of operation. Thin and thick data will coexist until then. Upon conclusion of the transition process, the .net whois service will provide a central, openly accessible system for information regarding a particular second level domain name registration in the .net TLD. The whois service will contain data transferred by registrars during the registration process for every registered .net domain. If a registrant changes any registration information relating to the registrant's domain name, the registrar will communicate these changes to the registry at the time they are received. This will provide interested parties with access to up-to-date information for every .net domain, under a widely deployed protocol with a consistent format. 1. Port 43 Whois Service (Thin Registry) The format of responses for thin registry output will be similar to the guidelines listed below for thick-registry whois. In the case the contact reference is missing from the domain output, the referral information will indicate the name of the whois server of the sponsoring registrar responsible for providing the contact whois information. 2. Port 43 Whois Service (Thick Registry) (a) Thick Registry Model and Data Output Fields Registry Operator will deploy a thick registry model. There are certain mandatory information fields which will be displayed in public whois in order to be able to unambiguously identify the registrant, e.g. for legal reasons. Beyond these mandatory fields Registry Operator will enable registrants the option to limit the amount of information given in the public whois in order to protect their privacy. 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. The object descriptions found below state per field: * First column: name of field * Second column: fields marked "mandatory" will be present in the output, "optional" fields may or may not be present (NB: data may still exist, but publication may have been suppressed); an asterisk indicates a field is "optional" during transition and "mandatory" afterwards * Third column: "single" indicates field may appear only once per object (exactly once in conjunction with "mandatory", at most once in conjunction with "optional"), "multiple" otherwise * Fourth column marks primary and/or lookup key DOMAIN OBJECT Domain: [mandatory] [single] [primary/lookup key] Domain-ace: [mandatory] [single] [lookup key] Status: [mandatory] [multiple] [ ] Registrar: [mandatory] [single] [ ] Referral: [mandatory] [single] [ ] Registrant: [optional*] [single] [ ] Admin-c: [optional*] [single] [ ] Billing-c: [optional*] [multiple] [ ] Tech-c: [optional*] [multiple] [ ] Nserver: [optional*] [multiple] [ ] Created: [mandatory] [single] [ ] Changed: [optional] [single] [ ] Expiration: [mandatory] [single] [ ] CONTACT OBJECT Handle: [mandatory] [single] [primary/lookup key] Name: [mandatory] [single] [ ] Organisation: [optional] [single] [ ] Address: [mandatory] [multiple] [ ] City: [optional] [single] [ ] State: [optional] [single] [ ] Zipcode: [optional] [single] [ ] Country: [optional] [single] [ ] Phone: [optional] [multiple] [ ] Fax: [optional] [multiple] [ ] E-mail: [optional] [multiple] [ ] Sip: [optional] [multiple] [ ] Created: [mandatory] [single] [ ] Changed: [optional] [single] [ ] NAME SERVER OBJECT Hostname: [mandatory] [single] [primary/lookup key] Ip-address: [optional] [multiple] [lookup key] Registrar: [mandatory] [single] [ ] Created: [mandatory] [single] [ ] Changed: [optional] [single] [ ] REGISTRAR OBJECT Registrar: [mandatory] [single] [primary/lookup key] Url: [mandatory] [single] [ ] Whois: [mandatory] [single] [ ] Admin-c: [mandatory] [multiple] [ ] Billing-c: [mandatory] [multiple] [ ] Tech-c: [mandatory] [multiple] [ ] [[Note to reviewers. Stated below are the reasons for the suggested limitation of the output fields. The mandatory information fields will ensure that the registrant can be identified and contacted. Yet by providing only information on how to contact the registrant via postal mail will establish sufficiently high hurdles to protect the registrant from unsolicited phone calls or e-mails. Abuse of information by the public or by registrar is effectively prevented. Every registrant can, at the time of registration as well as any time afterwards, agree for additional information to be accessible via whois. Examples for these additional fields are registrant phone, registrant e-mail, admin contact phone, admin contact e-mail, etc. The individual privacy flags used by DENIC are a key benefit for the whole .net community. From the experience with .de, where 80% of the registrants do not disclose this data DENIC expects the vast majority of .net registrants to make use of this feature and limit their domain information to the basic information fields.]] All objects and key types shall be specified in a publicly available description on the Registry Operator's website. The key names and objects should change as infrequently as possible, and only upon the agreement of ICANN and the Registry Operator. (b) Input Syntax IDNs can be queried natively via the whois service by using a command line flag (passed through to the whois server) that defines the character set with UTF-8 as default. UTF-16, ISO-8859-1, and US-ASCII are also supported. The web whois identifies the appropriate character set itself and will return the appropriate data. The public whois can be customized by using the flags shown below. Example: Query "HELP" whois -h whois.denic.de HELP % SYNTAX: whois [-h hostname] [-Frk] [-T types] [-C charset] key % % where: % % -h hostname search alternate server % -F fast raw output % -r turn off recursive lookups % -k establish persistent connection % -T new normalized output for domain descr in combination with -T[dn] % -T ace ACE input for domain lookup in combination with -T[dn,st] % % -T type[[,type] ... ] only look for objects of type type % % Available types: status (st), domain (dn) (co) % % -C charset specify character set for the input/output % % Available charsets: US-ASCII, ISO-8859-1, UTF-8, UTF-16 % % NOTE: There are two especial queries % % whois -h whois.denic.de HELP displays text above % whois -h whois.denic.de alive@whois returns alive if whois-server runs properly [[Note to reviewers: Above figure shows current flags for .de public whois. This figure is not to be included in the final Appendix O of the .net agreement and is presented here for demonstration of DENIC's technical abilities solely. DENIC proposes to offer similar flags for .net. The final Appendix O of the .net agreement will contain the relevant flags. Additionally the current flags are and will always be published on DENIC's website.]] 3. Web Whois Service The Registry Operator will make available a whois interface on its website which can also be linked to by each ICANN-Accredited Registrar that is a party to a Registry-Registrar Agreement with the Registry Operator. The information available in the whois database will be returned as a results page on the website. Registry Operator has designed its web based whois as a two step process. (a) Step 1 of Web Whois The first step of Registry Operator's web whois gives information about availability of the requested domain only, serving the highest user demand. (b) Step 2 of Web Whois In the second step the user will receive domain information as described above. When thick registry whois information is unavailable during the transition phase, the registry shall provide thin registry whois information, as specified in the whois output fields section above. The purpose of this web interface is to provide a user-friendly interface for whois queries. It does neither provide any additional search capabilities nor reveal information beyond what is described for the port 43 whois in this appendix. 4. Minimum Data Update Frequency The update frequency of whois data is specified in Appendix D. 5. Protocols through which Access is Provided Access to the whois data is provided through the whois protocol, TCP port 43, by whois.DENIC.NET supporting exact match queries for * domain name * registrar name * name server hostname * name server IP address (both IPv4 and IPv6) All queries will be handled case insensitively with IDN rules applied where appropriate. IPv4 addresses must be supplied as "dotted quad", IPv6 addresses must be supplied in the format specified by RFC3513. The whois data will also be accessible through the registry interface as described above. It is available via and through the website http://www.DENIC.NET. 6. Security General security measures such as password policy, firewalls and network traffic monitoring systems will be provided for the whois servers and services. The Registry whois system has been designed for robustness, availability, and performance. Registry Operator audits access to its whois service and reserves the right to respond to signs of abusive usage, like excessive numbers of queries from a single source to prevent resource exhaustion or breaches of privacy. The security considerations of RFC3912 apply. 7. Extensible-Field Capability Registry Operator provides additional fields for all stored data, e.g. a privacy flag with which the registrant can define the extent of non-mandatory information to be published via information services (e.g. whois). Furthermore Registry Operator reserves the right to introduce new fields to support new services and/or respond to demands from the registrar or registrant community or the Internet community at large. 8. Technological Progress, Standards and Development 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. Further, Registry Operator reserves the right to develop these services internally or outsource management of the facilities to an external contractor under terms that are consistent with the standards of the proposed service.

[[Note to evaluators: DENIC can provide bulk access to whois data to an independent whois provider, if one of two conditions is met: * DENIC has the explicit consent of the domain holder to allow bulk access. Only the domains with the individual and explicit prior consent resulting from an educated decision of the domain holder will be included in the bulk access. * The transfer, handling and use of the whois data provided via bulk access to the third party has to comply with clearly specified rules and must be compliant to European and German privacy law. Uses other than the specifically agreed uses are to be prohibited.]] .NET REGISTRY AGREEMENT: APPENDIX P WHOIS SPECIFICATION -- INDEPENDENT WHOIS PROVIDER DENIC does not specify a bulk access data exchange format because the result of our research suggests that any such transfer to an entity not directly related with the registry operations would be in conflict with national German or with EU legislation on data protection and privacy. Supporting material can be found (in German language) in section 9.2 and 9.3 of the 13. Data Protection Report of The State Government of Hessen (2000) and in section 8.7 of the 15. Report (2002).

[[Note to evaluators: Registry Operator suggests to provide ICANN with access to escrowed data instead of Bulk Access to whois data. If ICANN prefers to receive Bulk Access to whois data, Registry Operator will accommodate this requirement and will provide procedures, content and format of this Bulk Access to whois during the negotiations with ICANN.]] .NET REGISTRY AGREEMENT: APPENDIX Q WHOIS SPECIFICATION -- ICANN Registry Operator grants ICANN access to its escrowed data. The .net registry data will be transferred and stored at the escrow provider site according to the ICANN agreement. An overview of the schedule, content and format of the reports is displayed in the following: Schedule * Full Deposit on Sunday * Incremental Deposit Monday through Saturday Content Weekly Report * Domain Object Report * Host Object Report * Contact Object Report * Registrar Object Report * Pending Transfer Report Content Daily Report * Transaction Report Format: * All Reports are generated in XML Format Please refer to Appendix R for detailed description of the data escrow specifications regarding: * Company Name of Escrow Provider * Statement of Work * Schedule of Escrow Deposits * Specification of Deposit Format * Detailed Content Description of Full & Incremental Deposit Reports * Escrow Transfer Process * Escrow Verification Process

.NET REGISTRY AGREEMENT: APPENDIX R DATA ESCROW SPECIFICATION 1. Company Name, Statement of Work, Schedule of Deposits (a) Company Name of Escrow Provider HanseEscrow Management GmbH Stresemannallee 118 D-22529 Hamburg contact@hanse-escrow.de http://www.hanse-escrow.de (b) Statement of Work In addition to the backup procedure with daily full backups as well as transaction log backups of the registry database, Registry Operator is implementing a new data escrow procedure to deposit the .de registry data with an established European escrow provider. By the time Registry Operator takes over the .net registry, the new procedure will be fully in operation. For the .net registry data, the same escrow provider will be used. In addition to this European escrow provider, Registry Operator is currently evaluating several US escrow providers to deposit .net escrowed data in the US. The registry data is transferred to the designated escrow provider as weekly full deposits; transaction data as daily incremental deposits. A verification process for the transferred data will be developed and implemented by Registry Operator. This process will be used on both sides to ensure the completeness, correctness, integrity, syntax and coherence of the transferred data at the escrow provider. The whole escrow process will be mutually examined and improved to meet the requirements of the registry agreements between Registry Operator and ICANN. (c) Schedule for Escrow Deposits Full Deposit The full deposit consists of five different reports, described in 2. reflecting the complete set of registry data. A full deposit is a snapshot of the registry data at 00:00:00 UTC every Sunday. Transactions which have not been committed at this point of time will not be exported. A full deposit file will be delivered until 06:00:00 UTC on Sunday. Incremental Deposit The incremental deposit consists of a report including the complete set of transactions that were processed by the registry system since the generation of the last full or incremental deposit file. The first incremental deposit after a full deposit covers the transactions not yet committed during the full deposit snapshot taken at Sunday 00:00:00 UTC and all transactions until Monday 00:00:00 UTC. A sequence of six incremental deposits follow until Saturday 00:00:00 UTC. Incremental deposits will be generated, verified and transferred until 04:00:00 UTC of the related day. 2. Deposit Format Specification Before describing the detailed reports, the following has to be considered: * Only if the related database field contains data, the respective XML element for a given object will be exported in combination with the opening and end tag. Thus, there will not be any empty elements in the reports. * All object reports contain an XML attribute id which is used to build the relation between the objects in the different reports. * XML files will be UTF-8 encoded to provide fully internationalized support. (a) Content of Reports Content of Full Deposit * Domain Object Report - includes all domain objects in the registry database. * Host Object Report - includes all host objects in the registry database. * Contact Object Report - includes all contact objects in the registry database. * Registrar Object Report - contains all registrar objects in the registry database. * Pending Transfer Report - contains all running transfers up to the moment of the full deposit. Content of Incremental Deposit * Transaction Report - includes all committed transaction records processed by the registry system since the last full or incremental deposit generation. (b) Format of Reports All reports will be generated in the XML format (XML 1.0 specification). Report- specific XML schemas (XML Schema 1.0 specification) will be stored separately. The schemas will be used for syntax and coherence checks while verifying the related report files. All report files will be generated with an XML header including attribute values for the registry TLD, the report type and the date and time the report was generated. The format of the header is shown in the following example. <?xml version="1.0" encoding="UTF-8" ?> <escrow version="1.0" tld="net" report="domain" date="2005-12- 21T03:00:00+01:00"> {Here the report contains the actual data being escrowed. It contains one element for each type (domain, host, contact, registrar, transfer or transaction) covered by the report. The specific format for each report is described below.} </escrow> (c) Detailed Description of Full Deposit Reports Domain Object Report The following report elements are included: * Fqdn - Fully qualified domain name. * Status - The domain status code. * Period - The registration period in years. * Owned-by - An identification (the "id" attribute of the registrar element) of the sponsoring registrar of the domain. * Created-by - An identification (the "id" attribute of the registrar element) of the registrar that originally created the domain object. * Created-on - The date/time the domain object was originally created. * Renewed-on - The date/time the domain was last renewed. * Updated-by - An identification (the "id" attribute of the registrar element) of the registrar that last updated the domain object. * Updated-on - The date/time the domain object was last updated. * Transferred-by - An identification (the "id" attribute of the registrar element) of the registrar that last transferred the domain object. * Transferred-on - The date/time when the domain object was last transferred. * Host-id - An identification (the "id" attribute of the host element) of a name servers for the domain. * Contact-id - Contact-ids that reference the contact records for this domain. Contact-id has the attribute "type" to denote the type of contact. "Type" can be one of: Registrant, Administrative, Technical or Billing. * Expires-on - The date/time of the domain expiration. * AuthInfo - The authorization information associated with the domain. * Pending-transfer - An identification (the id" attribute of the transfer element) for potentially existing transfers. An example of the domain container appears below: <domain id="1"> <fqdn>example.net</fqdn> <status>ACTIVE</status> <period>1</period> <owned-by>42</owned-by> <created-by>42</updated-by> <created-on>2005-08-14T12:34:56+01:00</created-on> <updated-by>42</updated-by> <updated-on>2005-08-23T16:14:26+01:00</updated-on> <host-id>99</host> <host-id>100</host> <expires-on>2006-08-15T13:34:56+01:00</expires-on> <contact-id type="Registrant">1</contact-id> <contact-id type="Administrative">2</contact-id> <contact-id type="Technical">3</contact-id> <contact-id type="Billing">4</contact-id> <authInfo>fooBar</authInfo> <pending-transfer>123</pending-transfer> </domain> Host Object Report The following elements are included: * Fqdn - Fully qualified host name * Owned-by - An identification (the "id" attribute of the registrar element) of the sponsoring registrar of the host. * Created-by - An identification (the "id" attribute of the registrar element) of the registrar that originally created host object. * Created-on - The date/time the host object was originally created. * Updated-by - An identification (the "id" attribute of the registrar element) of the registrar that last updated the host object. * Updated-on - The date/time the host object was last updated. * IP-address - Any IP addresses associated with this host, with an attribute type indicating whether it is an IPv4 or an IPv6 address. An example of the host container appears below: <host id="99"> <fqdn>dns1.example.net</fqdn> <owned-by>42</owned-by> <created-by>42</created-by> <created-on>2005-08-14T12:40:32+01:00</created-on> <updated-by>42</updated-by> <updated-on>2005-09-24T14:21:12+01:00</updated-on> <ip-address type="v4">192.0.2.0</ip-address> </host> Contact Object Report The contact element consists of the following elements: * Name - The name of the contact. * Organization - The organization for the contact. * Within the "contact" container is a sub-container named "postal" with the following elements: * Address - The street address of the contact. * City - The name of the city of the contact. * State-province - The name of the state/province of the contact. * Postal-code - The postal/zip code of the contact. * Country - The two-letter ISO 3166-1 code for the contact's country. * Voice - The voice phone number of the contact in E164a format. * Fax - The fax number of the contact in E164a format. * E-mail - The e-mail address of the contact. * Owned-by - An identification (the "id" attribute of the registrar element) of the sponsoring registrar of the contact. * Created-by - An identification (the "id" attribute of the registrar element) of the registrar that originally created the contact object. * Created-on - The date/time the contact object was originally created. * Updated-by - An identification (the "id" attribute of the registrar element) of the registrar that last updated the contact object. * Updated-on - The date/time the contact object was last updated. * Transferred-by - An identification (the "id" attribute of the registrar element) of the registrar that last transferred the contact object. * Transferred-on - The date/time when the contact object was last transferred. An example of the contact container appears below: <contact id="1"> <name>Juergen Mustermann</name> <organization>aol</organization> <postal> <address>Musterstrasse 1</address> <city>Frankfurt</city> <state-province>Hessen</state-province> <postal-code>60000</postal-code> <country>DE</country> </postal> <voice>+49.691234567</voice> <fax>+49.691234568</fax> <email>jmustermann@example.net</email> <owned-by>42</owned-by> <created-by>42</created-by> <created-on>2005-08-14T12:42:22+01:00</created-on> <updated-by>42</updated-by> <updated-on>2005-09-15T16:42:00+01:00</updated-on> </contact> Registrar Object Report The registrar element has the attribute "id", which is a unique identifier assigned by the IANA., and consists of the following elements: * Password - The password for the registrar. * Name - The name of the registrar. * Status - The registrar status code. * Contact-id - Any number of contact-id associated with this registrar. Contact- id has the attribute "type" to denote the type of contact. "Type" can be one of: Administrative, Technical or Billing. An example of the registrar container appears below: <registrar id="42"> <password>denic12345</password> <name>REGISTRAR-FOO</name> <status>ACTIVE</status> <contact-id type="Administrative">10</contact-id> <contact-id type="Administrative">11</contact-id> <contact-id type="Technical">12</contact-id> <contact-id type="Technical">13</contact-id> <contact-id type="Billing">14</contact-id> </registrar> Pending Transfer Report The transfer element consists of the following elements: * Period - The extension of lifetime (in years) of the domain. * Requested-by - An identification (the "id" attribute of the registrar element) of the gaining registrar An example of the pending transfer element appears below: <transfer id="123"> <period >1</ period > <requested-by>43</ requested-by > </transfer> (d) Detailed Description of Incremental Deposit Report The report which forms an incremental deposit is the transaction report consisting of all transaction records since last full or incremental deposit. Transaction Report The transaction element contains the properties "operation" and "type". "Operation" can be one of: add, modify, transfer or delete. "Type" can be one of: domain, host, contact or registrar. The transaction element is a container consisting of elements from the corresponding "type" element. For example, a transaction element with a "type" of "registrar" will have the same set of elements as a registrar element. For a "delete" operation, only the object ID is included in the transaction element. An example transaction container appears below: <transaction operation="modify" type="registrar"> <password>new password</password> <name>REGISTRAR-FOO</name> <status>ACTIVE</status> <contact-id type="Administrative">10</contact-id> <contact-id type="Administrative">11</contact-id> <contact-id type="Technical">12</contact-id> <contact-id type="Technical">13</contact-id> <contact-id type="Billing">14</contact-id> </transaction> 3. Escrow Transfer Process For a full and an incremental deposit, the related reports will be first generated based on the format description above. Every report will be verified against the specific schema to be formed correctly (syntax and coherence). For a full deposit, all reports will be concatenated. These concatenated reports form the complete deposit file. The deposit files for .net will be named as NET followed by a 4-digit sequence number for the related deposit transfer. During the next step of file processing, the deposit file will be split to produce deposit files with a file size of less than 1 GB each. This step is optional. Before the files are transferred to the escrow provider, they must be signed and encrypted. Registry Operator has decided to use PGP software. Registry Operator uses escrow provider's public key for encryption and Registry Operator's private key to sign the files. The encrypted files will be transferred to the data server of the escrow provider. 4. Escrow Verification Process After the reception of the escrow file(s) within the specified deposit window, the data will be moved to the non-public area of the escrow agent's server. The name of the escrow file and the size must be noted. The file(s) will be decrypted using the private PGP key of the escrow provider and Registry Operator's signature will be checked. If the whole deposit was split into several transfer files (not to exceed 1 GB), they will be concatenated in the correct sequence. The deposit file will be verified against the related XML schema. The report files will be encrypted with ICAN