ICANN | .NET Application Form

2.1 Application Vehicle and Institutional Set-up ------------------------------------------------ This bid is submitted by Asociación CORE++. This entity has as its only goal to submit the proposal and negotiate the subsequent contract with ICANN. But it will not sign the contract itself, nor act as the .net Registry. For these purposes, it will set up the institutional framework described below. 2.2 The participants in the CORE++ Bid -------------------------------------- CORE++ is a consortium of non-profit and for-profit organizations. The bulk of the .net-related activity is performed by functional organizations acting as suppliers to CORE++. As a result, it is necessary to describe the key functional organizations participating in CORE++ alongside the description of institutional set-up of CORE++. With regard to the Applicant's Business and Other Associated Activities, the determinant activities are those of the key functional organizations described below. 2.3. CORE++ Institutional Set-up -------------------------------- CORE++ is based on a two-level institutional set-up. The institutional set-up is structured in the form of * one coordinating organization (created as a new company) * several functional organizations (existing companies and institutions). The functional organizations are the ones that perform the essential technical tasks. They participate managerially in the coordinating organization, some of them also financially. Economically, they act as suppliers to the coordinating organization, but they have an obligation to continue to perform their function even in case the institutional tier should be unable to act. Financially, institutionally and technically, they have the highest level of solidity that can be achieved in the respective fields, yet could be replaced in the extremely unlikely event of failure. This form of organizations lies in the spirit of the Internet and modern concepts of high security and international risk management. The technical functions are encapsulated with clear interfaces and assigned to well-qualified, strong organizations. The coordinating organization is kept as light as possible. This set-up is more resilient than a monolithic organization. It also enables CORE++ to act both globally and regionally, achieving a degree of geographical and language diversity that a monolithic organization cannot match. 2.4. The Coordinating Organization ---------------------------------- The coordinating organization for the purpose of the ICANN RFP is set up as not- for-profit association CORE++, chartered with the objective of creating a .net registry by fostering the required cooperation of for-profit and not-for-profit organizations. Please seepart 1, Section 4 for a detailed description of CORE++ SL. It prepares, among other things, the institutional set-up for a for-profit organization, to be called "CORE++ SL". If the CORE++ Association is retained for the bid, then it will either sign the contract with ICANN in view of that contract being assigned to the newly created CORE++ S.L. At the time of this submission, the participants of the CORE++ are preparing the creation of the CORE++ Limited Liability Partnership. The final financial parameters will be determined shortly after ICANN's deadline, when the submission is public. This enables the financial partners in the CORE++ project to evaluate the precise context of their financial investment. Most of the functional organizations will formallly be partners (members, equivalent to shareholders, even if the term is not legaly correct)) of such CORE++ SL corporation. Some of them are still going though the internal aproval procedures for becoming formal members. Some other functional organizations will act as subcontractors without holding a stake in CORE++ equity. 2.5. The Functional Organizations --------------------------------- The CORE++ proposal is based upon the participation of key organizations, each of which performing for CORE++ that it already performs in the course for is normal business. The list below addresses the organizations performing technical functions. Other organizations with a mere financial involvement are listed under <Section 1, point 3.vii>. The functional organizations are listed here by time zone of their principal place of activity (from East to West). 2.5.1. NIDA Consortium NIDA Consortium is a joint venture between NIDA, Cydentity, and Inames. The National Internet Development Agency of Korea (NIDA) is a non-profit organization. It was founded in 1999 with the aim of building a stable internet address management system. Since then, NIDA has been in charge of allocating & managing Internet addresses in an efficient manner including R&D activities designed to increase the use of Internet. It has established a stable framework for managing the Internet address resources and promoting international cooperation and comprehensive policies. As a sub-organization of NIDA, Korea Network Information Center (KRNIC) also has endeavored in allocation and assignment of domestic IP addresses and registration of .KR domains. As of now, NIDA manages about 590,000 .KR domains. In addition, NIDA has showed continuous support for international cooperation and development in Internet through its outreach programs for developing countries and active participation in various international organizations and conferences. In this way, NIDA has been playing a key role in Internet development of Korea based on Korea's world-class high-speed network infrastructure. NIDA is located in Seoul, Republic of Korea. CyDentity and Inames are companies specialized in Internet Address Resources. They have prepared and materialized a global platform, R&D, and operations to manage the necessary technologies for operating a Registry since 2001, based on the skill and experiences in Internet Address Business. CyDentity has participated in the .org Registry Re-delegation in March 2002. In addition to developing technologies regarding expansion and efficient use of Internet Address resource, CyDentity and Inames provide an e-Business Total Solution & Service by consulting on matters such as e-Design, e-Promotion, and e-Biz. 2.5.2 CORE Internet Council of Registrars CORE is a not-for-profit membership association of Internet domain name registrars and registries active since 1997 in the internet industry. CORE was the first operable ICANN accredited registrar in 1999, and has always been actively present in the major technical and political development that ICANN pursued since its creation. Some of the high value services that CORE offers are the following: Registrar business operations With their shared registration system (SRS) CORE provides cutting-edge developments. * Registry consulting services CORE's professional expertise and their profound experience with state-of-the- art technologies make them a valuable adviser. CORE has repeatedly submitted successful bids to ICANN. * Registries back-end services Since 2002, CORE provides sophisticated back-end registry systems for two sponsored top level domains (sTLD), .aero and .museum. 2.5.3.Telefónica Telefónica Group is one of the world's leading telecommunications companies. Telefónica is the leading operator in the Spanish and Portuguese speaking markets and the fifth biggest operator in terms of market capitalization. Its activities are centered mainly on the fixed and mobile telephony businesses with broadband as the key tool for the development of both of these. The company has a significant presence in 16 countries and has operations of various sizes in approximately 40 countries. Telefónica has a strong presence in Latin America, where the company acts in eight countries and where it concentrates its growth strategy. Its costumer base amounts more than 115 million. Telefónica is a 100% public company, with almost 1.7 million direct shareholders. Its share capital currently comprises 4,955,891,361 ordinary shares traded on the Spanish Stock Market (Madrid, Barcelona, Bilbao and Valencia) and on those in London, Paris, Frankfurt, Tokyo, New York, Lima, Buenos Aires, São Paulo and the SEAQ International Exchange in London. 2.5.4. NICBR NICBR is the entity, coordinated by the Brazilian Internet Steering Committee - CGIBR, with the attribution to coordinate and to integrate all internet services in Brazil, assuring quality and efficiency in all offered services. Specially must support the development of internet services, approve and commend policies for the Brazilian internet, and technical and operational procedures, allocate the internet address space and register all domain names under the ccTLD <.br>, promote the interconnection of different backbones and collect, organize and share information and statistics about internet services. 2.5.5. ISC The Redwood City based Internet Systems Consortium, Inc. (ISC) is a nonprofit public benefit corporation dedicated to supporting the infrastructure of the universal connected self-organizing Internet -- and the autonomy of its participants -- by developing and maintaining core production quality software, protocols, and operations. ISC was originally founded to continue the work of maintaining and enhancing BIND following in the footsteps of U. C. Berkeley, Digital Equipment Corp., and Vixie Enterprises. ISC's operational activities include root name service, Internet hosting facilities, secondary name service for more than 50 top-level domains, and a DNS OARC (Operations, Analysis and Research Center) for monitoring and reporting of the Internet's Domain Name System. Today, ISC has employees in California, Massachusetts, Canada, Holland, and Australia, and a global constituency.

Direct responsibility for Business Operations ============================================= The overall responsibility for Business Operations of CORE++ will lie with Elmar Knipp as Concejero delegado. As he is a member of the Board (Consejo de administración), his background is described under that heading. Chief Operations Officer ======================== The operational management responsibility of the CORE++ will be held by Paul Lecoultre. As he is also board member, his background is described under that heading. Note: ===== The formal decision making authority lies with the General assembly of shareholders (Junta General), based on the number of votes held. Please see Part 1, Section 4 for a description of the setup and the respective powers. As the shareholders are legal persons, each of them can freely determine the delegate to the Shareholders's Assembly.

Relationship between Applicant and Registry officers ==================================================== The formal applicant of the present Proposal is CORE++ Association, solely chartered to handle the bid process. The Officers of the CORE++ Association are listed under Part 1, Section 4. The link between the Applicant and the Staff hierarchy of Registry organization, CORE++ SL (the future registry and in this sense, the de facto applicant) is established by the fact that the members of the Association are also the founding members of the Registry Organization. CORE++ SL has a straightforward chain of command. Its CEO, also member of the Board, will be the head of a Management Unit with few, if any, vertical levels, a its members will be the Coordinators of the functions provided by the subcontractors. A CFO, a COO and a CTO will cordinate those functions. A graphical representation is shown in Part 2, Section 5.b.iii.

Chief Financial Officer of CORE++ SL ------------------------------------ The overall responsiblity for the financial management of CORE++ LTDA, the coordinating organization, will be held by Dr. Winfried Boeing as Chief Financial Officer. Financial Controller of CORE++ SL --------------------------------- The CFO will be assisted by Mr. David Bernal as Financial Controller, knowlegdeable about the Spanish laccounting taxation legal framework. Personal Backgrounds -------------------- Dr. Winfried Boeing Winfried was educated in Germany and obtained a Master degree in Business Administration and Ph.D. (Magna Cum Laude) from the University of Cologne, specialized in Informatics, Economics, and Auditing. At the beginning of his career Winfried was employed by the University of Cologne in the Department of Business Administration and Auditing, and became Assistant Professor and Project Leader for the European ESPRIT initiative, dealing with the introduction of smart cards and highly secure office automation systems. In 1989 Winfried started working for Lufthansa German Airlines, later being seconded to the International Air Transport Association (IATA). At IATA, he build up the Internal Audit function, became Head of the Geneva Finance department, and served for seven years as the IATA Chief Auditor, inter alia responsible for worldwide Billing and Settlement Plans with over 120 billion US$ in cash settlement. End of 2002 he was promoted to Senior Director Interline Tariffs. October 2003 Winfried left IATA and co-founded the AirCash Holding Ltd., a Swiss consulting company, and is currently its CEO and Delegate of the Board. Winfried is active Professor of Finance and Accounting at the International University in Geneva. As his special area of expertise in Finance and IT is well known, Winfried is engaged in finance and restructuring projects dealing with innovative systems and future technology. Winfried is married and lives in Geneva, Switzerland. He speaks German, English and French. David Bernal Bosch David Bernal holds a Master's degree in General Management from the University of Barcelona with specialization in Taxation. In 1996 he started his career in accounting and tax advisory services. From 1999 through 2002 he was Head of department at PallarÃ©s Asesores de Empresa, an accounting and consultancy firm in Barcelona. In 2002 he joined Nominalia S.L., an ICANN-accredited registar, as head of its Finance and Administration department. Mr. Bernal is married and lives in Barcelona. He speaks Catalan, Spanish and English.

