TOP   THE .ORG TLD IS A PUBLIC TRUST  » 
« A Joint Effort of the INTERNET MULTICASTING SERVICE and INTERNET SOFTWARE CONSORTIUM »
TRANSMITTAL »FITNESS DISCLOSURE » « VOICE YOUR SUPPORT »
PROPOSAL »SUPPLEMENTARY MATERIALS » « SPREAD THE DOT »
CONFIDENTIAL INFORMATION »SUPPLEMENTAL QUESTIONS »


.org Proposal Form 

Executive Summary

This is a joint bid between the Internet Multicasting Service (IMS) and the Internet Software Consortium (ISC). We are both public benefit corporations with a long history of operating public works and creating freely available software for key infrastructure services on the Internet.

The .org Top Level Domain (TLD) is the home for the noncommercial organizations of the world, and we would operate the .org registry service as a public trust:

IMS and ISC have provided important contributions to Internet infrastructure and have worked together closely for years. Our team is in place and builds on substantial past experience:

Revenue generated from the operation of the registry will first cover core operations, then service debt, and then fund public works projects for the benefit of .org registrants and core Internet infrastructure. No funds will be used for unrelated programs and we have no shareholders. An experienced board of directors, a public process, and extensive reporting will provide full accountability and transparency for the operation of this registry.

We will provide ICANN with tools that will spur greater competition in the marketplace for registry services and support innovation in related areas.


Table of Contents

1.  General Information About the Applicant  
2.  Statement of Capabilities of the Applicant and Contracted Service Providers  
2.1  Outsourcing  C12 
2.2  Services and Facilities  C13 
2.3  Scope and Terms of Contracts  C14 
2.4  Abilities of the Applicant  C15 
3.  Technical Plan (Including Transition Plan)  
3.1  Summary  
3.2  General Description of Proposed Facilities and Systems C17.1 
3.2.1  Functional Specification  
3.2.1.1  Provision of Services  
3.2.1.2  Transaction Security  
3.2.1.3  Active Service Monitoring  
3.2.1.4  Event Monitoring  
3.3  Registry-Registrar Model and Protocol  C17.2 
3.3.1  General Approach  
3.3.2  RRP Implementation  
3.3.3  EPP Implementation  
3.3.4  Message Passing to Registrars  
3.3.5  Registrar Portal  
3.4  Database Capabilities  C17.3 
3.5  Zone File Generation  C17.4 
3.5.1  A Note on TSIG and DNSSEC  
3.6  Zone File Distribution and Publication  C17.5 
3.7  Billing and Collection Systems  C17.6 
3.8  Data Escrow and Backup  C17.7 
3.8.1  Requirements  
3.8.2  Data Escrow Schedule, Content, Format and Procedure  
3.8.2.1  Schedule  
3.8.2.2  File Naming  
3.8.2.3  Escrow Deposit Specification  
3.8.2.4  Dump Format  
3.8.2.5  Deposit and Transfer  
3.8.2.6  Verification Procedures  
3.8.3  Backup Provisions  
3.9  Whois Services  C17.8 
3.10  System Security  C17.9 
3.10.1  Types of Services  
3.10.1.1  Public Services  
3.10.1.2  Restricted services  
3.10.1.3  Private services  
3.10.2  Types of Attacks  
3.10.2.1  Denial of Service  
3.10.2.2  Intrusion  
3.10.2.3  General and Physical  
3.11  Peak Capacities  C17.10 
3.12  Customer Support  C17.11 
3.12.1  Incident Handling  
3.12.2  Notifications  
3.12.3  Maintenance  
3.12.4  Change Control  
3.12.5  Questions/Help  
3.12.6  Staffing  
3.13  Compliance with Specifications  C17.12 
3.14  System Reliability  C17.13 
3.14.1  Definitions  
3.14.2  Notification  
3.14.3  Performance Metrics  
3.14.4  Nameserver Availability and Performance Measurements  
3.14.5  Update Frequency  
3.14.6  Performance Specification Summary  
3.15  System Outage Prevention  C17.14 
3.16  System Recovery Procedures  C17.15 
3.16.1  Recovery From Hardware Failure  
3.16.2  Recovery From Software Failure  
3.16.3  Recovery From Operational Failure  
3.16.4  Customer Service  
3.17  Registry Failure Provisions  C17.16 
3.17.1  Operational Failure  
3.17.2  Business Failure  
3.17.3  Regulatory Failure  
3.18  Transition Plan  C18 
3.18.1  Steps of Proposed Transition  C18.1 
3.18.1.1  August/September 2002  
3.18.1.2  September/November 2002  
3.18.1.2.1  Implementation of RRP and EPP  
3.18.1.2.2  Whois Service  
3.18.1.2.3  Zone File Generation  
3.18.1.2.4  Operational Planning  
3.18.1.3  Final Cutover Preparation  
3.18.1.4  Live Cutover Acceptance Criteria  
3.18.1.5  RRP/EPP and Thin/Thick Transition  
3.18.1.6  Phase I - Stable Transition  
3.18.1.7  Phase I - Transfers  
3.18.1.8  Phase I - Deleted Domains  
3.18.1.9  Phase II - Dual Protocol Support (RRP and EPP)  
3.18.1.10  Phase II - Transfers  
3.18.1.11  Phase III - From Thin to Thick  
3.18.1.12  Phase IV - Complete Thick/Thin Transition  
3.18.2  DNS Server Service Assimilation  
3.18.3  IDN Transmigration  
3.18.4  Whois Redirection from VeriSign  
3.18.5  IP Version 6 Support  
3.18.6  Community Notification and Outreach  
3.19  Interruption of the Registry Function  C18.2 
3.20  Contingency Plans  C18.3 
3.21  Effect on .org Registrants and Internet Users  C18.4 
3.22  Specific Cooperation Required from VeriSign  C18.5 
3.23  Relevant Prior Transition Experience  C18.6 
3.24  Proposed Criteria for the Evaluation of Transition  C18.7 
4.  Compliance with ICANN-Developed Policies and the Registry Agreement  C19 
5.  Provisions for Equivalent Access by Accredited Registrars  C20 
5.1  Equivalent Access Policies  C21 
5.1.1  Equivalent Access Policy  
5.1.2  Registry Code of Conduct  
5.2  EPP Support  C22 
5.2.1  EPP Transition  
6.  Proposed Registry Services  
6.1  Registry Services for Fee  C25 
6.2  Maximum Price  C26 
6.3  Registry Services Without Fee  C27 
6.4  Technical Performance Specifications  C28 
6.4.1  Performance Specifications  
6.4.2  Update Frequency  
6.4.3  Cross-Network Nameserver Performance Requirements  
7.  Enhancement of Competition  C30 
8.  Responsiveness to the Noncommercial Internet User Community  
9.  Support for Proposal  C36 
10.  Differentiation of the .org TLD  C38 
11.  The VeriSign Endowment  C40
12.  Supporting Documentation  C50 
13.  Signature and Certification  
§  Normative References  
§  Select RFCs By Team Members  
§  Current Internet-Drafts by Team Members  
§  Books by Team Members  
§  Web Sites by Team Members  
§  Authors' Addresses  
A.  Escrow Data Format  
A.1  Domain Format  
A.2  Name Server Format  
A.3  Registrar Format  
A.4  Contact Format  
A.5  Escrow Format Example  
B.  Registry/Registrar E-Mail Templates  
B.1  Receipt of Transfer Request  
B.2  Completion of Transfer Request  
B.3  Auto-Acknowledgement of Transfer Request  
B.4  Non-Completion of Transfer Request  
C.  Initial Whois Output Format  
D.  Thick Record Whois Output Format  
E.  Biographies of Key Personnel  
E.1  Program Managers  
E.1.1  Carl Malamud  
E.1.2  Rebecca Malamud  
E.1.3  Paul Vixie  
E.1.4  Suzanne Woolf  
E.2  Additional Personnel  
E.2.1  Joe Abley  
E.2.2  Luther Brown  
E.2.3  Brad Burdick  
E.2.4  Michael Graff  
E.2.5  Lynda McGinley  
E.2.6  Rick H. Wesson  
E.3  Board Members  
E.3.1  Rick Adams  
E.3.2  Dave Farber  
E.3.3  Teus Hagen  
E.3.4  Daniel Karrenberg  
E.3.5  Carl Malamud  
E.3.6  Rebecca Malamud  
E.3.7  Evi Nemeth  
E.3.8  Marshall T. Rose  
E.3.9  Paul Vixie  
E.3.10  Stephen Wolff  
E.3.11  Pindar Wong  
F.  Document Formats   DOC  



 TOC 

1. General Information About the Applicant
 ? 
C1. The first section of the .org Proposal (after the signed copy of this document) covers general information about the applicant. Please key your responses to the designators (C2, C3, C4, etc.) below.

C2. The full legal name, principal address, telephone and fax numbers, and e-mail address of the applicant, and the URL of its principal World Wide Web site.

Internet Multicasting Service, Inc.
P.O. Box 217
Stewarts Point, CA 95480
United States
Email: carl@media.org
Phone: +1.707.847.3720
Facsimile: +1.415.680.1556
URI: http://not.invisible.net/

Our partner in this application is:

Internet Software Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
United States
Email: paul@isc.org
Facsimile: +1.650.779.7055
Phone: +1.650.779.7000
URI: http://www.isc.org

 ? 
C3. A general description of the applicant's business and other activities.

The Internet Multicasting Service is a not-for-profit, public-benefit corporation that conceives and implements large public works projects and new services on the Internet for the benefit of the general public:

The Internet Software Consortium is a not-for-profit, public-benefit corporation that produces core software and operates core infrastructure for the benefit of the general public:

From 1993 to 1997, ISC was under the fiscal sponsorship of the Internet Multicasting Service. ISC was incorporated in 1997 and began accepting funds in 1998.

 ? 
C4. The applicant's type of entity (e.g., corporation, partnership, etc.) and law (e.g., Denmark) under which it is organized. Please state whether the applicant is for-profit or non-profit. If it is non-profit, please provide a detailed statement of its mission.