The principal technical responsibility for the registry operations will be held by Klaus Malorny as Chief Technical Officer (CT0). Klaus Malorny is Diplom Informatiker (similar to Master of Computer Science). Senior Software Developer at Knipp Medien und Kommunikation GmbH, Dortmund (10 1/2 years + during study). Senior Software Developer at Siemens Rolm Communication Inc., Santa Clara, USA (1/2 year). Computer experience for 26 years. Skills: C, C++, Java, SQL, Pascal, PostScript, Assembler (x86), _JavaScript, Perl and various other (scripting) languages; Database, GUI and web design & programming, object oriented programming, 2D/3D graphics, Internet protocols, document processing (XML/SGML), cryptography and related technologies. Domain related activities: designed and implemented Knipp internal registration system, designed and implemented CORE's second generation Shared Registry System. Participation in the IETF Provreg WG List, which designed EPP. Member of the technical advisory committee of the German ccTLD Registry, DENIC.

Head of DNS Operations: Changhun Lee ==================================== Chang Hun Lee is a CEO of Cydentity, one of the top innovative internet solution providers in Korea and one of the ICANN Accredited Registrars. He started his career at Samsung Electronics (UK) and Northern Development Company in United Kingdom. In 2000, he was appointed as ICANN Business Constituency Member. He has been acting as ICANN Registrar Constituency Member and URI (Uniform Resource Identifier) Forum advisor of NIDA. He holds a BA and Master degree in International Business from Newcastle Business School in UK. Internet related activities He has actively participated in the wide range of international conference such as ICANN, ITU, IETF, MINC, APRICOT, and APTLD as well as Korean Internet organization; NC, NNC and TTA. In 2002, he led a DotOrg Re-delegation bidding Project as Technical & Operating Backend solution provider and involved in professional projects regarding on domain development such as DotAsia Project, EPP application for KRNIC domain registration system, and collaborative ccTLD Name Servers. Head of Support Center for Asia-Pacific Region: TaeJe Kim ========================================================= TaeJe Kim is currently a CEO of INAMES, one of the top registrar companies in Korea. He served as a CEO and advisor of the Su-Won Cable Broadcasting, one of the biggest cable broadcasting companies in Korea. He completed the Graduate School of Industry & Information Studies at Kyung-Hee University in Seoul. He awarded the 'Chief Executive of Korea' from HeraldBiz Media and the '1st Innovative Management Company' from Seoul Economic Newspaper. Recently, he also received 'National Customer Satisfaction Management Award'. He was given this prestigious award in recognition of the high-quality domain registration operation of his company and his devotion to internet service development based on RFID and IPv6. Head of Support Office for EMEA Region: Alexandre Oulevey ========================================================= Alexandre Oulevey holds a Bachelor's degree in Information Sciences and a Bachelor's degree in General Management from the Universty of Geneva. He joined the CORE Secretariat support team in 2002 and became responsble for Member Support in 2004. Head of Support Office for Amercias Region: TBD =============================================== The head of the Americas region support office will be seconded by NIC.BR. Chief Architect, SRS and Database: Thomas Corte =============================================== Thomas Corte hold the degree of Diplom-Informatiker (similar to Master of Computer Science). He works as a senior software developer at Knipp Medien und Kommunikation GmbH, Dortmund, Germany since 1992 and has 20 years of computer experience. His skills include: programming in Java, C, C++, Perl, SQL, Lisp, Modula-2; object oriented analysis and design using the UML standard; database administration; web design & programming; implementation and administration of content management systems; document processing (XML/SGML/TeX). Managed several web application projects for major companies utilising Sun's J2EE platform (EJB/Servlet/JSP technology). Thomas is one of the architects of CORE's second generation Shared Registry System.