The Internet Multicasting Service (IMS) is a Delaware Corporation (File 2335603) chartered in 1993. The Federal Employer ID of IMS is 52-1827912. IMS was classified as a 501(c)(3) non-profit in 1993 by the IRS and received a final 5-year 501(c)(3) ruling in 1998. IMS is registered in the State of California as corporation number C2369286 and has been granted exemption from state franchise and income taxes under section 23701(d) of the California Revenue and Taxation Code. IMS is a non-profit public benefit corporation and is not organized for the private gain of any person. The charter of the Internet Multicasting Service is "the creation and operation of public works on the global Internet computer network, including the creation and operation of new services, multimedia content and database, and network protocols for the benefit of the general public and the public Internet infrastructure."

The Internet Software Consortium is registered in the State of California as corporation number C2063422. ISC is a non-profit public benefit corporation and is not organized for the private gain of any person. The specific purpose of the ISC is "supporting the development of freely-available computer software programs which implement core Internet protocols and standards."

 ? 
C5. Dun & Bradstreet D-U-N-S Number (if any) of the applicant.

The D-U-N-S Number for the Internet Multicasting Service is 82-508-2589.

The D-U-N-S Number for the Internet Software Consortium is 02-368-9651.

 ? 
C6. The number of employees currently employed by the applicant.

IMS pays 3.5 Full Time Equivalent employees and has additional contractors and volunteers.

ISC pays 6.3 Full Time Equivalent employees and has additional contractors and volunteers.

 ? 
C7. The applicant's total revenue (in US dollars) in the last-ended fiscal year. 

     IMS Total Revenues 
       (US Dollars)

    Year         Amount
    ====     ==========
    1993       $316,550
    1994       $801,191
    1995       $939,733
    1996       $831,785
    1997       $147,307
    1998       $300,447
    1999         $3,300
    2000         $1,686
    2001        $80,183
    2002       $500,104 (YTD)

    ISC Total Revenues
       (US Dollars)

    Year         Amount
    ====     ==========
    1998       $629,684
    1999     $1,724,715
    2000       $684,614
    2001     $1,301,141
    2002        $68,208 (YTD)
 ? 
C8. Full names and positions of (i) all directors, (ii) all officers, (iii) all relevant managers, and (iv) any persons or entities owning five percent or more of the applicant.

The directors of the Internet Multicasting Service are Rick Adams, Dave Farber, Daniel Karrenberg, Carl Malamud, Rebecca Malamud, Marshall T. Rose, and Pindar Wong.

The officers of the Internet Multicasting Service are Carl Malamud and Rebecca Malamud. They will be the program managers for the .org program.

The directors of the Internet Software Consortium are Teus Hagen, Evi Nemeth, Paul Vixie, and Stephen Wolff.

The officers of the Internet Software Consortium are Paul Vixie, and Lynda McGinley. The program managers for the .org program will be Paul Vixie and Suzanne Woolf.

Neither IMS nor ISC have any stockholders. Both are public benefit corporations.

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

Carl Malamud (carl@media.org)
Internet Multicasting Service, Inc.
P.O. Box 217
Stewarts Point, CA 95480
United States
Phone: +1.707.847.3720
Facsimile: +1.415.680.1556
URI: http://not.invisible.net/

C10. Intentionally omitted.


 TOC 

2. Statement of Capabilities of the Applicant and Contracted Service Providers
 ? 
C11. As stated in the Criteria for Assessing Proposals, "ICANN's first priority is to preserve the stability of the Internet" and "ICANN will place significant emphasis on the demonstrated ability of the applicant or a member of the proposing team to operate a TLD registry of significant scale in a manner that provides affordable services with a high degree of service responsiveness and reliability." This section of the .org Proposal offers the applicant the opportunity to demonstrate its ability to operate the .org registry in that manner.

Throughout this document, operation of the .org registry, including providing all associated Registry Services, as defined in subsection 1.16 of the model .org Registry Agreement, is referred to as the "Registry Function."

2.1 [C12] Outsourcing
 ? 
C12. State whether the applicant intends to perform all aspects of the Registry Function, or whether the applicant intends to outsource some or all aspects of the Registry Function to other entities that will provide services or facilities under contract with the applicant. If any portion(s) of the services or facilities will be provided by another entity under contract, please describe which portion(s), state the time period during which they will be provided under contract, and identify what entity will be providing the services or facilities.

We will not outsource any of the functions listed above. To provide a single point of accountability for ICANN, the Internet Multicasting Service will serve as prime contractor. However, as evidenced in the attached Joint Statement of Authority, and by our long history of working together, this should be considered a joint bid between two established non-profit organizations.

2.2 [C13] Services and Facilities
 ? 
C13. Identify by name each entity other than the applicant that will provide any of the following:
  • all services and facilities used to perform the Registry Function;
  • any portion of the services and facilities used to perform the Registry Function accounting for 10% or more of overall costs of the Registry Function; or
  • any portion of any of the services and facilities used to perform the following parts of the Registry Function accounting for 25% or more of overall costs of the part: database operation, zone file generation, zone file distribution and publication, billing and collection, data escrow and backup, customer (registrar) support, and Whois service.

Applicant will perform all functions. Note, however, [C18.5] Specific Cooperation Required from VeriSign

2.3 [C14] Scope and Terms of Contracts
 ? 
C14. For each entity identified in item C13, please state the scope and terms of the contract under which the facilities or services will be provided and attach documentary evidence that the entity has committed to enter into that contract.

As stated in [C13] Services and Facilities, applicant will perform all such functions.

2.4 [C15] Abilities of the Applicant
 ? 
C15. Describe in detail the abilities of the applicant and the entities identified in item C13 to operate a TLD registry of significant scale in a manner that provides affordable services with a high degree of service responsiveness and reliability. Your response should give specifics, including significant past or present achievements and activities of the applicant and the entities identified in item C13 that demonstrate the described abilities. It should also include information about key technical personnel (qualifications and experience), size of technical workforce, and access to systems development tools.

Our ability to operate a TLD registry of significant scale is based on:

Specifically:

The services we build and operate require very high degrees of stability, performance, in a highly complex operating environment.

We are used to serving many constituencies. In addition to our experience working with software developers and operators around the world, we have worked with many kinds of communities and stakeholders.

Our team is well known for advancing the state of the art. We'll do that with the .org registry in particular and registries in general.

Our program managers have held senior management positions with full responsibility for large organizations in industry, government and public service:

The Internet is a global network and our team our team has extensive international experience:

Our team has the experience and ability to operate as a public trust a rock-solid and responsive .org registry service. We will help differentiate .org, making it a home for noncommercial organizations. All of our work will be freely available, spurring innovation and competition in the registry and registrar markets.


 TOC 

3. Technical Plan (Including Transition Plan)
 ? 
C16. The third section of the .org Proposal is a description of your technical plan. This section must include a comprehensive, professional-quality technical plan that provides a full description of the proposed technical solution for transitioning and operating all aspects of the Registry Function. The topics listed below are representative of the type of subjects that will be covered in the technical plan section of the .org Proposal.

C17. Technical plan for performing the Registry Function. This should present a comprehensive technical plan for performing the Registry Function. In addition to providing basic information concerning the proposed technical solution (with appropriate diagrams), this section offers the applicant an opportunity to demonstrate that it has carefully analyzed the technical requirements for performing the Registry Function. Factors that should be addressed in the technical plan include:

3.1 Summary

This technical plan for the design and implementation of the .org registry was constructed in accordance with the guidance provided by "gTLD Registry Best Practices" and the ".org Proposal Form". Additional detail required for implementation, but not requested specifically in the RFP has been separated from the main text for clarity, and is included in appendices.

The .org registry will initially be operated as a "thin" registry, but with a core registry schema that will accommodate both thin and thick registry models. We will implement a transition from the initial thin registry to a thick registry in conjunction with ICANN and the registrar community, as described in [C18] Transition Plan.

Our plan for initial deployment and transition of Shared Registration System (SRS) protocols is described in [C18] Transition Plan, and accommodates VeriSign's Extensible Provisioning Protocol (EPP) and Registry-Registrar Protocol (RPP) deployment plans to ensure that the impact on gTLD registrars is minimized.

Software created to operate the registry, including software which provides RRP and EPP client and server functionality, will be released under an open-source license and will be made available for use by other registries and by registrars.

All services will be designed where possible to be provided multilingually in languages chosen to best serve the registrar community. A strong support structure for registrars and other interested parties is provided.

3.2 [C17.1] General Description of Proposed Facilities and Systems
 ? 
C17.1. General description of proposed facilities and systems. Address all locations of systems. Provide diagrams of all of the systems operating at each location. Address the specific types of systems being used, their capacity, and their interoperability, general availability, and level of security. Describe buildings, hardware, software systems, environmental equipment, Internet connectivity, etc.

We will operate the .org registry on a dedicated technical and support infrastructure, including new hardware, separate co-location and bandwidth contracts, and a dedicated technical staff of 10-12 professionals in customer support, systems administration, and software development. The technical plan makes extensive use of the team's expertise in the design, implementation, and operation of advanced server systems and networks, highly available public services such as the DNS, custom network applications, and advanced performance monitoring.

The central site, housing customer support, management, and software development activities, will be at ISC's primary location in Redwood City, California. This location has abundant suitable space at preferred rates, the local availability of excellent Internet connectivity, and close proximity to the San Francisco Bay Area talent pool of trained, experienced technical personnel. Improvements to the property, primarily in HVAC, electrical capacity, and telecom, will support our customer support center, development and other activities, with room to grow as needed for relatively low cost.

The production sites that will be supporting services for registrars and the public will be located at well-known, well-connected Internet co-location facilities. In the first year, two production sites in addition to the central site in Redwood City will support .org. As loads stabilize and DNS for .org is transitioned away from VeriSign's servers and towards ours, additional satellite installations will be deployed in other strategic locations to improve reachability and performance.

In recognition of the volatility of the co-location and bandwidth markets at this time, final determinations have not been made as to the locations of the production servers. A number of facilities would meet our requirements, which include highest quality security and reliability, ample space, low-latency and high bandwidth transit facilities, and the availability of many large, well-connected peering partners. Initial locations will be on east and west coasts of the United States, with additional facilities at suitable locations in Europe, Asia, South America, and Africa, with specific locations determined by the best connectivity for the largest number of users and customers.