Initial Composition CORE++ SL Consejo de administración (Board of Directors) ============================================================================ The proposed initial composition of the Board of CORE++ SL is as follows: * Elmar Knipp (Knipp; "consejero delegado" * Dr. Jaechul Sir (NIDA Consortium) * Hartmut Glaser (NICBR) * Marcus Fauré (Global Village) * Jordi Hinojosa (Nominalia) * Paul Lecoultre (Managing Director) Personal Backgrounds ==================== Elmar Knipp ----------- 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 per cent of Knipp's shares. Elmar Knipp is vice president of CORE since 2001, is member of the Supervisory Board of DENIC eG since July 1998 and is one of the directors of Afilias since 2003. Elmar Knipp studied Computer Science and Business Administration at the University of Dortmund. Note: As the latter are applicants in the present RFP, Elmar Knipp has recused himselves from all decisions and communications regarding the .net RFP both in the Afilias and the Denic Boards. Dr. Jaechul Sir --------------- Dr. Jaechul Sir is President of KRNIC of NIDA, in charge of Internet Name Policy Section, Statistics & Policy Research Team, International Affairs Team, and a member of NNC (Number and Name Committee). Served as an arbitrator of the Korean Commercial Arbitration Board, a Promotion & PR director at KADO (Korea Agency for Digital Opportunity & Promotion), and a President of Hwa Shin CompuGraphic Company. Professional Engineer (P.E.). B.S. and M.S. in Computer Science from Hanyang University. Ph.D. in Computer Science from Soongsil University. Skills: Computer Network Design & Implementation; Internet protocols; Wired & Wireless Telecommunication Management; XML/SGML, C++, Delphi, Java, Pascal, Assembler, AutoLISP and other languages; Database (Oracle); Computer Graphics & Design (AutoCAD) ICT related activities: Took an active role in drafting the Internet Resource Administration Act and conducted Outreach Projects. Worked on digital divide projects at KADO as a project manager. Gave various lectures on ICT related topics at Hanyang University, Kyungwon University, and Catholic University of Korea. Hartmut Glaser -------------- Prof. Hartmut Richard Glaser Bachelor in Physics (USP - University of São Paulo - 1967); Assistant Professor for Physics at USP (1968 to 1970); Master in Electrical Engineering/Microelectronics (USP - 1972); Doctorate studies at USP (1972 to 1975); Assistant Professor in Electronics at USP (1970 to 2004); Vice- Coordinator of Microelectronics Laboratory (Research Center) at USP (1972 to 1988); Assistant to the Dean (Director) of the Polytechnic School (Faculty) of USP (1988 to 1993); Assistant to the Rector of University of São Paulo for InformationTechnologies/Internet (1993 to 1996); Assistant to the CEO of FAPESP - The State of São Paulo Research Foundation (1996 to 2004); Executive Coordinator of ANSP - the Academic Network of the State of São Paulo (1996 to 2002); Executive Coordinator of NICBR (1996 to 2004); Member of LACNIC´s Board of Directors (2000 to 2006); AC/ASO/ICANN Member (2000 to 2006) Marcus Fauré ------------ Internet technician. Marcus is co-founder and CTO of Global Village Germany, the company being established in 1996. It offers services to customers like Merck, Zuerich Aggripina and Underberg. He has been active in the development and operation of the GV registrar gateway which is used by 1000+ registrars to access a variety of top level domains. He is also responsible for security installations of a number of customers and has been a project manager for the development of e-learning portal sites that are supported by the EU commission and the German government. Since 2001 he is also chairman of the executive committee of CORE Internet Council of Registrars. As such, he pursuits CORE's mission to establish new TLDs on the Internet. He is co-author of the SITA ICANN agreement for .aero and worked on the policy for the special restricted registration procedure in that TLD. On the other hand, in ICANN's registrars' constituency, he gained experience in registrars' interests and their role in the success of a domain. Jordi Hinojosa -------------- Jordi holds a masters degree in Information Systems from the Universitat Pompeu Fabra and a Bachelor's degree in Economis from the Universidad Autonoma de Barcelona. He began his career in IT 19 years ago. His Internet-related activities began in 1994 as a project manager of Institut Catatala de Telematica Aplicada, an entity of the Catalan government. Subsequently, from 1996 to 1999, he worked with Cinet, one of Spain's first ISPs. In 1999, je joined Nominalia, an ICANN-accredited registrar, as CEO and Delegate Board Member (Consejero delegado). Paul Lecoultre -------------- Paul holds a bachelor's degree in Geography with a specialization in Political Science from the University of Geneva. He is a graduate of the in Geneva School of Commerce. He joined CORE in 2000 and move to the different departments. Since 2002, Paul is the Operations Manager of the CORE secretariat. His professional experience covers areas such accounting, technical development, daily operations, finance and public relations, including ICANN and registrar constituencies meetings.

Besides CORE, NIDA Consortium, NICBR, and, in the future, .ZADNA, other parties will have equity stakes in excess of 5%. These include, at the time of submission, Nominalia Internet SL (a Spanish limited-liability privately held company and ICANN-accredited registrar), Global Village GmbH, are German limited- liability member of CORE and and registrar in a number of ccTLDs, and Knipp Medien & Kommunikation GmbH, (a German IT consulting company and ISP9. In addition to the above, additional shareholders may join the company and aquire stakes in excess of 5%. In particular, the members of CORE++ Association are currently in discussion with additional prospective financial partners. For some of them, the decision- making proces involves a longer timeframe that the one allocated by the RFP. Those financial partners are expected to acquire stakes in excess of 5%. As soon as their commitments are final, CORE++ will identify them to the evaluators.

Applicant Organization Type =========================== The Applicant is CORE++, which in fact refers to two different organizations: Asociación CORE++ which is just the bid vehicle, and CORE++, S.L., which would sign the contract with ICANN as the registry operator if this bid is slected. Asociación CORE++ ----------------- The partners have established an association under Spanish law, called Asociación CORE++. This is a so-called civil law, not-for-profit entity with legal personality and members' liability limited to the amounts they bring into the association. As already noted several times, the only goal of this association is to serve as a bid vehicle, provide legal personality and manage the negotiation process with ICANN if the bid is successful. Its main goal would be, therefore, establishing the entity that would operate the registry. The association is formed as of today by the following members (already described in the previous section): CORE Internet Council of Registrars and NIDA Consortium, plus three CORE members and future financial partners within subsequent for-profit entity: Nominalia Internet SL, Global Village GmbH and Knipp Medien und Kommunicationen GmbH. Voting rights are one per member. Its board is composed of one representative of each member: * CORE (Werner Staub; Chair) * NIDA Consortium (Dr. Jaechul Sir; Deputy Chair) * Knipp (Elmar Knipp, Treasurer) * Global Vilage (Marcus Faure Secretary) * Nominallia (Jordi Hinojosa; member) This entity will handle the evaluation and negotiation processes with ICANN, in conjunction with the partners that, for different reasons, were not in a position to join the Association at this stage. The association will not have any other role or activity. The proposed registry: CORE++, Sociedad Limitada ------------------------------------------------ As soon as ICANN notifies its willingness to enter into negotiations with CORE++, the association will proceed to the establishment of a different entity, the proposed registry operator. Structure and bylaws has been discussed and approved by the association, and it is this second entity that is refered to as CORE++ in the remainder of the proposal, unless a specific reference to the association is made. (a) Legal type and name The entity will be established as a Limited Liability Company (Sociedad Limitada; SL) in Barcelona according to Spanish Law under the name of CORE++, Sociedad Limitada, usualy abbreviated as CORE++, SL. A SL is largely equivalent to a LLC or a German GmbH. It is a privately-held corporation, where partners have limited liability (the amount of their contribution to equity). (b) Equity Equity is represented by participaciones sociales (partners' particpatios), that we will call shares hereinafter, even if this term is not correct according to Spanish law. Shares have to be paid up in full, either in cash or in kind (equipment, etc). In this latter case, partners guarantee the veracity of the evaluation of such in-kind payments. Services or labour cannot be accepted as payment for shares. Shares will be issued at a premium (Ie, their nominal value would be several times inferior to its price). Equity is divided among different classes of shares. Class A shares have special rights regarding both dividends and voting. They would have right to 15% of the profits to be paid to partners (along with Class B shares). They also have a preference, along with Class B, in the liquidation process (their capital is paid back in preference to Class C). As for voting rights, each share would carry 2 votes. Please see also below at Junta General. These Class A shares will be allocated to founding members performing the Registry functions for CORE++ (CORE; NIDA; NICBR, and, in the future, .za DNA). Class B shares would carry the same special dividend rights (and preference in liquidation) than Class A, but no special voting rights (1 vote per share). These shares would correspond to the founders according to their initial investment, except for those with Class A ones. Class C shares would not carry any special dividend or voting right. They won't exist initially, but could be issued at the future. The entity will be able to issue any of these types of shares in the future. The partners have agreed to issue a number of Class A shares for .za DNA within the first year-and-a-half of existence of the corporation. In case that NICBR is not fully reorganised and recognized at the time of the establishment of the corporation, a number of Class A shares would also be issued for them as soon as they had completed all the legal steps to become fully operational. (c) Transmission of shares (participaciones) The transmission of shares within a SL is not completely free. In the case of CORE++, a partner wanting to sell any of its shares to an outside party will inform the Board of the number of participations involved, the party offering to buy them and the price. The Board will inform the partners. The partners will have a preferential right to buy them during 60 days, at the same price. In case of different partners wishing to buy them, the shares will be spread among them according to their relative participation in CORE++. The Junta (General Meeting) can also decide that the shares will be bought by CORE++ (and the partners would have three years to find a new buyer, and if not found, reduce the equity accordingly). This procedure will not apply whenever the shares are sold or otherwise transferred to a company within the same group. (d) Organs (i) Junta General The organ having the final say is the Junta General or shareholder's (memers) General Meeting. Short of directly manage the SL, which is prohibited, the General Meeting can do anything. Among its responsibilities there will be the approval of the budget, the approval of annual accounting, appointing (and removing) Directors, appointing the Advisory Council, approving the annual working plan and the strategic plan. Indeed, it's the organ that can decide on issuing new shares, reducing the capital, modifying the Bylaws, dissolving the company, changing its legal type or moving the legal seat. The General Meeting has to meet at lest once a year, as Annual Meeting. The Bylaws will provide for quarterly meetings, and special meetings can be called anytime the Board or partners having at lest 5% of the shares require so. The meetings can be hold by any electronic means that guarantee real-time interactive oral communication among all members present. Agreements require the affirmative vote of shares representing the majority of the votes cast, with a minimum of one third of the shares voting. It also will require the affirmative vote of a minimum of 2 partners, one of them holding Class A shares, the other holding Class B shares. (ii) Consejo de Administrción The Board (Consejo de Administración) will be composed of a maximum of 7 members (the minimum 3). The Board is the legal representative of the corporation. It is appointed by the Junta General. Only partners can be members of the Board. They appoint the physical person representing them within the Board. A single partner can appoint different physical representatives (if so agreed). CEO can also be appointed as Board Director. Agreements within Board are taken by simple majority of votes cast, proving a quorum of members present. We would create what is called Conejeros Delegados, ie, one or two people that are in fact the heads of the day-to-day management of the corporation, working for it full time. The initial composition of the Board would be the follwoing: * Elmar Knipp (Knipp; "consejero delegado") * Dr. Jaechul Sir (NIDA Consortium) * Hartmut Glaser (NICBR) * Marcus Fauré (Global Village) * Jordi Hinojosa (Nominalia) * Paul Lecoultre (Managing Director) (iii) Consejo Asesor CORE++ would create an Advisory Bord (Consejo Asesor). Its role would be advisory but the bylaws would specify that this Advisory Council will present its opinion before the General Meeting prior to the votes of the Budget, annual accounts, programs for the Special DNS & Network Security Fund, yearly evaluation of such fund, and Strategic Plan, at least. It would also oversee the internal neutrality reports and mediate in conflicts between customers and staff/Board. The Advisory Council would be composed of up to 15 members, elected by the General Meeting. A number of them wil in fact be selected from outside CORE++. The Board will submit within the first 4 months of existence a plan for the composition of such Council. The composition will follow these lines: * 1 member proposed by ISOC * 1 member proposed by ccNSO * 1 member proposed by Registrar Constituency * 1 member proposed by Root-server Operators AG * 1 member proposed by ISPCP * Up to 10 members proposed by Board of Directors in order to obtain balance between financial, technical and TLD policy backgrounds, with due consideration to geographical diversity. The role of this Advisory Council, beyond providing expert advise to Board and staff, is to counterbalance, on behalf of the .net User Community, the influence of inside Registry contractors and investors. The list of those instances selecting individuals to serve might vary from time to time. The initial composition of the Advisory Council (until end of October 2005) will be the follwong: * Prof. Kilnam Chon (Chair) * Eva Frölich * Paul Vixie * Amadeu Abril i Abril * Alan Levin * Emilio Sepúlveda * Dr. Tan Tin Wee * Dr. Nii Quaynor * Dr. Abhisak Chulya * Dr. Hiroshi Esaki * Lars-Johan Liman CORE++ will gladly provide CVs for all these distinguished individuals on request.

1.5 Number of Employees ----------------------- Overview Asociación CORE++, the bid vehicle, has no employees on its own. Hereinafter the responses will refer to CORE++ SL, the future entity that would become the registry operator. As already mentioned, CORE++ is a company which consists of a group of experienced players in the domain area. The main players are ccTLD registries and the consortium of registrars known as CORE (Council of Registrars, also with experience in the registry side). The principle behind CORE++ is to do the work by the members of the company whenever feasible: decentralization and coordination. Whereas overview and coordination tasks should be done through the hierarchy of CORE++ itself. This principle results in an effective, stringent, conversant and stable solution for the management of the .net TLD. Coordinating Office ------------------- The coordinating office of CORE++ SL is estimated to have a staff of 13, including the CEO, COO, CTO, CFO legal advice and administrative support. This rather flat, high quality Office has as primary function the co-ordination of the tasks of the functional units described below. Functional Units ---------------- Asia/Pacific SRS Location and Support Office (Subcontractor: NIDA Consortium) The Asia/Pacific SRS location is estimated to have over 24 staff devoted to .net. Of these, at least 10 are technical staff, 6 administrative officers and 8 support staff for the Asia-Pacific Support office. European SRS Location, and EMEA Support office (Subcontractor: CORE) The European SRS location is estimated have 8 technical staff, including the Chief Architect, developers and second-level support. And additional 4 staff are devoted to the EMEA Support office. (Total of 12.) Americas Support Office (Subcontractor NICBR) The Americas Support office is projected to have 12 support staff as well as 4 technical staff for the Whois servers. (Total of 16.) TLD Servers Operation and Coordination (Several Subcontrators coordinated by ISC) The person-count equivalent for the human resource in this area is estimated at 4 full-time jobs. Summary ------- The total projected staff is 13+24+12+16+4=69

Compliance with Existing Consensus Policies ------------------------------------------- CORE++ operates the .net registry in a manner that is completely compliant with all existing consensus policies of ICANN. Moreover, CORE++ also intends to enhance the .net registry by features that facilitate the implementation of ICANN policies for .net registrars. This is especially the case for ICANN's Inter-Registrar Transfer Policy. ICANN's Inter-Registrar Transfer Policy --------------------------------------- Regarding a registry's duties, CORE++ implements all mechanisms and rules required by ICANN's Inter-Registrar Transfer Policy. Details concerning specific aspects of the implementation are provided in the following subsections. First Level Dispute Resolution CORE++ provides personnel and other resources for the implementation of the first level of ICANN's Registrar Transfer Dispute Resolution Policy. Transfer Undo Mechanism CORE++ implements all required functionality to support the transfer undo mechanism, using the recommended approach described in ICANN's document from July 7th, 2004 at http://www.icann.org/transfers/TransferUndoMechanismFinal07Jul04.pdf. Periods Preventing Transfers The Inter-Registrar Transfer Policy gives nine specific reasons a losing registrar may bring forward to reject an outgoing transfer. Two of these reasons are dealing with transfer attempts happening during the first 60 days after the creation or most recent transfer of a domain, respectively. The registry system implemented by CORE++ detects such cases and prevents the initiation of transfers for affected domains in the first place, so there is no need for registrars to handle cases like this themselves. This means that within the first 60 days after the creation of a domain, any requests to transfer this domain from one registrar to another are rejected by the registry server. Additionally, within the first 60 days after the most recent successful transfer of a domain, any requests to transfer this domain from one registrar to another are rejected by the registry server. In accordance with the transfer policy specification, the latter rule is not applied if the transfer in question is done to transfer the domain back to the original registrar in cases where both registrars so agree and/or where a decision in the dispute resolution process so directs. Obtaining Contact Information for Automated Transfer Processing ICANN's Inter-Registrar Transfer Policy requires a gaining registrar to determine contact information about a domain's registrant and administrative contact prior to the initiation of the domain's incoming transfer, in order to send the FOA document for gaining registrars to these contacts. Consequently, a registry operator should make sure that this contact information - especially the respective e-mail addresses - can be easily obtained by a gaining registrar; in particular, a registrar's automated system (it can be assumed that most registrars have such a system) should be able to accomplish this without manual human interaction. Due to the "thin registry" model used for the .net registry at this moment, there currently is little the .net registry can do to assist registrars in this task. Since the contact information is not known to the registry, registrars must rely on the whois server provided by the domain's current registrar of record to obtain the needed contact information. Several problems arise from this. First, contacting a whois server represents a cumbersome "out-of-band" communication for a registrar that otherwise uses RRP (or EPP) for all communication involved in the registration process - it should be possible to do all registration related transactions via the same channel. Second, the lack of a rigid whois output specification allows each whois server to use its own proprietary data format, thus requiring other registrars to implement different parsing rules for different whois output variants. In addition, things sometimes even become more complicated as some registrars do not include the required registrant/admin information in their whois output at all. The .net registry system implemented by CORE++ offers the following features to overcome (or at least relieve) these problems: * All registrars have the possibility to switch domains from the "thin registry" model to the "thick registry" model. Among other things, this switch requires the submission of contact information for the involved domain to the registry. Each submitted contact is required to have an associated e-mail address that can be used for electronic submission of the FOA. * If a losing registrar has switched a domain to the "thick registry" model, the contact information part relevant to the transfer policy is made available to a gaining registrar via the contact:info command of EPP. While this sounds like a matter of course, it is not - currently, not all existing EPP-based registries allow the inquiry of repository objects that are not sponsored by the requesting registrar. * The .net registry's data disclosure policy is carefully chosen to provide the data required for automated transfer processing on the one hand, while ensuring the maximum protection of contact data against data mining and similar threats on the other hand. In particular, the results of a contact:info command submitted to the registry's EPP server (which is accessible only by .net registrars) should always provide at least as much information as the (public) .net Whois server's output on inquiry of the same contact; it does not make sense to deprive registrars using EPP from information that is available via public Whois anyway. In a nutshell, the measures described above are intended to enable registrars to obtain the information they need to implement ICANN's Inter-Registrar Transfer Policy in the most convenient way possible. Obtaining Additional Information about Transfer Denials As mentioned above, the Inter-Registrar Transfer Policy requires losing registrars to give one of nine specific reasons upon rejection of a losing transfer. If a transfer rejection occurs, the gaining registrar - in order to be able to inform his customer - should have means to obtain the reason why his transfer request was denied. However, at the time of writing, no registry affected by the Inter-Registrar Transfer Policy offers technical means to transport the denial reason from the losing to the gaining registrar. Since this is a service that should be provided by the registry, the .net registry system implemented by CORE++ features an EPP extension for the transmission of the denial reason by the losing registrar as well as the convenient provision of this reason to the gaining registrar. ICANN's Whois Data Reminder Policy (WDRP) ----------------------------------------- As described in section 2.3.a, CORE++ offers registrars that have switched domains to the "thick" registry model assistance for fulfilling their duties in respect to the Whois Data Reminder Policy, primarily by a service that creates periodic e-mail notifications to the registrants containing the Whois data. Other Policies -------------- As far as the duties of the registry operator are concerned by the respective policies (as opposed to duties of the registrars), CORE++ will also follow and support all remaining current consensus policies applicable to ICANN-accredited registrars (as listed at http://www.icann.org/general/consensus-policies.htm), i.e. * the Uniform Domain Name Dispute Resolution Policy (UDRP), * the Whois Marketing Restriction Policy, * the Restored Names Accuracy Policy and * the Expired Domain Deletion Policy. Compliance with Future Consensus Policies ----------------------------------------- CORE++ agrees to comply with all future consensus policies. In addition, CORE++ will actively participate in ICANN's established bottom-up policy development process. The Whois reform seems to be the most urgent task in this policy efforts.

CORE++ operates the .net registry in a manner that provides a maximum degree of equality in access and support for all ICANN-accredited .net registrars worldwide. The multi-national approach of CORE++ helps in achieving this goal, especially in terms of geographical domain name server distribution and the variety of available support languages. Details are provided in the following subsections. Code of Conduct --------------- For further certification of the intent described above, CORE++ will devise a Code of Conduct (in agreement and negotiation with ICANN) based on the principles of a neutral, trusted third-party operator providing fair and efficient DNS services to registrars and Internet users. Equal (non-discriminatory) access to the registry's services to all ICANN- accredited registrars is the paramount principle. But the confidential treatment of the data (be that registrars or registrants) and an efficient support is equally relevant. In this regard, CORE++ will comply with the now-standard provisions regarding Equal Access Certification and Access to Data Policy (plus all other issues in Annexes H & I of the various registry agreements). The proposed Code of Conduct based on the following principles: * Operation as a neutral, fair, non-discriminatory, trusted third-party. * Other than in connection with distribution of dividends or their economic benefits among its members, CORE++ and its subcontractors will not show preference or provide special consideration to any specific registry or registrar. * Any member, affiliate, subsidiary or any other entity related to CORE++ that also operates as a registrar shall keep separate books of account for such activity. * Neither CORE++, its members or its subcontractors should register domain names in their own right, except when expressly provided in the ICANN contract. * No proprietary information of registrars shall be disclosed to CORE++ members, affiliates, subsidiaries or subcontractors except to the strict amount that the registry operations require. The same applies to user's data. * CORE++ will run internal neutrality reviews, under coordination of its Advisory Council. ICANN and CORE++ might agree to carry external neutrality reviews as well. Organizational Conflict of Interest Compliance part for CORE Internet Council of Registrars One of the subcontractors providing DNS services for CORE++ will be CORE Internet Council of Registrars. This association of registrars, ICANN-accredited and not, acts itself as an ICANN-accredited registrar for its members. In this regard (and in connection to any other subcontractor that could be in the same situation in the future), the following steps will be taken: * Activities will be separated into two separate legal entities (registry and registrar services). * Each entity will have its own, independent Executive Committee (Board) and management, and will also have financial separation. * Premises when located in same or close premises, will be physically separated and only personnel duly accredited as CORE++ Registry-related will be allowed in. * Adequate measures for handling protection of information, and the related training and possible conflicts, will be established with the assistance of the Advisory Council and the agreement of ICANN. Similar procedures would be established if any other subcontractor would also act in the future as a provider of gTLD registrar services. Registry/Name Server Access --------------------------- The .net shared registry system implemented by CORE++ processes requests from registrars by applying a strict, unbiased "first come, first served" principle. Therefore, no registrar is favored or discriminated with respect to other registrars whatsoever. Due to the continuous, 24/7 uptime of the SRS, no disadvantages concerning registry access arises from time zone issues. To further ensure a fair competition between all .net registrars, each registrar is assigned a limited number of connections that may be used to send RRP/EPP commands. The same limit applies to all registrars - this should help to balance bandwidth inequalities among registrars to some extent. Additionally, the data center hosting the SRS server is chosen to provide a reasonably balanced internet connectivity (in terms of network topology and vicinity to exchange points) to all registrars worldwide. In the same fashion, the locations for the .net name servers are also chosen to supply a high degree of network topological distribution and geographical diversity. Technical support ----------------- Support Locations and Languages CORE++ offers .net registrars continuous, 24/7 technical support (365 days per year, 7 days a week, 24 hours a day). This is provided by three support centers at three different locations, namely Brazil, South Korea and Switzerland. Each day is split into three slots of 8 hours each, and each of these three 8- hour support time slots is mainly provided by one of the 3 support centers (incorporating a reasonable time overlap that ensures a seamless coverage). The following languages are supported: * Support in English is provided by all three support centers and is therefore available 24 hours a day. * The support center in Brazil additionally supports Portuguese and Spanish. * The support center in South Korea additionally supports Korean, Chinese and Japanese. * The support center in Switzerland additionally supports French, Italian and German. While each support center is primarily responsible for its assigned 8-hour time slot, each center also employs a minimal staff during times outside of its slot. This enables CORE++ to support each of the languages mentioned above virtually at any time. Support Procedures and Issue Tracking Requests for support are accepted via phone, fax, e-mail and a web interface to the trouble ticket system. Each e-mail support request will be confirmed with an immediate receipt confirmation and subsequently dispatched to a support staff member capable of the corresponding language. The initial answer from the support staff will usually be issued no later than 24 hours after the receipt. Problems that cannot instantly be solved are entered as a trouble ticket into the issue tracking system. All registrars are able to monitor the progress of their tickets or to provide additional input via the issue tracking system's web interface. The ticket system is also used to escalate problems to higher levels within the staff, where the software development team serves as the highest level. Support Quality Assurance Quarterly audits are performed to assess the support quality. This includes questionnaires (twice a year) that collect information from registrars regarding their satisfaction with the support team. The analysis will be used to provide guidelines for additional staff training and other improvements. During the pre- transition time and for three months after the transition, these audits are performed each month. Operational Test and Evaluation System In addition to the production SRS, CORE++ provides an independent Operational Test and Evaluation (OT+E) system to give all registrars the opportunity to develop and test their client software in a self-contained "sandbox" environment that does not interfere with production business. The OT+E system emulates the behaviour of the production system as closely as possible to allow for realistic testing. It also includes a Whois server and a name server fed from the sandbox data, which facilitates the testing of transfer policy and DNSSEC implementations on the registrar side, respectively. For tests concerning the proposed Protected Registration Service, the registrars will be supplied with free test certificates. The OT+E system differs, however, from the production system in some respects to further simplify development for the registrars: * Each registrar is granted two independent identities on the OT+E system. This enables each registrar to test domain transfers easily by creating domains with the first identity and transferring them to the second identity (or vice versa). * To allow short turnaround times for registrars during their tests, most of the periods and deadlines used by the production system are significantly shortened (or entirely disabled) on the OT+E system. For example, the OT+E system - contrary to the production SRS - allows the transfer of newly created or recently transferred objects before the end of the usual 60-day period. * Major SRS upgrades, possibly involving protocol changes or other enhancements that require changes to the registrar's client software, are always installed on the OT+E system some time before being deployed on the production system. The actual lead time depends on the nature and the extent of the changes involved.

  Registry Registrar Protocol - RRP
  ---------------------------------

The current .net registry operator requires registrars to use RRP, the Registry
Registrar Protocol as described in RFCs 2832 and 3632, for the transmission of
commands to manipulate their registry object inventory. In the meantime, the
Extensible Provisioning Protocol (EPP) has become the preferred registry-
registrar protocol among major registries. As described below, the registry
system developed by CORE++ supports EPP as a registry-registrar protocol for
.net.

CORE++ is aware that the requirement for an immediate switch from RRP to EPP on
July 1st, 2005 would burden .net registrars with considerable implementation
efforts in order to adapt their client software. Therefore, CORE++ continues to
support RRP as a registry-registrar protocol for one year after the .net
migration in July 2005. This hopefully provides enough time - even for smaller
registrar companies - to implement the changes necessary to use EPP while being
able to continue their daily domain business via RRP. The RRP implementation of
CORE++ will support all RRP commands offered by the current .net registry
operator.

During their transition from RRP to EPP, registrars may use both protocols in
parallel. This gives them the opportunity to fall back to RRP communication if
problems occur with their EPP implementation.

It should be noted that the continued RRP support is restricted to the "thin
registry" model and the current .net functionality. Any features of the "thick
registry" model, the standard EPP protocol or extensions thereof that exceed the
current capabilities of RRP will not be added to the .net RRP implementation.
Registrars seeking to benefit from new .net features immediately must switch to
EPP to do so.


  Extensible Provisioning Protocol (EPP)
  --------------------------------------

CORE++ implements EPP 1.0 (as described in RFCs 3730, 3731, 3732, 3733, 3734,
3735 and 3915) and uses it as the primary registry-registrar protocol for .net,
replacing RRP that has been used for this purpose before. As described above,
RRP however continues to be supported for one year after the transition.

In order to avoid any interference with the migration of registry services from
the current registry operator to CORE++, EPP is not supported right from the
beginning of registry operation in July 2005. Instead, EPP is introduced shortly
after the migration of registry services from VeriSign has been completed and
.net has resumed normal registry operation.

The provided EPP implementation offers all common operations on domains, hosts
and contacts, including (but not limited to) create, update, delete, check,
info, transfer and renew commands. In addition to the base EPP 1.0 standard,
CORE++ implements various EPP extensions. On the one hand, these extensions are
related to additional services CORE++ intends to provide (see section 2.3.(a)).
On the other hand, these extensions result from extensive experiences members of
CORE++ made with EPP as registrars. These experiences either discovered
shortcomings of the EPP protocol or proved doubts that have been expressed by
CORE++ members in the related IETF ProvReg working group, but have been rejected
due to a too registry centric view or lack of farsightedness demonstrated by
members of the working group. Some of these extensions have been implemented in
another registry-registrar protocol, namely in the Payload 2.0 SRS protocol used
internally by CORE.

The extensions are fully optional. No registrar is forced to implement and use
them.


  EPP with Accounting

Due to the move from fixed to flexible pricing models, promotions and various
grace periods that may or may not apply, it becomes more and more difficult to
estimate the actual costs of a registration. While these costs may appear later
in accounting reports, the registrar is unable to determine this at the time of
command submission. CORE++ proposes an extension that provides accounting data
in each response and poll notification. This contains the debit or credit the
operation caused as well as the total accumulated cost of the domain.


  Transaction Management Extension

EPP 1.0 is missing methods that allow the registrar to determine the outcome of
a command in case of a communication interruption during an ongoing transaction.
With the proposed extension, registrars are able for the first time to implement
a generic and simple algorithm to handle this situation. The command extension
uses the client transaction ID that can be supplied by the registrar. It either
returns the result of the command where this transaction ID has been used or the
notice that no such command has been received by the registry in a certain time
frame. Based on this, the registrar can easily decide whether he needs to
resubmit the interrupted command or not.


  Autorenewal Information via EPP Poll Messages

The automatic renewal of domains is performed by the registries in background.
To determine whether a domain has been renewed or whether it is eligible to the
renewal grace period, registrars either have to perform cumbersome and
inaccurate date calculations or have to use out-of-band sources like autorenew
reports that may not be available in time. CORE++ proposes additional poll
notifications after the renewal and after the end of the grace period to
simplify

the handling of the renewal process and to extend the completeness of the EPP
protocol.


  Support for Communicating the IRTP Transfer Reject Reason

The Inter-Registrar Transfer Policy requires losing registrars to give one of
nine specific reasons upon rejection of a losing transfer. If a transfer
rejection occurs, the gaining registrar - in order to be able to inform his
customer - should have means to obtain the reason why his transfer request was
denied.

EPP 1.0 does not support the transmission of this information from the losing to
the gaining registar out of the box. However, CORE++ is convinced that this a
service that should be provided by the registry. Therefore, .net registry system
implemented by CORE++ features an EPP extension for the transmission of the
denial reason between the parties.


  Thick Registry Model
  --------------------

The .net registry is currently using a "thin registry model", meaning that the
object repository maintained by the registry only contains data about domain and
host objects, but no contact data. Experiences with new generic top level
domains like .info and .biz have revealed considerable advantages of the "thick
registry model" (which adds contacts to the registry's object repository). Only
recently, the introduction of ICANN's new Inter-Registrar Transfer Policy has
shown the huge benefits of having a single, uniform data source for contact data
(instead of a variety of different whois servers, data formats and disclosure
policies spread across all registrars).

Accordingly, CORE++ uses a thick registry model as the "primary" data model for
the .net registry. As soon as EPP is introduced, registrars switching to EPP
have the opportunity to adopt the thick registry model. Introduction of the
thick registry model primarily means that the switching registrar has to supply
contacts for its domains to the .net registry. However, registrars may choose to
opt out of the thick registry model and continue to use the thin registry model,
keeping their contact data locally. They may even use a "mixed" approach, i.e.
decide upon the used model on a per-domain basis. This choice is offered to
registrars that may want to avoid the overhead that is coming with the
transition from the thin to the thick model or may have other reasons not to
disclose their contact data to the registry for all domains. Consequently,
CORE++ continues to support both the thick and the thin registry model for .net.

It should also be noted that a registrar switching from RRP to EPP does not have
to switch from the thin registry model to the thick registry model at the same
time - a registrar may continue to use the thin registry model while using EPP
to submit commands to the registry. A registrar may choose to switch to the
thick registry model completely in order to be freed from the duty to implement
an own Whois server.

It should be noted that the usage of the thick registry model requires that the
registrar switches to EPP, because RRP is not suitable for use with a thick
registry model and can not be extended in a reasonable manner for this purpose.

Both transitions (RRP to EPP, thin to thick registry model) are made as easy as
possible for registrars in order to minimize their efforts. As stated above,
registrars are granted a full year to migrate from RRP to EPP. Concerning the
thick registry model, they may decide to use it on a per-domain basis, which
offers a maximum of flexibility. See the migration plan at the end of this
document for details.


  Accreditation Test
  ------------------

As was the case with previously launched or migrated registries, .net registrars
switching to EPP - as well as all new .net registrars - have to pass a technical
accreditation test to demonstrate their basic capabilities regarding registrar-
registry communication over EPP.


  Supported Programming Languages and Toolkits
  --------------------------------------------

CORE++ does not dictate or prefer the use of any particular programming language
or technical approach by registrars. As long as the technical accreditation test
is passed and subsequent registrar-registry communication is done in compliance
with the protocol, registrars may freely choose the means of implementing their
client systems.

However, CORE++ explicitly supports registrars that use the established and
widely used Open Source EPP toolkit "EPP-RTK" (available at SourceForge.net)
which currently supports the C++ and Java programming languages. CORE++ has been
able to gain extensive experience with the EPP-RTK for Java, as CORE uses
various versions of this toolkit to do transactions with the .info, .org, .name
and .coop registry systems as a registrar.

This hands-on experience revealed that the Java RTK - while doing a good job for
basic EPP communication - comes with some drawbacks and flaws, especially
regarding the overall software design and the handling of EPP extensions in
particular. Consequently, CORE++ plans to provide an own Java toolkit at a later
date to overcome these weaknesses.


  Reports
  -------

In addition to RRP, the current .net operator also provides report files that
contain e.g. domain transfer or renewal related information. These reports are
generated on a regular basis and may be downloaded by registrars via FTP. The
.net registry system operated by CORE++ continues and extends the provision of
such reports on a dedicated FTP server.

CORE++ is aware that many .net registrars have implemented systems which
automatically download and process the available reports. In order to facilitate
the transition for these registrars, any reports provided by the current .net
operator are also made available by CORE++ after the transition, matching the
previously available reports closely in terms of generation frequency, file
format and the naming of files and directories on the FTP server.

The publicly accessible domain name service for the .net zone supports at least the following RFCs: RFC 1034, RFC 1035, RFC 1982, RFC 2181, RFC 2671, RFC 3226, RFC 3425 and RFC 3596. Although they do not directly concern the DNS protocol, RFC 3490, RFC 3491 and RFC 3492 are also supported. For internal purposes (not relevant to Internet users), RFC 1995, RFC 1996, RFC 2136 and RFC 2931 are supported. CORE++ will implement RFCs that result from the emerging DNSSECbis standard. Also, CORE++ will implement future RFCs that are applicable to the domain name service of the .net zone.

Definitions The software used by CORE++ to operate the .net registry is subject to continuous development, driven by the requirement of new features, changed registry policies and business practices on the one hand and the elimination of identified issues on the other hand. The results of this development have to be deployed on the production and OT+E registry systems as soon as they are found mature by internal quality assurance processes. For this purpose, CORE++ will -- depending on the nature and the impact of the changes -- apply one of the actions defined as follows: * Patch: A patch means a minor modification for the purpose of error correction. Patches do not require corresponding changes to client applications developed, implemented and maintained by each registrar. * Update: An update means a new release of the software which may contain error corrections, minor enhancements and -- in certain circumstances -- major enhancements. Updates may require changes to client applications by each registrar in order to take advantage of the new features and/or capabilities and to continue to have access to the Shared Registration System. * Upgrade: An upgrade means a new release of the software which involves the addition of substantial or substantially enhanced functionality. Upgrades require changes to client applications by each registrar in order to take advantage of the new features and/or capabilities and to continue to have access to the Shared Registration System. A version number is assigned to each release of the software (emerging from a patch, an update or an upgrade). The version number consists of three numbers separated by dots, where the first number is incremented for each upgrade, the second for each update and the third for each patch. Deployment Methodology The SRS is designed to allow for uninterrupted service even during the deployment of new software by usage of multiple, redundant systems that are taken off-line and patched one after the other. Depending on the extent and nature of the involved patch, update or upgrade, the deployment may therefore not have impact on the external availability of the SRS and other components. Announcements For patches, updates and upgrades that have impact on registrars, CORE++ will give each registrar notice at least 60 days prior to deploying the updates and upgrades into the production environment. Such notice will include an initial thirty days' notice before deploying the update (if it requires changes to client applications) or the upgrade into the Operational Test and Evaluation (OT+E) environment to which all registrars have access. CORE++ will maintain the update or upgrade in the OT+E environment for at least thirty days, to give each registrar the opportunity to modify its client applications and complete testing before implementing the new code in the production environment.

SRS Performance Maximum processing time read operations per object: 250 ms Maximum processing time write operations per object: 500 ms Maximum processing time of a token: 250 ms The term 'object' relates to a contact, host or domain. Some EPP commands allow the specification of multiple objects (e.g. the "check" command). In this case, the guaranteed processing time for the command results from the given value multiplied with the number of objects. In respect to the current .net registry agreement, a "check" is considered as a read operation, while an "add" is considered as a write operation. For the Protected Registration Service, so-called tokens are used to authorize an operation. The evaluation of the associated privileges requires additional processing time for each involved token. The time has to be added to the maximum processing time for the involved write operations. The processing time is measured from the arrival of the request at the SRS to the delivery of the response. This excludes any network latency CORE++ and its service providers are not responsible for. SRS Outages Total outage: 8 hours/month Unplanned outage: 4 hours/month Major upgrade outage: 12 hours/month (may occur twice a year) DNS Performance Maximum round-trip time: 300 ms Maximum packet loss: 10 % Maximum update delay: 15 min DNS Outages Total duration of service unavailability: 120 min/month (99.73% availability) Total duration of unplanned outage time: 30 min/month (99.93% availability) Whois Performance Maximum response time for non-wildcard queries: 500 ms Maximum update delay: 10 min The response time is measured from the arrival of the request at the Whois server to the delivery of the response. This excludes any network latency CORE++ and its service providers are not responsible for. Whois Outages Total outage: 8 hours/month Unplanned outage: 4 hours/month

This service level agreement is based on the current .net registry agreement, but updated to accommodate the plans of CORE++ for the .net registry. It provides means to measure the registry performance and defines how registrars are credited if CORE++ should not meet the defined service levels. A) Definitions * 1) The term "monthly timeframe" is defined as a single calendar month beginning and ending at 00:00 UTC. * 2) The term "planned outage" defines the inavailability of the shared registry system ("SRS") due to pre-announced maintenance. The so-called "planned outage period" is a predefined time slot where planned outages are scheduled under normal conditions. The designated time period is 6:00 to 14:00 UTC on Sundays, but is subject to change after respective notice to the registrars. There will be no more than 8 hours of planned outage per month and no more than 4 hours per calendar week. Two additional so-called "extended planned outages" of up to 12 hours each (extending the planned outage period) may be scheduled within a year. These represent the total allowed planned outages for the respective month, i.e. no other planned outages are to be scheduled in this month. * 3) The "SRS availability" is defined as the time when the SRS is fully operational. This is e.g. not the case during planned outages or extended planned outages. * 4) The "SRS unavailability" is defined as a failure of systems within the responsibility of CORE++ or its service provides that causes the registrar to be unable to either: * a) establish an RRP or EPP session with the registry system as defined in the RFCs 3632, 3730, 3734 * b) execute at least 95% of the commands within the assured performance as defined in appendix D during each monthly timeframe. * 5) The term "unplanned outage time" denotes all of the following: * a) the amount of time between the confirmation of a registrar's claim of SRS unavailability by opening a trouble ticket at CORE++ and the point in time where the problem has been declared as resolved by both the registrar and CORE++. Such a case will be considered as an SRS unavailability for the individually impacted registrar only. * b) the amount of time between the first confirmation of an SRS unavailability affecting all registrars by opening a trouble ticket at CORE++ and the point in time where the problem has been declared as resolved by the registry. * c) the amount of time that planned outages or planned extended outages exceed the limits as defined in A.2. * d) the amount of time that planned outages or planned extended outages occur outside the planned outage period as defined in A.2. * 6) The "monthly unplanned outage time" is defined as the sum of all unplanned outage times during the monthly timeframe. The unplanned outage time diminishes the available monthly planned outage time by up to 4 hours. * 7) "Whois service" denotes the CORE++ Whois server using either the Whois or the emerging IRIS protocols as described in appendix O. * 8) ".net name servers" means all name servers that are either operated by CORE++ or its service providers for the purpose of hosting the .net zone. B) Responsibilities of CORE++ and .net registrars * 1) A registrar must report each occurrence of an alleged SRS unavailability to the CORE++ support staff by one of the offered communication means (e- mail, fax, phone, trouble ticket system web interface) in order for the occurrence to be treated as an SRS unavailablitity in terms of this SLA. * 2) Should all registrars be affected by an SRS unavailability, CORE++ is obliged to open a corresponding trouble ticket and to notify all registrars of the ticket and its details immediately. * 3) Both registrar and CORE++ agree to determine the cause of an alleged SRS unavailability using reasonable commercial good faith efforts. If it is mutually acknowledged to be caused by CORE++, the duration of the issue will be counted as unplanned outage time. * 4) In order to verify that RRP/EPP sessions can be established and that RRP/EPP commands can be successfully performed, CORE++ will continuously monitor the SRS from at least two external locations. * 5) A registrar must inform CORE++ whenever its estimated volume of transactions will exceed the registrar's previous month's volume by more than 25% (not counting "check domain" commands). Should the registrar fail to do so, and the registrar's volume increases by 25% or more over the previous month, and should the total volume of transactions of all registrars for that month exceed the registry's actual volume of the previous month's transactions by more than 20%, then the registrar will not be eligible for any SLA credits (as defined in section C) in that monthly timeframe. The Registrar must submit its forecast at least 30 days prior to the first day of the next month. CORE++ agrees to supply transaction summary reports on a monthly basis. * 6) CORE++ will notify registrars of planned outages outside of the planned outage period at least 7 days in advance. Moreover, reasonable commercial good faith efforts will be made to inform registrars about possible upcoming planned outages within a 30-day advance schedule. * 7) CORE++ will provide a Whois service with a maximum update delay of 10 minutes. Registrars will be notified in advance in case of changes to the Whois service update schedule. * 8) CORE++ will allow external monitoring of the SRS via means acceptable for both the registrar and CORE++. * 9) CORE++ will perform a near-real time update of its name servers. The results of an RRP/EPP write operations shall be visible on the .net name servers no later than 15 minutes after the completion of the operation. Registrars will be notified in advance in case of changes to this mode of operation. Notifications will also be sent to announce scheduled maintenances and unavailabilities of the .net name servers. * 10) In the event of a force majeure, CORE++ will use commercial reasonable efforts to restore the critical parts of the SRS within 24 hours and to restore full system functionality within 48 hours. Outages caused by a force majeure will not be considered as SRS unavailability in terms of this SLA. * 11) CORE++ agrees to deliver weekly system performance and availability reports. These reports will provide average round trip for the RRP/EPP "check" and "add" rsp. "create" domain commands for all registrars and information on the availability of the SRS during the previous week. * 12) CORE++ will provide an SRS availability of 99.45% during each monthly timeframe. C) Credits: Should the SRS availability drop below 99.45% in any monthly timeframe, CORE++ will grant a credit to affected registrars who have complied with Sections B.1 and B.5 above as follows: * (i) If an SRS unavailability as described in A.4.b occurred, a credit will be given for the combined % total RRP "add", EPP "create" and RRP/EPP "check" commands dropping below the denoted 95% performance threshold. For each affected registrar, the credit will be determined by multiplying the % below 95% by the registrar's monthly add/create domain volume times the average initial registration price charged to that registrar during the month. The maximum credit granted to each registrar shall not exceed 5% of the registrar's total monthly add/create domain volume times that average registration price. * (ii) If an SRS unavailability as described in A.4.a occurred, CORE++ will grant a credit to the registrar by multiplying the registrar's monthly add/create domain volume (based on the monthly timeframe when the unplanned outage began) 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.55% of the monthly timeframe. The maximum credit given to each registrar in this context shall not exceed 10% of the registrar's total monthly add/create domain volume times the charged average registration price. Under no circumstances will credits be granted due to availability problems caused by network providers and/or the systems of individual registrars.