The major production sites will consist of systems dedicated to public information services, registrar services, and database services, along with a redundant pair of servers supplying non-Internet access for "out-of- band" management of the servers, routers, and switches via modem and serial connection. The HP Alphaservers specified are well-known for speed, high capacity, and reliability, and the model specified, DS20L, are significantly over-provisioned for the anticipated loads (see [C17.10] Peak Capacities). Tru64 is a UNIX variant that has been in production use for highly available network services for many years and is interoperable with any standards-compliant UNIX and standards-compliant network service.

  FIG 1    CONFIGURATION OF CORE PRODUCTION SITES 
        ,---------------.                     ,--------------.
        | Database      |                     | Public       |
    ,---+    Server     +---------,  ,--------+    Server    |
    |   +---------------+         |  |        +--------------+
    |   | Database      |         |  |        | Public       |
    | ,-+    Server     +-------, |  | ,------+    Server    |
    | | `---------------'       | |  | |      `--------------'
    | | ,---------------.       | |  | |
    | | |  RAID         |       | |  | |      ,--------------.
    | `-+    ARRAY      |       | |  | |      | Registrar    |
    `---+               |       | |  | | ,----+    Server    |
        `---------------'       | |  | | |    +--------------+
                                | |  | | |    | Registrar    |
      ,---------------.         | |  | | | ,--+    Server    |
      | Mgmt station  |         | |  | | | |  `--------------'
      |               +-------, | |  | | | |
      +---------------+       | | |  | | | |
      | Mgmt station  +-----, | | |  | | | |
      |               |     | | | |  | | | |
      `---------------'  ,--+-+-+-+--+-+-+-+--.
                         |       Switch       |
                         +--------------------+
        ,---------------.                     ,--------------.
        | Database      |                     | Public       |
    ,---+    Server     +---------,  ,--------+    Server    |
    |   +---------------+         |  |        +--------------+
    |   | Database      |         |  |        | Public       |
    | ,-+    Server     +-------, |  | ,------+    Server    |
    | | `---------------'       | |  | |      `--------------'
    | | ,---------------.       | |  | |
    | | |  RAID         |       | |  | |      ,--------------.
    | `-+    ARRAY      |       | |  | |      | Registrar    |
    `---+               |       | |  | | ,----+    Server    |
        `---------------'       | |  | | |    +--------------+
                                | |  | | |    | Registrar    |
      ,---------------.         | |  | | | ,--+    Server    |
      | Mgmt station  |         | |  | | | |  `--------------'
      |               +-------, | |  | | | |
      +---------------+       | | |  | | | |
      | Mgmt station  +-----, | | |  | | | |
      |               |     | | | |  | | | |
      `---------------'  ,--+-+-+-+--+-+-+-+--.
                         |       Switch       |
                         +--------------------+
                         |       Switch       |
                         `-----+--------+-----'
                               |        |
                           ,---+--------+---.
                        ,--+     Router     |
                        |  +----------------+
                        |  |     Router     +--,
                        |  `----------------'  |
                        |                      |
                        |                      |
                    ################################
                   #         Public Internet       ##
                   #  (via provider switch fabric) ##
                    ################################
 NOTES 
  1. Some redundancy is removed for clarity. In particular, the switches are fully redundant and each component shown as wired into one is wired into both.
  2. IP addressing and routing are not shown.
  3. Equipment is expected to stack into one rack including space for cable management and air circulation.
  4. Some specifics of out of band management stations are removed for clarity. Connectivity will include a modem for outside access and serial ports cabled to each major component.

High-availability features of the hardware specified include redundant power supplies, hot-swappable disk, redundant Ethernet ports with failover capabilities, dual connections from each server into fully redundant Ethernet switches, and dual connections from each switch into a fully redundant pair of routers configured for automatic failover between them. A dual power RAID5 store between the database servers provides for highly reliable disk capacity. The maintenance policy will provide for on-site spares for both disk and power supplies. In addition, we remove the chance that maintenance access to the installation could be cut off by a network failure of any kind by including a full "out-of-band management" kit of dedicated redundant servers. This provides the ability to dial in to the installation and reach any of the servers or network gear via a serial connection in the unlikely event that it's entirely unreachable via the network.

Support services specified to enhance the availability and reliability of each production installation includes support contracts on the hardware, "eyes and hands" contracts with the facilities where they are housed, and 24x7 on-call availability of server system and network specialists on staff.

Facilities for the production systems are specified as carrier-grade, including dual entrance for fiber providers, redundant power, high availability HVAC, and access control requiring biometric identification of visitors or escorted access.

Production software is specified as open source where possible, including well-known standards-compliant implementations of relational databases, DNS, systems monitoring and management, and secure access. Systems development will also be based on established open-source tools. (Additional detail on our software architecture and tools will be included in responses to follow.)

Network access is specified to include diverse Internet access from initial launch. The technical team's experience with the connectivity needs and strategies of ISPs have led to an architecture that makes extensive use of BGP peering with ISPs to improve reachability to far reaches of the Internet and to reduce the costs associated with paid transit.

3.2.1 Functional Specification

The .org registry has been designed and implemented using a component model, using documented and consistent APIs between modules which will allow individual components to undergo development, testing and upgrade with a substantial degree of independence from the system as a whole. This approach, combined with community review and participation through open-source licensing and publication of all components, will lead to an optimally stable and secure infrastructure.

3.2.1.1 Provision of Services
  FIG 2    SOFTWARE ARCHITECTURE 
                    ,--------------.                 ,-------------.
                    | IXFR, TSIG   +-----------------+ IXFR, TSIG  |
                    +--------------+                 +-------------+
                    |  Zone File   |                 | Auth Name-  |
                    |  Generation  |                 |  servers    |
                    +--------------+                 +-------------+
                    | dbase access |                 |    DNS      |
                    `------+-------'                 `-------------'
                           |
                    ,------+-------.                    ,--------------.
                    |   Registry   +--------------------+ dbase access |
        ,-----------+   Database   +--------------.     +--------------+
        |           |              +--------.      \    | transaction  |
        |           `------+-------'        |       \   |   engine     |
        |                  |                |        \  `----+---+-----'
,-------+-------.  ,------+-------. ,-------+------.  \      |   |
| dbase access  |  | dbase access | | dbase access | ,-+-----+---+---.
+---------------+  +--------------+ +--------------+ | dbase | trans |
| Query Service |  | Web Services | | Notification | +---------------+
+---------------+  +--------------+ |   Engine     | |      SRS      |
|     Whois     |  |  HTTP, HTTPS | +--------------+ `---------------'
`---------------'  `--------------' |    SMTP      |
                                    `--------------'
 NOTES 
  1. All registry data is stored in the registry database; transactions will not complete until positive confirmation of data commit has been obtained.
  2. The database access component provides a consistent access API to the registry database. Maintaining a clean functional boundary between the access layer and applications which need to manipulate data in the registry allows flexibility in the choice of database, which in turn makes the registry more scalable.
  3. The Whois component accepts Whois queries from clients, and performs read-only queries against the database in order to obtain data to return to clients. The Whois component will dynamically limit useful responses supplied to clients that present excessive query loads.
  4. The transaction engine processes requests that might effect changes in the registry database, in response to instructions received from the SRS components. A common interface layer is provided for the various SRS components to send requests to the transaction engine.
  5. The SRS components accept requests from clients over appropriate interactive transport protocols, and translates SRS-specific dialogues into interactions with the transaction engine. We expect the supported set of SRS protocols to include RRP and EPP, as described in [C18] Transition Plan. Where message-passing provisions are provided in the SRS protocol, the database access component will be used to provide access to SRS components to the registry (e.g., the EPP <poll> command; see Message Passing to Registrars.)
  6. Two web applications require access to the registry data:
    • Public Whois-type registry query tool.
    • Registrar portal.
    • Other applications may be developed which use the common web services framework.
  7. Zone file generation is described in [C17.4] Zone File Generation.
  8. Certain registry operations require the registry to send notifications to clients that are not associated with a client-initiated transaction request. The notification engine polls for such notifications in the database, and performs appropriate actions. E-mail is the initial notification mechanism supported (see Message Passing to Registrars).

3.2.1.2 Transaction Security

Periodic database dumps stored according to the general backup and data security policy will allow reconstruction of the registry database to be performed in the event of catastrophic failure. Additional facilities have been implemented to ensure that transactions performed against the database following a database dump can also be preserved, providing a mechanism to facilitate complete disaster recovery.



  FIG 3    TRANSACTION SECURITY 
,--------------.
| dbase access |
+--------------+      ,-------------.
| Transaction  +------+ Transaction |
|    Engine    |      |     Log     |
`--------------'      `-------------'
 NOTES 
  1. A simple, flat, textual log of every transaction processed by the Transaction Engine is maintained, such that all transactions successfully committed through the Database Access component are recorded. The Transaction Log will provide transaction security and, together with periodic database dumps, will allow accurate reconstruction of arbitrary snapshots of the registry database.
  2. The transaction log is deliberately implemented separately from the database and the database access components in order to safeguard against systematic defects in either of those modules.

3.2.1.3 Active Service Monitoring
  FIG 4    ACTIVE SERVICE MONITORING 
                                                       | Auth Name-  |
                                     | Web Services |  |  servers    |
                                     +--------------+  +-------------+
|     Whois     |  | RRP |  | EPP |  |  HTTP, HTTPS |  |    DNS      |
`-------+-------'  `--+--'  `--+--'  `-------+------'  `------+------'
        |             |        |             |                |