CORE++ operates an information service where data about domains, contacts, hosts and registrars can be inquired by the public, generally known as "Whois" service. This information service is provided via the "Whois" protocol on TCP port 43 as well as via a web interface. However, CORE++ sees the future in the CRISP/IRIS protocols. They represent the latest attempt -- after RWhois (RFC 2167) and Whois++ (RFCs 1834, 1835, 1913, 1914, 2957, 2958) -- to overcome the many disadvantages of the aged Whois, initially described in RFC 812 and updated in RFC 3912 at last. A testbed implementation during draft status will be provided within the first half year after the start of the registry operation and a final implementation no later than half a year after the drafts have been declared as standards. General Whois Design All instances of the Whois service operate on their own databases. This ensures a load decoupling between the registry and the Whois servers. The database of a Whois server is continuously synchronized with the registry's database via a VPN connection. As soon as changes to the registry's database have been made persistent, these changes are forwarded to all Whois servers. The Whois servers update their own databases with the data and provide the new information to the public. That way, changes to the registry will become visible on the Whois server typically in less than a minute. In case of a communication problem or a maintenance of the Whois server, changes that occurred since the last successful update are automatically identified and transferred. All implementations provide means to prevent excessive use by a single entity ("hammering" or data mining) in addition to general security precautions (e.g. DoS attacks). Port 43 Service As mentioned, the Whois protocol on port 43 is provided, as defined in RFC 3912. Unfortunately, the protocol, with its original roots in the year 1982, defines only the basic exchange between client and server. Any specification of input and output formats are left out. This has led to a large number of different output formats among the domain registries, and, due to the thin registry model, among the registrars also. CORE++ does not believe in the need for another new format. Therefore, resemblances of the input and output formats of the service to existing Whois services are not by accident, but intentional. The format is chosen by the "best current practice" and orientates itself on the needs of both human beings and automated processing: Simple key-value pairs instead of a beautifully formatted, but unparsable and not associatable representation, unequivocal keys and systematic grouping. In fact, it is an extended implementation of the Appendix O of the .org agreement with some clarifications. Another aspect is internationalization. The registry supports so-called "localized" address fields for contacts in addition to "internationalized" data (see also RFC 3733). These fields may contain non-US-ASCII characters. Also, the internationalized domain names (IDN) allow the use of non-US-ASCII characters. To support transmission of such characters, an option exists that specifies an alternative character set which should be used instead of the default US-ASCII character set. Input Format Specification The input to the Whois server consists of two parts: the options and the query itself. The following options are available: * the -C option allows to specify the character set for both input and output * the -L option selects the "localized" data in addition to the "internationalized" data of a contact, if available If the -C option is specified, the Whois server expects a character set name as the next token. The name must correspond to one of the IANA character set names. Only a limited set of character sets is supported by the server. It can be determined with the HELP query described below. At least US-ASCII and UTF-8 are supported. If the specified character set is supported, the server tries to reinterpret the octet sequence that has been sent as input via this character set. If it succeeds, it continues processing, otherwise, an error response is generated. The use of this option does not guarantee in general that all characters that are intended to be sent to the client can properly be represented. If during the conversion of the output to the specified character set a character is found that cannot be represented, it is replaced with a question mark. In addition, a comment is added to the output that notifies the recipient of the response about this problem. Only the Unicode-based character encodings are capable of representing all possible characters. The registry fully supports the use of so-called "localized" and "internationalized" data for contacts (see also EPP Contact Mapping, RFC 3733). In the "international" version of the data, only characters from the US-ASCII subset of Unicode may be used. As this basic set of Latin characters is known worldwide, even in regions where other scripting systems are used, this representation of contact data is considered suitable for international interchange. In contrast to this, the "localized" version may contain any valid Unicode character, including those that are not recognized outside the region where the address is located. While the "international" version is mandatory, the "localized" version is optional. With the -L option, the client can influence which data is returned on queries. By default, always the "international" version is returned. If the option is used, the "localized" version is returned in addition to the "international" version, if it exists. To differentiate between the two versions, different keys are used (also see below). By default, the Whois service searches for domain names. By the following keywords, the search type can be determined: Keywords (case insensitive) | Type -----------------------------|--------------------------------- do, domain | Search for domain objects. | Either the "Domain Name", | "Domain Name ACE" or | "Domain ID" field is used -----------------------------|--------------------------------- ho, host | Search for name server objects. | Either the "Host Name", | "Host Name ACE" or the "Host ID" | field is used -----------------------------|--------------------------------- contact | Search for contact objects in | the "Contact ID" field -----------------------------|--------------------------------- registrar | Search for registrar objects | in the "Registrar ID" or | "Registrar Organization" field In addition, the following search options are available: Keywords (case insensitive) | Option -----------------------------|------------------------------------------------ id | Search is performed in the respective ID field -----------------------------|------------------------------------------------ ace | Search is performed in the respective ACE field In general, domain names in the input are considered as being Internationalized Domain Names (IDNs, as defined in section 2, "Terminology", RFC 3490). By using the ace option, a given domain name is considered as being an ACE domain name. The use of the option does not have an influence on the response. The output can be controlled by the following keywords: Keywords (case insensitive) | Option -----------------------------|------------------------------------------------ =, full | Always return the complete data, | even if multiple entries are found -----------------------------|------------------------------------------------ sum, summary | Always return summarized data, | even if only a single entry is found The last token in the input is taken as the search parameter. It may contain the percent sign (`%') as a wild card for any number (including zero) of characters or the underline character (`_') for a single character. The wild card characters may not appear within the first three characters. If more than one matching object is found, a summary report is returned by default. This behavior can be modified by the options above. The number of objects returned is limited to 50, both for data mining prevention and resource protection. Wild cards cannot be used for ID searches. If the search parameter is "help" and no object type is given, no search is performed, but a short summary about the input format is returned. Output Format Specification The results of the query are encoded using either the US-ASCII character set or, if a valid character set has been specified via the -C option, the selected character set. If the output contains characters for which no encoding does exist, they are replaced with a question mark and a respective warning comment is added to the beginning of the output: % WARNING: THIS RESPONSE IS NOT AUTHENTIC % % The selected character encoding "XXX" is not able to % represent all characters in this output. Those % characters that could not be represented have been % replaced with "?". Please resubmit your query with a % suitable character encoding in order to receive an % authentic response. % All lines are terminated by CR/LF pairs. Lines that contain comments, legal notes or similar, start with a percent sign (`%'). If the output consists of multiple objects, they are separated by at least one empty line. The objects themselves (including the related subobjects, like referenced contacts of a domain) do not contain empty lines. If no objects match the search query, "NOT FOUND" is returned. The object data is composed of multiple key-value lines. Key and value of a key-value pair are separated by a colon (`:'). The key may contain space characters. For domain names that appear in the output, both the IDN version and the ACE version are supplied, even if the IDN consists of LDH characters only and is identical to the ACE representation. This applies to names of domains and hosts as well as name server references in domains. It does not apply to e-mail addresses (which contain domain names as part of the address) in the contact data and to the Whois referral field that is supplied for domains that are registered using the thin registry model. Example: ... Domain Name: grün.net Domain Name ACE: xn--grn-ioa.net ... Name Server: blau.example.net 192.0.2.1 Name Server: grün.example.net 192.0.2.2 Name Server ACE: blau.example.net 192.0.2.1 Name Server ACE: xn--grn-ioa.example.net 192.0.2.2 ... If the output contains contacts that contain localized data and the -L option has been specified, a second set of address data is included. It contains the same keys, but preceded by "Local ": The text is inserted after the role, if the contact appears in a different object. Example: ... Admin ID: C394583 Admin Name: Francois Debreuil Admin Organization: Admin Street: 45, Rue de la Ville l'Eveque Admin City: Orleans Admin State/Province: Centre Admin Postal Code: 45000 Admin Country: FR Admin Local Name: François Debreuil Admin Local Organization: Admin Local Street: 45, Rue de la Ville l'Évêque Admin Local City: Orléans Admin Local State/Province: Centre Admin Local Postal Code: 45000 Admin Local Country: FR Admin Phone: +33.12345678 Admin Phone Ext: Admin Fax: +33.87654321 Admin Fax Ext: Admin Email: francois.debreuil@example.net ... In the thin registry model, the registry does not maintain and is not authoritative for the contact data of the domains. Instead, this is the duty of the registrar. As a consequence, the Whois service cannot provide this information. To enable the client to retrieve that data easily, additional information about the registrar (that is part of the registrar object) are provided instead. Example: ... Registrar ID: IANA-15 Registrar Name: CORE Internet Council of Registrars Registrar Whois Server: whois.core.info Registrar URL: http://www.corenic.net ... Domain Data Format Depending on the query and options, either a short or a long format is produced. Short format: Domain ID: D38482 Domain Name: example.net Domain Name ACE: example.net Long Format (thick registry): Domain ID: D38482 Domain Name: core-plusplus.net Domain Name ACE: core-plusplus.net Domain Language: en Registrar ID: IANA-15 Created On: 2001-07-23 17:53:02 GMT Last Updated On: 2002-11-01 09:21:47 GMT Expiration Date: 2005-07-23 17:53:02 GMT Status: ok Registrant ID: C343238 Registrant Name: CORE Internet Council Of Registrars Registrant Organization: CORE Internet Council Of Registrars Registrant Street: WTC II, 29 route de Pre-Bois Registrant City: Geneva Registrant State/Province: Geneva Registrant Postal Code: 1215 Registrant Country: CH Registrant Phone: +41.229295744 Registrant Phone Ext: Registrant Fax: +41.229295745 Registrant Fax Ext: Registrant Email: secretariat@corenic.org Admin ID: C343238 Admin Name: CORE Internet Council Of Registrars Admin Organization: CORE Internet Council Of Registrars Admin Street: WTC II, 29 route de Pre-Bois Admin City: Geneva Admin State/Province: Geneva Admin Postal Code: 1215 Admin Country: CH Admin Phone: +41.229295744 Admin Phone Ext: Admin Fax: +41.229295745 Admin Fax Ext: Admin Email: secretariat@corenic.org Tech ID: C343238 Tech Name: CORE Internet Council Of Registrars Tech Organization: CORE Internet Council Of Registrars Tech Street: WTC II, 29 route de Pre-Bois Tech City: Geneva Tech State/Province: Geneva Tech Postal Code: 1215 Tech Country: CH Tech Phone: +41.229295744 Tech Phone Ext: Tech Fax: +41.229295745 Tech Fax Ext: Tech Email: secretariat@corenic.org Billing ID: C343238 Billing Name: CORE Internet Council Of Registrars Billing Organization: CORE Internet Council Of Registrars Billing Street: WTC II, 29 route de Pre-Bois Billing City: Geneva Billing State/Province: Geneva Billing Postal Code: 1215 Billing Country: CH Billing Phone: +41.229295744 Billing Phone Ext: Billing Fax: +41.229295745 Billing Fax Ext: Billing Email: secretariat@corenic.org Name Server: ns1.core-plusplus.net 192.0.2.1 Name Server: ns2.core-plusplus.net 192.0.2.2 Name Server ACE: ns1.core-plusplus.net 192.0.2.1 Name Server ACE: ns2.core-plusplus.net 192.0.2.2 Regarding the included contact data, see below also. Long format (thin registry): Domain ID: D38482 Domain Name: core-plusplus.net Domain Name ACE: core-plusplus.net Domain Language: en Registrar ID: IANA-15 Registrar Name: CORE Internet Council of Registrars Registrar Whois Server: whois.core.info Registrar URL: http://www.corenic.net Created On: 2001-07-23 17:53:02 GMT Last Updated On: 2002-11-01 09:21:47 GMT Expiration Date: 2005-07-23 17:53:02 GMT Status: ok Name Server: ns1.core-plusplus.net 192.0.2.1 Name Server: ns2.core-plusplus.net 192.0.2.2 Name Server ACE: ns1.core-plusplus.net 192.0.2.1 Name Server ACE: ns2.core-plusplus.net 192.0.2.2 In case that the domain is in the auction phase (see 2.3.(a) for details), the following format is used: Domain ID: D38482 Domain Name: example.net Domain Name ACE: example.net Domain Language: en Status: pendingAuction Bid Due Date: 2005-07-23 17:53:02 GMT Host Data Format Short Format: Host ID: H38473 Host Name: ns3.core-plusplus.net Host Name ACE: ns3.core-plusplus.net Long format: Host ID: H38473 Host Name: ns3.core-plusplus.net Host Name ACE: ns3.core-plusplus.net Registrar ID: IANA-15 Created On: 2001-07-23 17:53:02 GMT Last Updated On: 2002-11-01 09:21:47 GMT Status: ok IP Address: 192.0.2.3 IP Address: 3FFE:3273:1002::FE99:3BC7 Contact Data Format Short format, without localized data: Contact ID: C394583 Name: Francois Debreuil Short format, with localized data: Contact ID: C394583 Name: Francois Debreuil Local Name: François Debreuil Full format, without localized data: Contact ID: C394583 Status: ok Name: Francois Debreuil Organization: Street: 45, Rue de la Ville l'Eveque City: Orleans State/Province: Centre Postal Code: 45000 Country: FR Phone: +33.12345678 Phone Ext: Fax: +33.87654321 Fax Ext: Email: francois.debreuil@example.net Full format, with localized data: Contact ID: C394583 Status: ok Name: Francois Debreuil Organization: Street: 45, Rue de la Ville l'Eveque City: Orleans State/Province: Centre Postal Code: 45000 Country: FR Local Name: François Debreuil Local Organization: Local Street: 45, Rue de la Ville l'Évêque Local City: Orléans Local State/Province: Centre Local Postal Code: 45000 Local Country: FR Phone: +33.12345678 Phone Ext: Fax: +33.87654321 Fax Ext: Email: francois.debreuil@example.net The actual published data depends on the registry policy and the contact's disclosure settings (see RFC 3733). If data is not disclosed, the respective key- value pair is omitted. In contrast, empty fields (like the organization in the given example), are included. This allows the client to differentiate between the two cases. Registrar Data Format Registrar ID: IANA-15 Status: ok Organization: CORE Internet Council Of Registrars Street: WTC II, 29 route de Pre-Bois City: Geneva State/Province: Geneva Postal Code: 1215 Country: CH Phone: +41.229295744 Phone Ext: Fax: +41.229295745 Fax Ext: Email: secretariat@corenic.org Whois Server: whois.core.info URL: http://www.corenic.net For ICANN-accredited registrars, the registrar ID is composed of the prefix "IANA-" and the registrar ID as specified in the registrar list maintained by IANA (http://www.iana.org/assignments/registrar-ids). Other administrative accounts operated by the registry use a different prefix. Web Whois Service The web Whois service shares the same functionality as the port 43 service, with the exception that the input is implemented by using the means of HTML, i.e. by text input fields, radio buttons and check boxes. The output format is the same as described above. It is included in the HTML page in a way that it easily can be copied by common browsers. To support the input and output of non-US-ASCII characters, the service operates using the UTF-8 encoding.

CORE++ agrees to provide bulk access to Whois data, as described in the appendix P of the .org registry agreement, dated 2002-10-23. It is recommended to review the exact technical details of the agreement and to adjust them to the different conditions of the proposed .net registry. Especially various aspects of the XML document type definition (DTD) need to updated; * as the thin model is also supported, the specification of the registrant and administrative, technical and billing contacts should be made optional * the status and country code (cc) attributes should be changed to NMTOKENS/CDATA to be more forward compatible * the registrar element should be updated to reflect the data structure that is proposed for the Whois service * the TLD attribute should be changed to CDATA to allow other TLDs than "org" * to promote homogeneous nomenclature, it is suggested to rename "nameserver" to "host", except where the host is referenced as a name server in the domain. * The contact data should also carry the local data. There are no changes required for IDN. As XML is fully Unicode compatible, it is not a problem to include IDNs in the respective name fields of domains and hosts. Other services, like DNSSEC, auction service or the protected registration service do not add additional fields to the XML Whois output. <!ELEMENT whois-data (domain | del-domain | host | del-host | contact | del-contact | registrar | del-registrar)*> <!ATTLIST whois-data tld NMTOKEN #REQUIRED date CDATA #REQUIRED type (full | incremental) #REQUIRED version CDATA #FIXED "1.1" > <!ELEMENT domain (domainname)> <!ATTLIST domain dom-id NMTOKEN #REQUIRED registrar-id NMTOKEN #IMPLIED admin-id NMTOKEN #IMPLIED tech-id NMTOKEN #IMPLIED billing-id NMTOKEN #IMPLIED nameserver-ids NMTOKENS #IMPLIED status NMTOKENS #IMPLIED cre-date CDATA #REQUIRED exp-date CDATA #REQUIRED upd-date CDATA #REQUIRED > <!ELEMENT del-domain EMPTY> <!ATTLIST del-domain dom-id NMTOKEN #REQUIRED > <!ELEMENT host (domainname, ip*)> <!ATTLIST host host-id NMTOKEN #REQUIRED registrar-id NMTOKEN #REQUIRED status NMTOKENS #IMPLIED cre-date CDATA #REQUIRED upd-date CDATA #REQUIRED > <!ELEMENT del-host EMPTY> <!ATTLIST del-host host-id NMTOKEN #REQUIRED > <!ELEMENT contact (addr, addr?, phone, fax, e-mail)> <!ATTLIST contact contact-id NMTOKEN #REQUIRED registrar-id NMTOKEN #REQUIRED status NMTOKENS #IMPLIED cre-date CDATA #REQUIRED upd-date CDATA #REQUIRED > <!ELEMENT del-contact EMPTY> <!ATTLIST del-contact contact-id NMTOKEN #REQUIRED > <!ELEMENT registrar (org, street, street?, street?, city, state, post-code, country-code, phone, fax, e-mail, whois, url)> <!ATTLIST registrar registrar-id NMTOKEN #REQUIRED status NMTOKENS #IMPLIED cre-date CDATA #REQUIRED upd-date CDATA #REQUIRED > <!ELEMENT del-registrar EMPTY> <!ATTLIST del-registrar registrar-id NMTOKEN #REQUIRED > <!ELEMENT domainname (#PCDATA)> <!ELEMENT ip (#PCDATA)> <!ELEMENT addr (name, org, street, street?, street?, city, state, post-code, country-code)> <!ATTLIST addr type (intl | local) "intl" > <!ELEMENT name (#PCDATA)> <!ELEMENT org (#PCDATA)&