,-------+--------+----+---+----+---+---------+-------+--------+------.
|     Whois      |  RRP   |   EPP  |  HTTP, HTTPS    |     DNS       |
+----------------+--------+--------+-----------------+---------------+
|                                                                    |
|                 Service Consistency and Test Engine                |
|                                                                    |
+----------------+                                   ,---------------+
|     Syslog     |                                   |  IXFR, TSIG   |
`-------+--------+-----------------------------------+-------+-------'
        |                                                    |
,-------+--------.                                   ,-------+-------.
|     Syslog     |                                   |  IXFR, TSIG   |
+----------------+                                   +---------------+
| Event Handler  |                                   |   Zone File   |
                                                     |   Generation  |
 NOTES 
  1. The Service Consistency and Test Engine component performs a set of test actions against each supported service, and validates the success of the actions and the results of the action, where appropriate. The services under test are live, production services.

3.2.1.4 Event Monitoring
  FIG 5    EVENT MONITORING 
                   ,---------------.
                   |    Service    |
,---------------.  |  Consistency  |  ,---------------.
| Platform Logs |  | & Test Engine |  | Service Logs  |
+---------------+  +---------------+  +---------------+
|    Syslog     |  |    Syslog     |  |    Syslog     |
`-------+-------'  `-------+-------'  `-------+-------'
        |                  |                  |
        |          ,-------+-------.          |
        `----------+    Syslog     +----------'
                   +---------------+
        ,----------+ Event Handler |
        |          `-------+-------'
        |                  |
,-------+-------.  ,-------+-------.  ,---------------.
| Event Storage |  |   Real-Time   +--+  Engineering  |
`---------------'  |   Monitoring  |  |  Escalation   |
                   `---------------'  `---------------'
 NOTES 
  1. The event handler is a multiplexer, and distributes incoming event data to one or more event processors.
  2. All events are stored for future reference.
  3. The real-time monitoring component provides some correlation and summarization of incoming event data.
  4. Certain events or combinations of events will cause the real-time monitoring component to perform automatic issue escalation, to allow proactive problem resolution.

3.3 [C17.2] Registry-Registrar Model and Protocol

3.3.1 General Approach
 ? 
C17.2. Registry-registrar model and protocol. Please describe in detail, including a full (to the extent feasible) statement of the proposed RRP and EPP implementations. See also item C22 below.

The principal guiding objective for the design of initial registry-registrar interactions is that the transition from the VeriSign .org registry to our registry should be as simple as possible for registrars to accommodate, and hence that changes in registrar systems should be reduced to the smallest set possible. For this reason the initial registry-registrar model and interface specification has been made as similar as possible to that currently operated by VeriSign.

The initial interfaces provided to registrars for manipulation of the .org registry will be the RRP[1], with a planned transition to EPP[14] as described in [C18] Transition Plan.

The initial live set of data incorporated into the registry will similarly match that maintained by the VeriSign registry. This implies a "thin" registry model.

The registry schema (see [C17.3] Database Capabilities), will support the superset of requirements of the existing VeriSign registry data set, those requirements imposed by RRP and EPP ([14], [15], [16] and [17]), and the requirements of a thick (contact-populated) register.

A managed, gradual transition from a thin registry to a thick registry (one in which contact information is stored in the register) will be carried out as described in [C18] Transition Plan.

3.3.2 RRP Implementation

We are prepared to go live with an implementation of RRP that will satisfy all the mandatory requirements specified in [1]. However, we will also require VeriSign to disclose details of their live, production SRS infrastructure in such a way that our initial SRS implementation will conform as closely as possible to that used by existing VeriSign registrars.

Registrars may perform the following registration service procedures using RRP to communicate with the .org registry:

This is the complete set of operations defined in RRP 1.1.0.

The WFR (waiting for authentication retry) and WFC (waiting for command) states in the RRP state machine will include timeouts, which will be specified in documentation made available to registrars. The RRP server will disconnect from the client if the specified timeout in WFR or WFC is exceeded.

The RRP implementation will allow specification of nameservers associated with other top-level domains for .org registration.

The RRP implementation will support a default initial registration period for domains, which will be used in the event that the registration period is not specified in a request to register a domain. This period, together with the range of acceptable values for a specified registration period will be specified in documentation made available to registrars.

The .org registry will notify a potential losing registrar when another registrar has made a transfer request. See Message Passing to Registrars for a description of message passing from the .org registry to registrars.

The .org registry may automatically approve transfers on behalf of potential losing registrars ("default approval") when the potential losing registrar fails to acknowledge the transfer request with an RRP transfer approval or rejection command within a certain time period. The time period used will be specified in documentation made available to registrars.

3.3.3 EPP Implementation

We are prepared to deploy an EPP service will satisfy all the mandatory requirements specified in [14], [15], [16], and [18]. Object service availability will initially be limited to domain names [15], and hosts [16], in accordance with the "thin" register model. As described in RRP Implementation for RRP, specific details of our deployment of EPP in phase II of our transition plan will be made available following advice from VeriSign on their EPP deployment plans, so as to minimize the Operational Test & Evaluation (OT&E) and systems implementation burdens for .org registrars.

3.3.4 Message Passing to Registrars

It is sometimes necessary for the registry systems to send messages to registrar systems, for example to notify a potential losing registrar of a transfer request. It is not possible to send these messages using RRP.

The .org registry will support the following message-passing mechanisms:

3.3.5 Registrar Portal

The .org registry will provide an authenticated portal, accessible over HTTPS, to registrars. This portal will provide:

3.4 [C17.3] Database Capabilities
 ? 
C17.3. Database capabilities. Database size, throughput, scalability, procedures for object creation, editing, and deletion, change notifications, registrar transfer procedures, grace period implementation, reporting capabilities, etc.

The database schema for the register accommodates the superset of requirements imposed by the VeriSign register inherited at transition, RRP, EPP, a thin (contact-free) register and a thick (contact-populated) register model.

The registry database will be implemented on an RDBMS platform which is SQL-capable, and supports real-time replication between diverse registry sites, row-level locking, transaction rollback, ACID semantics, ANSI SQL support, Unicode support, triggers, stored procedures, and hot backup. The provision of a database access layer across the registry components will allow a registry based on our software to be built around a variety of different database products and on different operating platforms.

Database Size

Throughput

Scalability

Procedures for Object Creation, Editing, and Deletion

Change Notifications

Registrar Transfer Procedures

Grace Period Implementation

Reporting Capabilities. The following reports will be made available to each active registrar through the web portal (via the HTTPS protocol) and via SFTP or SCP. The reports will use XML for their format.

3.5 [C17.4] Zone File Generation
 ? 
C17.4. Zone file generation. Procedures for changes, editing by registrars, updates. Address frequency, security, process, interface, user authentication, logging, data back-up.

These procedures may not be fully implemented until we have full control of authoritative nameservers for .org. For notes on compatibility with VeriSign's procedures, see below and [C17.5] Zone File Distribution and Publication. "Zone data" in this context can refer to the full set of zone data or to data offered as an incremental update, in accordance with documented DNS standards for each.

We intend to maintain a 5-minute update frequency for any given change 95% of the time. Additionally, at least once a week a full zone file will be generated and loaded onto our servers. At least once a day we will verify that the incremental changes and a full extract of zone data match.

A companion report will explicitly flag all changes as adds, drops, or modifications to aid systems support staff in spotting unusual patterns of activity.

The generated .org zone file will include the following resource records:

The incremental update to the zone will be generated by extracting from the database, at each zone update cycle, the zone data that has changed in the database since the last such cycle. The zone data thus generated from database changes will be checked against expected activity, with large changes in size or content (more than 2% change in total size or in the contents of more than 0.1% of the total delegations) to be flagged and the automatic process halted until review of the cause of the discrepancy can be performed by senior level systems staff.

Our expectations of normal activity in this zone are based upon previous experience with other critical DNS zones. During the prelaunch phase we expect that daily examination of the activity actually occurring in .org will allow us to considerably refine these expectations and our reporting thresholds.

Once the zone data has been generated, signed, and passed the automatic integrity checks, it will be loaded onto a non-public nameserver for a final verification pass. The availability of the zone for transfers and queries will be verified at this time.

When the test-load of the zone has been verified, it will be transferred to the published master. This system will not be a publicly known server and will not be used to resolve public queries against the .org zone. It will be a configuration usually described as a "hidden primary" or "distribution master", in which the only nameservers that can reach it are those configured as slaves for the .org zone and the only work it will do is the transfer of the zone to those appropriately configured slaves.

This configuration is operationally indifferent between the use of VeriSign's nameservers, the use of our nameservers, and the use of third parties for publication of the .org zone. All that is required is access control coordination between the operators so that all slaves have permission to gather the zone from the master (see note below on TSIG). However, our turnaround times are based on the ability to do DNS IXFR as the update mechanism; full zone transfer will be dramatically slower.

The NOTIFY extension to the DNS will be used to speed convergence between a new copy of the zone at the registry and that cached on the slaves.

It is extremely unlikely but not impossible that a seriously damaged version of the zone will pass the integrity checks and be loaded into publicly available slaves. Monitoring of both help desk activity and the operation of the slave nameservers, including regular automated tests of the availability and integrity of the zone on the slaves, will assist in identifying this should it ever occur. The recovery procedure includes:

  1. Regenerate the previous, operationally acceptable version of the zone with a new serial number.
  2. Force the normal update process with the newly revised zone, by manual intervention of a senior systems staff member.
  3. Verify receipt of the recovered zone by the slaves as soon as practical.
  4. Examine and resolve problems with the broken zone.

This would not allow for a perfect recovery because bad data may still be cached elsewhere among clients in the net. There is no way for the registry to prevent this owing to the way DNS works. However, it can be mitigated by fast detection of a flawed zone, fast action to back out the newest set of updates, and fast convergence among the slaves on the reversion to the old zone data under a new serial number.

3.5.1 A Note on TSIG and DNSSEC

A critical component of our strategy for operating .org is the ability to sign the zone in accordance with the protocol extensions documented in RFC 2535[2] and RFC 2845[33]. This commitment is undertaken both in the belief that this technology is critical to the future usefulness of the DNS and in accordance with our commitment to furthering the development of Internet technology through implementation and test. We have to date contributed heavily to the development of these protocol extensions, from protocol design to implementation and interoperability test activities.

The TSIG component of the DNS security standards has been stable for some time now and is beginning to see significant use among DNS operators. It is used to sign zone transfers between nameservers and we anticipate being able to use it to sign transfers of .org to slave servers at the launch of our service.

TSIG requires the use of a "shared secret" key and good time synchronization between servers, which in turn imposes a requirement for a basic level of coordination between separate operators for the same zone. We do not anticipate a problem in reaching an agreement with VeriSign, in accordance with their current practices and those of other registries, for the management of TSIG keys during the period in which their nameservers will be part of the authoritative server set for .org.

DNSSEC standardization for data signatures is incomplete, as the technology remains subject to the usual cycles of protocol refinement, implementation, test, and protocol tweaking. A critical phase of prelaunch will be to finalize our processes for signing the .org zone around the current state of standardization and implementation at that time. The process will include: