|TOP||THE .ORG TLD IS A PUBLIC TRUST||»|
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.
|1.||General Information About the Applicant|
|2.||Statement of Capabilities of the Applicant and Contracted Service Providers|
|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.2||General Description of Proposed Facilities and Systems||C17.1|
|126.96.36.199||Provision of Services|
|188.8.131.52||Active Service Monitoring|
|3.3||Registry-Registrar Model and Protocol||C17.2|
|3.3.4||Message Passing to Registrars|
|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.2||Data Escrow Schedule, Content, Format and Procedure|
|184.108.40.206||Escrow Deposit Specification|
|220.127.116.11||Deposit and Transfer|
|3.10.1||Types of Services|
|3.10.2||Types of Attacks|
|18.104.22.168||Denial of Service|
|22.214.171.124||General and Physical|
|3.13||Compliance with Specifications||C17.12|
|3.14.4||Nameserver Availability and Performance Measurements|
|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.17||Registry Failure Provisions||C17.16|
|3.18.1||Steps of Proposed Transition||C18.1|
|126.96.36.199.1||Implementation of RRP and EPP|
|188.8.131.52.3||Zone File Generation|
|184.108.40.206||Final Cutover Preparation|
|220.127.116.11||Live Cutover Acceptance Criteria|
|18.104.22.168||RRP/EPP and Thin/Thick Transition|
|22.214.171.124||Phase I - Stable Transition|
|126.96.36.199||Phase I - Transfers|
|188.8.131.52||Phase I - Deleted Domains|
|184.108.40.206||Phase II - Dual Protocol Support (RRP and EPP)|
|220.127.116.11||Phase II - Transfers|
|18.104.22.168||Phase III - From Thin to Thick|
|22.214.171.124||Phase IV - Complete Thick/Thin Transition|
|3.18.2||DNS Server Service Assimilation|
|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.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|
|6.||Proposed Registry Services|
|6.1||Registry Services for Fee||C25|
|6.3||Registry Services Without Fee||C27|
|6.4||Technical Performance Specifications||C28|
|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|
|13.||Signature and Certification|
|§||Select RFCs By Team Members|
|§||Current Internet-Drafts by Team Members|
|§||Books by Team Members|
|§||Web Sites by Team Members|
|A.||Escrow Data Format|
|A.2||Name Server 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.2.6||Rick H. Wesson|
|E.3.8||Marshall T. Rose|
| TOC |
Internet Multicasting Service, Inc.
P.O. Box 217
Stewarts Point, CA 95480
Our partner in this application is:
Internet Software Consortium, Inc.
950 Charter Street
Redwood City, CA 94063
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.
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."
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.
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.
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)
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.
Carl Malamud (firstname.lastname@example.org)
Internet Multicasting Service, Inc.
P.O. Box 217
Stewarts Point, CA 95480
C10. Intentionally omitted.
| TOC |
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.
Applicant will perform all functions. Note, however, [C18.5] Specific Cooperation Required from VeriSign
As stated in [C13] Services and Facilities, applicant will perform all such functions.
Our ability to operate a TLD registry of significant scale is based on:
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 |
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.
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|
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.
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.
|FIG 2||SOFTWARE ARCHITECTURE|
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|
|FIG 4||ACTIVE SERVICE MONITORING|
|FIG 5||EVENT MONITORING|
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, with a planned transition to EPP 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 (, ,  and ), 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.
We are prepared to go live with an implementation of RRP that will satisfy all the mandatory requirements specified in . 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.
We are prepared to deploy an EPP service will satisfy all the mandatory requirements specified in , , , and . Object service availability will initially be limited to domain names , and hosts , 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.
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:
The .org registry will provide an authenticated portal, accessible over HTTPS, to registrars. This portal will provide:
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.
Procedures for Object Creation, Editing, and Deletion
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.
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:
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.
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 and RFC 2845. 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:
Transfers of zone data will be performed via a zone transfer from the "hidden primary" nameserver (see [C17.4] Zone File Generation) once the change report has been generated from the database, transformed into zone data format, and passed the required integrity checks. Transaction signatures (TSIG) will be supported as described in A Note on TSIG and DNSSEC.
As noted, our zone data generation and publication procedure as described in [C17.4] Zone File Generation is intended to be indifferent among slaves for the zone that are ISC's nameservers, VeriSign's nameservers, or some other third party's nameservers as long as they interoperate with DNS standards.
According to existing provisions in other ICANN registry contracts, including the one with VeriSign for .org, the registry is required to make the full zone file available under appropriate contractual restrictions to other parties. Such parties at this time are estimated to number in the hundreds. In order to meet this obligation without risking any impact to the operation of the authoritative nameservers for ORG, the complete zone file will be available by AXFR (as restricted by an access control list) or ftp (as restricted by a login and password) on a separate machine to any such parties who may wish to enter into an agreement with the registry for access to the data.
Our billing and collection systems are fully automated and fully secured. We performed the first electronic commerce transaction on the Internet in 1994 and have extensive experience with these systems.
Communication with registrars is available through the use of secure electronic mail or secure sessions via the World Wide Web. Identity is established during the signing of the initial registry-registrar contract. Our systems use SSL to provide secure communication on the Web with identity established using the Thawte Certification Authority.
Registrars may make deposits into their accounts through all standard electronic funds transfer mechanisms, including bank drafts, ACH or SWIFT transfers, and using American Express, Discover, MasterCard, and Visa bank cards. Registrars may also send us a check payable in U.S. dollars, such amount being credited immediately upon clearance.
Once funds have cleared, a real-time system works with the core registry system to maintain a real-time account balance. Registrars will be able to use a secure web-based system to monitor the status of their account, including a variety of reports on registration and payment activity. Written statements will be dispatched by electronic mail at the option of the registrar.
SRS events that require financial transactions against a registrar account will be passed to a billing system as transactions to a General Ledger. The API of this software is the OMG's specification for a General Ledger Version 1.0.
Each registrar is required to provide funds as pre-payment for transactions such as registrations, renewals, and transfers. After each transaction the registrar's account is updated appropriately. If a registrar should fall below their balance and has no other credit instrument available, the registrar's account will be barred from processing billable RRP events.
Registrars may set a low water mark for their account. If their account reaches this threshold, email will be generated and sent to their billing contact warning them of their situation. If a registrar were to cross the low water mark for their account a phone call will be made to the registrar's billing contact to discuss their account. All attempts will be made to assist the registrar in understanding the situation and their accounts before a registrar is shut down for cause.
Under no circumstances will the registry extend credit to a registrar. No surety bond is required for registrars, but standard indemnification provisions and insurance requirements will apply.
The Registry Operator will prepare:
Full and incremental data sets will be up-to-date and coherent as of 1200 UTC on the day to which they relate. Until a different day is designated by ICANN, the full data sets will be prepared on Sunday.
Files will be prepared as XML documents adhering to Escrow Data Format. Each XML document will be placed in a file named according to the following convention:
- Full data sets:
- "ORG-CCYYMMDD.full", where CCYYMMDD is constructed from the date (CC=century, YY=last two digits of year, MM=number of month, with January numbered 01, DD=day of month; in all cases a single-digit number should be left-padded with a zero).
- Incremental data sets:
- "ORG-CCYYMMDD.inc", where CCYYMMDD is constructed as above.
The escrow data sets will contain Nameserver, Registrar, and Domain objects.
The domain object, which corresponds to a registered second-level domain under ORG, consists of the following elements:
The nameserver object, which corresponds to a single registered nameserver, consists of the following elements:
The registrar object, which corresponds to a single registrar, consists of the following elements:
The contact object is only used internally to manage contacts associated with registrars. The contact object consists of the following elements:
Objects that have been deleted will have a status of DELETED.
The full and Incremental dumps will be in text format using RFC 822 like name value pairs with records separated by a CRLF (\r\n) pair. I18N domains will be expressed in their RACE format until such a time that an RFC on the internationalization of domain names is published by the IETF.
The registry operator will prepare and transfer the escrow data files in the following manner:
The escrow agent will verify the format and completeness of each deposit by the following steps:
We recognize the risk posed to the stability of the DNS by failure of critical systems. We have extensive backup systems ensuring near zero data loss even in the event of multi-point infrastructure failures.
The need for conventional backups to tape has been largely eliminated in this infrastructure design by the use of RAID5, checkpointing of dynamic data, the deployment of identical pairs of machines allowing for the use of disk cloning to recover lost system functionality, etc. However, some data remains both dynamic and difficult to reconstruct, such as transaction data, some application data, trouble tickets, and the central database. These dynamic and less recoverable portions of the system environment will be backed up over the net to the central registry location regularly. This includes the equivalent data as described in the escrow provisions, including UTF-8 database dumps to be used in the event that online databases and checkpoints in database format are somehow corrupted.
We expect that the normal means of restoring a damaged server to operation will be to build operating system and initial configuration from original media, add applications as documented, and configure as per established, change-controlled configuration data. There will not be traditional full backups of servers because all that will be backed up for any server is the particular "personality" or state specific to its function.
Software development materials, including source code, tools, and test data, will be among the data committed to backup.
Periodically the archived configuration data, development snapshots, and other dynamic content will be sent offsite to secure storage for retrieval if needed.
Escrow data is deposited daily as incremental deposits, and weekly as full deposits, as described in Data Escrow Schedule, Content, Format and Procedure.
The .org registry will provide a public Whois service as described in [C17.12] Compliance with Specifications. Example output is included in Initial Whois Output Format.
Facilities for alternative, additional output formats more suitable for machine parsing will be made available if .org registrars indicate they would be useful.
Future changes in the registry model (e.g., any transition to a thick registry which involved the storage of additional fields in the registry database) may require changes to the output of the Whois service. Any changes which are not backwards compatible with the initial planned Whois service will only be introduced following extensive consultation with .org registrars and ICANN.
Bulk access to the Whois data may be made available to registrars after signing a Whois Data Access Agreement designed in the same vein as TLD Zone File Access. Bulk Whois data would not contain any personally identifying information. Should the .org registry contain Contacts, personally identifying information would be withheld from bulk access.
Our general approach to security implements the following basic assumptions:
Three types of services are run. These are fully public, restricted, and fully private. DNS and Whois fall into the first, and SRS protocols fall into the second. Bulk access to data and access to statistical information are restricted. Internal only services, such as database and shell access to server machines, are fully private, and may use on non-publicly routed addresses.
Many of the services are fully public. Using multiple layers of firewalls, access to machines will be limited to only what is necessary to provide a service. These services are subject to denial of service attacks (both malicious and unintentional) and are probed for possible intrusion points.
These services are not password protected or otherwise authenticated before being queried:
Supported SRS protocols are not public services, and can be protected from the general public. They are password and/or certificate authenticated. Encryption is used for these services.
Database services and shell access to server machines will be as tightly restricted as possible. Shell access will always be using well-established encrypted services such as SSH. Database services will be firewalled off to restrict access, and database access will be restricted.
Denial of Service (DOS) attacks come in two types, those that are malicious and intentional, and those that are accidental. Intentional attacks are concerted efforts, while unintentional DOS situations arise from poorly configured client software, malfunctioning hardware, or attempts to circumvent restrictions on bulk access to data.
Prevention of DOS attacks. Some services can be protected against DOS attacks by limiting the number of queries an IP address can perform in a given amount of time. DOS attacks are the most prevalent and the hardest to defend against without human intervention.
Detection of DOS attacks. DOS attacks typically have easily detectable spikes in service load and server usage. Many tools exist to detect these situations.
Recovery from DOS attacks. Once a DOS attack is blocked, the machine and services return to normal. Other than analyzing and preventing such attacks, no other security work needs to be performed. We will put into place procedures to contact our network providers about any DOS situation. This will allow us to quickly recover from them, prevent new ones, and to trace the source of attacks.
Intrusion attacks attempt to run executable code provided by the attacker, or to obtain access to the server machine. These attacks are more severe than DOS attacks because, once successful, the machine itself cannot be trusted.
Prevention of Intrusions. All possible security measures will be used to prevent intrusions. Firewalls will limit access to services and machines, and all public services will run with limited privileges in restricted environments. Additionally, compromise of one machine will not allow compromise of other machines.
Detection of Intrusions and Attacks. Many tools are available to detect intrusions or other types of unusual system activity. Many of these are designed to detect the attacks before they are successful, while others detect changes to the machine's executables and data after the fact.
Network monitoring tools will be used to detect intrusions attempts by analyzing incorrectly formatted DNS and Whois queries, attempts to log into machines, and other network traffic. The data from this monitoring will aid in detecting unauthorized changes to data, and will help in developing and testing changes to services.
Tools like tripwire will be used to ensure system binaries are not modified. These tools compare the production server's environment with a known good image.
Recovery from Intrusions. The only sure way to recover from a system intrusion is to reinstall from operating system media and to install new security patches. Every machine runs a standardized operating system image and software set. Reconstructing a compromised server will happen very quickly. Additionally, due to our high service redundancy, removal of one machine will not cause a service interruption.
Compromises of more integral machines such as the database machine are more severe, but a strong backup and data mirroring will quickly allow a hot-spare to be configured, secured, and put into production.
Physical access to servers and networking components will be limited. Secure co-location services provide controlled access to equipment and network access points.
Given the fact that .org has an established history and pattern of activity, we have little concern about a sudden, dramatic change in activity levels even with a change in management. Technical planning has, however, taken the possibility into account.
Peak capacities for the database, the servers, and the network have been planned such that one installation can easily handle the total expected load, which gives a built-in overprovisioning of a factor of 2 for total activity overall. Numbers used for planning normal load already use a base capacity required for servicing 5,000,000 names, approximately twice the number currently in use, so the total system is overprovisioned by a total factor of 4, with the option to grow network bandwidth essentially at will up to the total provisioned capacity of the 100Mb cross-connects.
Nameservers and Whois servers are overprovisioned by a factor of 10 or more and are limited by network bandwidth for presenting traffic to them rather than limited by CPU, memory, or disk. Database throughput for the primary installation is projected to be more than 10 times the expected loads of genuine updates, and can handle many times the same load of reads and unsuccessful writes.
Backup, data escrow, and other support systems are sensitive primarily to the size of the database and the latency of the network, so are subject to the same overprovisioning as those capabilities. Software is designed and built, and the network is engineered, to scale past an additional order of magnitude or more over currently projected use with minimal impact to support systems.
Customer support is 24x7 from launch, allowing unexpected support load to be spread out immediately, particularly for non-urgent issues. Additional less-skilled help, if needed, can be obtained temporarily, with minimal training time, while more advanced help with systems or software can be obtained from contractors with whom we already have relationships.
Customer support will benefit extensively from automation and experienced systems staff to keep the operation running smoothly, with minimal trouble. In addition we regard timely distribution of detailed information to registry customers as a critical component of support. Tools in support of this goal are expected to include industry-standard telecommunications facilities, trouble ticket and bug databases, and distribution of useful information to registrars and the public via email and the registry web site. However, the heart of any good support operation is always professional, skilled, available support staff.
The core of customer support for the .org registry is a dedicated customer support center, available 24x7 via telephone, email, and a website. The email and web portions of the support interface, along with certain notification facilities, will be maintained as part of the production service, including high reachability, reliability, fault tolerance, and graceful failover in the event of network or server issues at any one site.
The experience of the technical team in building customer support operations for Internet services suggests that the outsourced call center approach is not the most beneficial for a support operation required to provide a high degree of skilled support for specialized services to a small customer base, as is the case here. The customer support staff will be located with and work beside the systems and development staff. Internal processes will be closely coordinated between these two teams in order to provide minimal opportunity for delayed escalation, misunderstood problems, and the miscommunications that can otherwise limit the efficiency of support services when these teams are kept separate.
Professional quality trouble ticket systems and telephone call management facilities will be used to track all incidents, whether internal or customer-driven. Industry standard metrics such as call hold times, call duration, and system availability will be used to track resource levels, including the need to increase staff or upgrade bandwidth or hardware.
Systems and software staff will be on-call 24x7 in the event that a problem is urgent and cannot be resolved by the customer support specialist receiving the incident report. Both customer support and the registrar, with appropriate authentication, will be able to view tickets in progress. A ticket will not be closed until the customer agrees the problem is resolved or a workaround is in place.
It is anticipated that most incidents will involve a customer at a time, although a larger scale problem would affect many customers. In such an event, as well as in the case of routine maintenance that may have even limited customer impact, registrars will be notified by web and email.
Systems and software staff, in consultation with customer support, will establish a regular maintenance window. This will be used for non-outage maintenance such as phased software upgrades, minor routing policy adjustments, and other activity not expected to cause significant customer impact. There may be no separate notice to customers in advance of minor changes occurring within established maintenance windows and not anticipated to be affect the customers.
Maintenance activities will occasionally cause customer impact, from degraded performance or lower availability of SRS protocols to an outage of the database. Every effort will be made to choose times and methods for these activities that minimize impact to the customer and notification will be provided on the web and via email at a minimum of a week in advance.
Software development and quality assurance activities will make use of a dedicated server facility, duplicating the fielded production systems, and professional software engineering tools and test practices.
Enhancement and new feature requests will be prioritized by the development team in terms of complexity and urgency, with a development road map published periodically to registrars and the public. Minor releases to propagate bug fixes will occur as they pass QA, in accordance with maintenance policy. Changes required to improve security, performance, or standards compliance will take precedence over such other changes as may be requested.
Non-time-critical questions will be assigned a priority and a level of complexity by the support staff person who initially receives them, with a response within three business days either answering the question or stating that it has been escalated for further consideration by systems, software, or administrative staff.
FAQs, aggregate metrics of registry activity, the software bug database, and related material will be available via the registrar portal and, in many cases, to the public. We anticipate there may occasionally be a need to temporarily limit disclosure of some operational information, most likely for security or legal reasons. But we do find that one advantage of open source development and related processes is that they limit the overhead of customer contact authentication, confidentiality agreements, and other obstacles to quick sharing of information as needed.
It is anticipated that a dedicated staff of six customer support specialists, including a manager, and five developers/system staff will be able to handle supporting registrars, public services, and initial software deployment as of the launch date. The registry may also require additional help in the form of part-time or consulting specialists as part of the launch phase or as special circumstances might dictate in the production phase.
The Whois services described in [C17.8] Whois Services are implemented using the transport protocol specified in . The query language and the format of the responses differ from RFC954, however, in favor of compatibility with the VeriSign Registry server whois.crsnic.net. The .org registry server will be known as whois.isc.org. Sample output can be found in Initial Whois Output Format and Thick Record Whois Output Format, for registry records which do not include and which do include contact objects, respectively.
DNS service will be sought from VeriSign initially. Our global deployment, which will replace the VeriSign secondary DNS service for .org, will run production releases of BIND, specific versions as performance and future needs require. Deployed authoritative nameservers will be operated as authoritative nameservers with no zone transfer or recursive lookup capabilities. Standards compliance of interest for this task includes the following DNS-specific RFCs:
As a general principle, we build and buy software and equipment that support open, interoperable standards wherever possible. We also participate actively in the development and implementation of new protocols as the evolving Internet requires them.
Quality of Service for network services is expressed as a set of metrics that attempt to quantify how well the service is meeting expectations and requirements. Metrics we propose for the registry services are derived from those commonly used by ISPs, TLD registries and other DNS services, content delivery providers, and others providing widely used Internet infrastructure.
Questions to be addressed by defined metrics include:
An additional component of the quality of service is the nature, the duration, and the impact of outages, planned and unplanned.
Deriving quality of service metrics for the .org registry uses the following definitions:
Permitted values for these parameters in the context of the .org
registry operation can be found in the
Tools for monitoring availability and capacity of our registry services include:
Both daily reports and real-time displays on ongoing measurements will be made available to the technical staff for diagnostic and provisioning analysis.
Planned Outages will be scheduled well in advance. The registry will notify the registrars of any Planned Outage at least 3 days in advance.
The registry will notify all registrars of any Extended Planned Outage at least one month in advance. Extended outages are a serious matter for the registry and the registrars and will be avoided to the maximum extent possible.
Processing time is a critical component in a transaction based service like the SRS, and refers to the amount of time it takes to process a single request from when it is received at the server to when a response is emitted.
Processing time performance specifications for Add, Modify, and Delete, or Check operations in the SRS refer to the 95th percentile of the amount of time it takes to process transactions over a month.
Processing Time specification for a Whois query refers to the amount of time it takes from when the server receives the request until it emits a response.
Processing Time Specification for Domain Name Resolution refers to the amount of time from when the server receives a query until it emits a response.
Processing Time Specification for Domain Name Updates refers to the amount of time from when we receive a update request from a registrar until the DNS update is reflected in the public served by our DNS servers.
Summaries of the acceptable performance parameters for each of these metrics can be found in the table below.
Our technical team, with experience of root nameservers, TLD DNS provisioning, and DNS service requirements for large ISPs, is well equipped to provide the critical elements of highly available service for nameservers. (The comments here apply to our DNS service, which we will begin deploying within six months of the start of the registry contract and which will assume responsibility for DNS services from VeriSign at the end of the transition.)
There is a high degree of inherent redundancy in the DNS itself, in that only a subset of the authoritative nameservers for any zone needs to be functioning at any given time in order for satisfactory name resolution to occur. With geographic and network diversity of DNS servers (multiple physical sites, multiple major network carriers providing transit), plus this inherent fault tolerance that comes with maintaining a large set of well-provisioned servers, we anticipate essentially no likelihood of any downtime of the .org DNS service at all.
Each system, or cluster of systems in a load-balancing configuration, can be expected to meet a minimum 99.99% uptime on a monthly basis, with the ability to service at least 3 times the measured offered peak load on any single nameserver or cluster.
Availability of a nameserver within the provider's network is of course a less compelling measurement of its usefulness than availability from where the users are. The operator of any system has limited control over that system's availability from the perspective of an arbitrary user. However, our concentration on providing well-connected services through a variety of transit providers and peering partners allows us to maintain a very high degree of reachability to our servers from locations throughout the public Internet.
The .org registry DNS service will meet the Cross-Network Nameserver Performance Requirements as documented by ICANN at section 2.1. In addition, we expect to deploy our own monitoring to observe the performance of our services from outside of our own installations, and promptly correct any serious or persistent problems with reachability of our service from the public Internet.
Two services, name service and Whois service, must be updated frequently. These services receive data from the database as updated by registrars and propagate them to the public Internet.
The committed update frequency metric for both the nameserver and Whois denotes the 95th percentile over a month for how long it takes an update to the registry database to applied to both DNS and Whois servers. This is measured from the time the registry confirms the registrar-initiated update to visibility on public services.
During the transition VeriSign will be initially responsible for serving the .org zone. We will commit to getting the updates to VeriSign within the specified update frequency, but it will be outside our control as to when VeriSign applies the updates to the published .ORG zone.
Category Service Metric ===================== ======= ========================= Service Availability SRS 99.9% per calendar month. DNS 99.999% per calendar year. Whois 99.5% per calendar month. Processing Time SRS Add, Modify, Delete: 3 seconds for 95%. Check: 1.5 seconds for 95%. Whois 1.5 seconds for 95%. DNS 150ms for 95%. Update Frequency DNS 5 minutes for 95%. Whois 5 minutes for 95%. Planned Outage - Duration SRS 8 hrs per calendar month. DNS Never. Whois 8 hrs per calendar month. Planned Outage - Notification SRS 3 days. DNS n/a Whois 3 days Extended Planned Outage - Duration SRS 18 hours per year. DNS n/a Whois 18 hours per year. Extended Planned Outage - Notification SRS 1 month. DNS n/a Whois 1 month
All public registry services will be subject to automated, proactive monitoring (see Active Service Monitoring for a functional description of the monitoring infrastructure). The event handling facilities described in Event Monitoring include provision for real-time service monitoring, as well as an automated escalation component. Problems with production services, whether reported by customers or detected by automated monitoring, will be tracked in the registry's ticket system.
All registry systems will be housed in carrier-class co-location facilities, which will include fully redundant environmental control, and uninterruptible power supplies. Registry systems will be deployed in multiple sites, such that a complete failure of one site will not prevent registry systems from continuing to handle a full load of production services. The co-location facilities chosen will provide a very high level of physical security, and access to registry equipment will be strictly limited to registry technical staff. A full record of every physical visit to the equipment will be maintained.
The full-load, production operation of all registry services will not depend on any single network or server element.
Tru64 on Alpha systems has been developed over many years to the highest standards of performance and reliability, particularly in a configuration required to support high availability and high performance for web and database services. Our extensive previous experience on this platform has shown it to be fast, stable, reliable, and capable of handling the most intensive core Internet infrastructure functions.
All software changes applied to registry systems will be made first in an isolated test environment, and rolled out to a user-test environment once regression tests have been passed. Once successful user testing is complete, code will be migrated into production within maintenance windows, with full provision for rollback in the event that problems are discovered. Production deployment of software changes will not be made on two redundant servers simultaneously, unless the nature of the software change requires a consistent version of software to be running across the redundant pair.
All network changes will be subject to peer review, and will be made during published maintenance windows.
No changes will be made to any network element or registry system component without full documentation being included in the ticket system.
The registry has been designed to withstand single-point hardware failure at full system load. Failed hardware components will be replaced during published maintenance windows. Hardware maintenance will not be performed on both elements in a redundant pair during the same maintenance window.
If it is considered that the safe and stable operation of registry functions is seriously jeopardized, emergency software or hardware maintenance may be performed which does not follow the published maintenance policy. Such emergency maintenance will only be performed with the authorization of an .org Program Manager.
Backup services will run as described in [C17.7] Data Escrow and Backup.
System security is discussed in [C17.9] System Security.
Network diversity will be accomplished using multiple transit providers at each co-location facility. Additional route diversity will be obtained using an aggressive and open peering policy.
As noted previously in [C17.14] System Outage Prevention, much of our architecture is designed around the architectural principle of avoiding single points of failure rather than having elaborate plans for recovering from faults involving such points. However, it is not realistic to assert all possible failures can be prevented.
In general, our response to major incidents is based on the multiple layers of redundant service available in our hardware and software configuration. As a matter of course we load-balance among multiple instances of the public Whois and DNS at all times, so the failure of a single instance of these services within one site or between sites should be literally unnoticeable.
The SRS services and database are slightly more complex to handle redundantly because of consistency issues between instances. Thus there will be a primary instance of the database (one per site) and a primary instance of the registrar portal for addressing it (two per site). Failover between servers at the same site, sharing a database instance, will occur within minutes, with some operations oversight, and will be transparent to the registry user owing to the redundancy features in the network equipment.
Transaction replication between the primary and secondary instances of the database will allow for transparent failover between sites in the event of a catastrophic failure at the primary site. Mechanisms contemplated to redirect traffic from the primary site to the secondary include https redirect, DNS changes, and network provisioning so as to support re-routing of traffic from one site to the other at the IP layer.
Procedures for failover between systems, failover between sites, and recovery from the fault or outage condition are the responsibility of the technical operations lead and the technical staff. The customer support technicians will have the ability to monitor automatic failover systems and processes, with escalation to on-call technical staff when any of the automatic failover processes are invoked. This ensures that the situation can be monitored, the initial problem corrected, and any additional failures diagnosed and repaired.
As previously discussed in [C17.14] System Outage Prevention, fully redundant hardware and network connectivity allows us to minimize the impact of single hardware failures, whether routers, switches, or servers. It is to be expected that no noticeable outage will occur as a secondary router, switch, or server takes over the full load of a failed companion.
If such failures do occur, they will be fixed in a timely fashion in order to return to fully redundant operation. Support contracts with hardware vendors and with co-location providers will allow for on-site replacement of failed hardware as needed. In the event of a particularly complex failure, registry technical staff may be dispatched to the site to supervise diagnosis and repair.
Maximum impact of a single hardware failure: loss of a single site. In the event this is the primary production site, the second site will continue to function under the full expected load. Some outage or disruption may be notable to registrar clients as the database at the secondary site is validated and the server takes over as primary. In the event the development and management site is affected, software updates, customer service advisories, and some reporting functions may be impacted, but the production sites will continue to function.
Software failures may be harder to isolate than hardware failures, requiring a more flexible response. Tools for diagnosis and mitigation of unexpected software problems include:
Software bugs will be classified and prioritized as reported, with resources assigned to fix them according to their severity. A bug, misconfiguration, or other anomaly that causes failure of production SRS services, public Whois, or DNS, will be assigned all possible resources until resolved.
Database anomalies or corruption are the most severe potential class of problems.
We expect that regular backups and maintenance of a "warm spare" copy at the secondary site will allow for recovery from a catastrophic failure of the database software or the corruption of the online contents. Database replication between a primary and a secondary is a well understood and widely used technology for fault tolerance.
However, periodic dumps of the database to plain text will be taken in order to support a "fix of last resort" in which the operations staff would load the text and table descriptions into a clean copy on some other database system, configured from scratch if necessary.
Maximum impact in the case of a switch to a new database system and reversion to archived database data would be some hours of downtime to bring up the new system online if checkpoint database logs are not available or are not compatible with the replacement database engine. Loss of the data will be limited to data committed between the text backup used for restoration and the failure event.
The primary value in having multiple production instances of the server farm is to eliminate the chance that a failure at a single facility or a single transit provider could destroy connectivity for the entire registry. Multiple transit providers at multiple sites mean that network connectivity is unlikely to be lost to even a single site for any significant length of time, much less all registry sites.
It is not impossible that for reasons of natural disaster or other causes a co-location or network services provider could experience an interruption in their ability to provide services to us. Failure of one site or one provider can be handled transparently. A more complete failure is unlikely to occur without affecting a far larger portion of the global public Internet than the .org registry.
The registry's later stage deployment plans involve "satellite installations" of servers to handle DNS and Whois queries at well-connected sites throughout the net. This will enhance the ability of the registry to support these critical services without interruption for .org registrants even during a period when the registry's ability to conduct other normal operations such as add/modify/delete might be impaired.
A critical component of fault recovery for the registry is the commitment of customer service to both supporting the recovery process and keeping customers informed throughout. The discussion of incident handling in [C17.11] Customer Support describes the responsibilities of Customer Service, but we emphasize here that the registry operations center is committed to disseminating information about outages in the following ways:
In the event of an outage affecting the customer service site itself, contingency plans for backup phone and network service at a nearby location are included in the registry operational plans. Thus even a major operational problem should not render the registry unable to carry out operations or maintain contact with its customers.
Previous portions of this discussion have described the redundancy, reliability, and failure recovery provisions of the operation we are proposing. These include valid, tested escrowed data or conventional backups for all data needed to take over operation of the registry:
We find it unlikely that multiple production sites for the .org registry service, including both the primary production site and the backup site, along with all valid backups, would be destroyed. Please see the previous discussion for our reasons why we do not foresee any situation in which all of our production facilities would become unavailable, irrecoverably, all at once, barring the disruption or destruction of a substantial portion of the global public Internet. In all other cases the data escrow, backup, and software engineering processes we have described would allow us to recover operational capability.
However, the availability to ICANN or its designee of all the data required to run the registry will provide the ability to allow ICANN or its designee to run the registry in the event that we were no longer able to do so.
A business failure such as a judgment, insolvency, or Act of God, that only encompassed the registry operator would allow reconstruction of the technical ability to run the registry by any ICANN-designated party granted access to the escrowed material, just as above. In addition, the senior technical team would make a best effort attempt to assist the ICANN-named successor registry operator in a transition away from a business failure of the registry operator.
Whois and DNS services could be transitioned almost immediately to any entity with nameservers and other capable servers in geographically diverse locations. The ability to accept database changes and new registrations, and reconstruct relationships with registrars, could follow shortly thereafter, with the critical path determined by legal and regulatory concerns, not operational ones.
The open source and open standards orientation of the .org registry we are proposing has the particular advantage of no intellectual property encumbrances on the software required to run the registry. Succession for an operation based on open source and open standards software is significantly simpler than might be required for a registry based on proprietary solutions.
A regulatory failure provides a less definitive scenario because of the difficulty in defining it. We are here envisioning the possibility of a radical change in either ICANN's composition or mission such that some other entity or group becomes responsible for some or all of the ICANN functions involved in concluding or maintaining a registry agreement, making the agreement with ICANN somehow unsustainable. It is impossible to predict how such changes might unfold, but we note that the organizations involved in the .org registry described here have a long history of commitment to a stable Internet, along with unmatched operational experience in assuring it.
In the event of a major change in ICANN's composition or mission that would impact its agreements with parties such as registries and registrars, the .org registry would continue to operate under the same terms as included in its ICANN contract as any regulatory changes and new contract negotiations went forward. The registry would continue to serve registrars and end-users with as little disruption as possible while regulatory issues were resolved such that a new contract became possible or a new operator was selected in accordance with evolving ICANN process.
We discuss here the high-level development and implementation roadmap for software and procedures up to registry function acceptance test and cutover from VeriSign management of the registry data to us.
We also discuss below in more detail RRP/EPP and Thin/Thick Transition, as well as DNS, IDN, Whois, and IPv6 issues.
The formal startup phase of the registry implementation begins with the bid award. We include a high-level description of the development and deployment plan for equipment, software, and technical support capabilities, based on a bid award in August 2002 and a production date of January 1, 2003.
The following characteristics will be used to determine readiness for operational cutover of the registry function from VeriSign to us:
Non-critical path items for initial launch, to be resolved within operational Q1:
There are three phases to the .org transition from VeriSign Registry to the new .org Registry. Phase I will consist of serving registrars requests with an RRP protocol compliant Shared Registry Service (SRS) and providing the basic services for DNS and Whois. The goal of Phase I is rock solid stability for registrars and their customers and the DNS.
If VeriSign has initiated transition to thin-EPP we will accept any registrars passing of an OT&E testing criteria with the VeriSign Registry. We will also combine Phase I and Phase II for the launch of the .org Registry so that qualified registrars have the opportunity to use either EPP or RRP on day one.
Phase I will consist of serving registrar's requests with an RRP 1.1.0 protocol compliant Shared Registry Service (SRS) and providing the basic services for DNS and Whois. The goal of Phase I is rock solid stability for registrars and their customers and the DNS.
During Phase I of the transition we will take over the management of the .org registry. We will manage the .org zone file and provide a RRP based registry service. We will manage the data transfer from VeriSign and deploy services exactly replicating the current VeriSign service offering for .ORG. Phase I is all about staying consistent with current requirements thus providing for a stable transfer.
In Phase II, we propose to migrate from a pure RRP based registry to a thinly managed EPP based registry. During this migration phase the registry will support two similar protocols. We intend to run both EPP and RRP in parallel for at least 18 months. EPP can run in either a thick or thin model and in Phase III we propose to take the .org registry to a thick registry.
The main difference between thick and thin registry protocols is that thin registries do not maintain contact data. The use of thin registries has been a constant issue for all ICANN registrars and the recent launch of several thick gTLD registries has proven the viability of a thick EPP registry protocol.
During Phase III we propose that registrars migrate their contact data to the registry. As domains are migrated to maintain contacts the Whois for the domain will also migrate. We will work with ICANN and the registrars on the time line of the thin to thick registry migrations with the understanding that a thick EPP based registry is our goal for the .org registry.
It is our goal to provide this service to the registrar community with a smooth, low-cost transition from RRP to EPP. Not only will the server software become freely available, but our experience, software, and expertise will be open for all current and future name registries to use and inspect. We will create a platform for ICANN to create a more stable and robust Internet naming infrastructure.
The goals for Phase I is smooth transition and stability for registrars. Our focus will be on a complete and accurate implementation of RRP and its associated out of band communications such as using identical automated e-mail messages for transfer notifications. We will work to mirror the current registry operations for a seamless transition. If VeriSign has deployed a thin EPP implementation this phase will be combined with Phase II.
During Phase I of the migration transfers will operate just as they do now with VeriSign Registry. We will assume and implement duplicate policy regarding domain transfers.
During Phase I of the migration we will implement processes, under the direction of ICANN, based on the outcome of the Redemption Grace Periods for Deleted Names (Technical Steering Group's Implementation Proposal)
Our first evolution will be to dual protocol support, meaning we will host RRP and thin-EPP on the same virtual front-end. Allowing the registrar the option to use either RRP or transition to thin-EPP. We believe that the improved robustness of EPP will allow registrars to compete more effectively than registrars using legacy RRP.
We will work with ICANN and registrars to determine a mutually agreed upon time frame for determining the end-of-life date for RRP support. Should ALL registrars complete the evolution to EPP before the agreed upon time-frame period we could accelerate to Phase III after appropriate consultations with ICANN and registrars.
While we are running both EPP and RRP transfers will continue to function for RRP as they did in Phase I, however there will be several enhanced features that we will take advantage of with EPP. When we place EPP into production every domain will be assigned a randomly generated AuthInfo token. These tokens will be available to the registrar of record through the EPP "info" command. Registrars must present this token to initiate and or acknowledge a transfer request over EPP.
We will work with ICANN and the registrar community to determine the most effective date to retire the RRP transfer functionality and only allow the more secure and clearly authorized EPP transfer functionality.
Thin registries only support referrals in their Whois, meaning that thin registries only manage relationships that describe the domain and which registrar it belongs to: thin registries do not maintain contact information and they cannot display any information about contacts from their Whois database.
Registrars that participate with thin registries must maintain their own Whois and must also implement parsers for some 100+ other registrar Whois formats. All efforts within the IETF and ICANN to further specify port 43 Whois into a common format have failed; However registries that provide thick Whois and use thick protocols such as EPP allow a registrar to implement a parser for the registry Whois format instead of parsers for 100+ registrar formats.
The .org EPP accreditation process will include a rigorous Operational Testing Criteria, which must be passed with 100% accuracy for a registrar to become operational with the additional EPP protocol. Registrars that have passed a Operational Testing Criteria from VeriSign will be grandfathered if VeriSign has launched an thinly managed EPP registry function before Jan 1, 2003.
At some point in Phase III of the protocol evolution phase, after all registrars are using EPP, the registry will allow registrars to start associating contacts with domains. Again we will work with the registrar community and ICANN to determine the best time frame for phasing out the thin EPP registry function.
EPP will become the primary method to manipulate registry objects. Once an object has contacts associated with the domain the Whois for that domain will include those objects in the Whois output. Once all domain objects have associated contacts the registry will no longer accept thinly manage domain objects. Meaning that the registry will require all addDomain commands to contain the required contact references. The date of this final thin to thick transition will be mutually agreed upon with the registrars and ICANN.
Phase IV will signify the complete transition from a thin EPP based registry to a thick EPP basted registry. In Phase IV all domains will have associated contacts and all Whois replies for domain requests will contain contact information.
VeriSign will initially run the DNS for the .org registry on the currently deployed GTLD-SERVERS.NET cluster. During this time we will abide by VeriSign DNS server update policy, which will be mutually agreed upon with VeriSign and ICANN. During the transition we will abide by this policy until ALL nameservers are under our direct control.
We will selectively deploy the .org zone on additional servers and in coordination with ICANN roll the new delegations into the root-zone and off individual VeriSign .org Domain Servers. The assimilation is expected to take 6 months for the full and complete replacement of VeriSign nameservers with our DNS infrastructure.
VeriSign Registry has sold a significant number of domains described as Internationalized Domain Names (IDN). These domain names are encoded using a encoding described in the expired Internet-Draft draft-ietf-idn-race-03.txt. The encoding was called RACE or Row-based ASCII Compatible Encoding for IDN. This obsolete encoding is still supported by VeriSign and the IETF has abandoned it as a viable solution for Domain internationalization. These domains, encoded in the RACE format starting with the four-character prefix 'bq--', will be call the RACE domains.
We will maintain the RACE domains until such a time that the IETF IDN working group creates a Proposed Standard for creating and manipulating Internationalized Domain Names(IDN). We will allow domains to be manipulated but not renewed. RACE domain may be deleted but not added to the registry.
The current registrars of RACE encoded domains will not be charged for RACE encoded domains until the registry has a production solution in operation. No new RACE domains may be created via EPP or RRP, but no registrar, and hopefully registrant, will be charged for a domain that cannot be resolved from the .org DNS Servers.
We will only support internationalized domains once the IETF has created a Proposed Standards for such encodings and consultation with ICANN has produced a mutually agreed upon action plan for the deployment of I18N functionality in the .org registry.
RACE encoded domains will only be delegated under the domain "mltbd.org" until ICANN has approved the use of an IETF-designated Proposed Standard on the use of Internationalized Domain Names.
We propose that the VeriSign Registry serve a single referral to the .org registry for any .org domain or nameserver that is sent to any of the port 43 Whois servers the VeriSign Registry operates.
A sample request/reply for the domain 'example.org' to whois.internet.net:
C: example.org\r\n S: Domain names in the .com, .net, and .org domains can now be registered S: with many different competing registrars. Go to http://www.internic.net S: for detailed information. S: S: .org Domains are now handled by the .org registry administered by S: the Internet Software Consortium. See http://nic.isc.org for more S: information. S: S: Domain Name: EXAMPLE.ORG S: Whois Server: whois.isc.org S:\r\n
The major components of .org registry support for IPv6 are as follows:
We will post notifications to various operational mailing lists of the stage and progress of the .org transition. We will attend and present status and progress reports to ICANN and at various operator conferences.
We anticipate some interruption in the registry function for a few hours as we synchronize databases with VeriSign, validate the data, and make sure VeriSign has stopped accepting add/mod/deletes for the .org domain before we start to accept them. This will require some assistance from VeriSign and some effort by registrars to reconfigure their SRS clients. Support requirements more than the operational requirements dictate we be prepared for the handoff to take several hours to finalize and verify.
Contingency plans for some failure of the proposed changeover address three possible situations:
Effects of the transition on .org registrants are expected to be limited to the need to change their Whois clients to point to a different registry Whois. As new versions of commonly used clients appear, this will rapidly become unnoticeable to the average user.
Registrants will as time goes on notice decreased latency in getting registry add/modify/deletes they commit through their registrars into the public DNS and Whois infrastructure. Initial service levels commitments are to maintain the current 12-hour cycle for Whois and zone file changes, but it is also expected that significant progress will be made within the first six months in reducing that latency.
Internet users seeking resolution for .org names will see literally no change at first, as VeriSign's nameservers will continue to serve the .org zone. As our servers are added and zone data refresh cycles accelerate beyond the initial commitment of 12-hour latency, changes to domain name information will be reflected in the global DNS and Whois services much faster.
We will require VeriSign Registry cooperation in the following areas.
We will generate a zone file at least once every 12 hours. This zone must be transferred to the GTLD-SERVERS.NET cluster of name servers. As we transition our own nameservers to replace the individual machines in the cluster. ICANN and VeriSign will need to coordinate the update of the ROOT zone with the newly deployed .org nameservers.
During the process where by VeriSign stops accepting SRS transactions for .org and we start accepting the transactions, VeriSign will need to discontinue service for the .org registry. Also, should there be a massive failure during the transition and the transition needs to be reversed in favor of another transition date, VeriSign will need to be able to cause their systems to resume accepting SRS transactions for .org.
VeriSign will need to compile an .org Registry Data Dump on several occasions. The dump must contain all relevant data so that we can properly populate the registry for seamless transition. The Dump should contain, but not be limited to, the following data sets: Registrar to Domain associations, domain status and domain to name server associations with any appropriate glue records.
VeriSign will have to create these data sets and make them available to our registry over the Internet via secure methods such as SFTP or SCP on several occasions.
VeriSign will also have to update their Whois so that it emits a referral for any .org name queried. A sample of an appropriate referral would be as follows:
C: example.org\r\n S: Domain names in the .com, .net, and .org domains can now be registered S: with many different competing registrars. Go to http://www.internic.net S: for detailed information. S: S: .org Domains are no handled by the .org registry administered by S: the Internet Software Consortium. See http://nic.isc.org for more S: information. S: S: Domain Name: EXAMPLE.ORG S: Whois Server: whois.isc.org S:\r\n
For complete management of the currently registered .org namespace we will require VeriSign Registry to transfer the domain mltbd.org to us so we can continue to manage the Multilingual RACE Encoded domain registrations currently registered in the .org namespace. For a complete overview on IDN transition refer to section on IDN Transmigration of this proposal.
VeriSign must provide complete specifications for the SRS (RRP and, if in production, EPP) server software implementations, including but not limited to, business logic for grace periods and billing, email templates for notifications, and any functional implementation used in the registry but not documented in RFC 2832 or one of the EPP Internet-Drafts
VeriSign will need to provide complete sources of the Server software, scripts and associated documentation and build tools for SRS protocol implementations.
Provide mutually agreed upon standard protocol mechanism or functional equivalent to transmit DNS additions, deletions, and modifications to the .org zone while some .org Nameservers are managed by VeriSign. The standard protocol mechanism must be at least more robust than that stated in .
We have extensive experience performing similar transitions and deep familiarity with the current operating environment. Our team members have:
For the transition period, the goal is to complete the transition within the schedule allotted with minimal downtime and no after-effects. In the plan we've put forward, questions could include in the short term:
After the transition period, the goal is to run a stable .org registry that meets the performance and functionality criteria specified in this proposal and in a subsequent agreement with ICANN. Specific criteria could include:
| TOC |
We will regularly publish many of the operational statistics to the general public. We will designate various members of staff to participate in the gTLD Registries constituency and work within the DNSO on Consensus Policy Development. A Policy Compliance Officer staff person will be designated to work directly with ICANN management on issues of compliance and best industry practice.
We will generate and submit to the ICANN Office of Policy Compliance the following reports:
| TOC |
Neither ISC nor IMS will be a registrar. We will not compete with our customers. Our first priority is to provide stable, responsive, and fair service to our customers and to the registrants in the .org TLD.
It is the goal of this policy to ensure that:
We will at all times operate as a trusted neutral third-party provider of DNS Registry Services. We recognize that domain names are the means by which businesses, consumers, and individuals gain access to, navigate, and reap the benefits of the global Internet. These benefits cannot be fully realized, however, unless DNS resources are administered in a fair, efficient, and neutral manner that makes them available to all parties desiring to provide DNS services. To ensure the provision of neutral Registry Services, We will comply with the following Code of Conduct.
Neither us nor any of our subcontractors will, directly or indirectly, show any preference or provide any special consideration to any company, person or entity that is a DNS registry provider or registrar services provider, as those terms are defined by ICANN.
All registrars accredited by ICANN who are authorized to register domain names in the .org registry shall have equal access to Registry Services provided by us.
We and our subcontractors shall not in any way attempt to register domain names in their own right, except for names designated for operational purposes. In its monthly report to ICANN, we shall include a list of all names designated for operational purposes.
Any subcontractor, affiliate, or other related entity that also operates as a provider of registrar services shall maintain separate books of account with respect to its registrar operations.
Neither us, nor our directors, subsidiaries, affiliates, or other related entities shall have access to user data or proprietary information of a registrar served by us, except as necessary for registry management and operations.
We will ensure that no user data or proprietary information from any registrar are disclosed to its affiliates, subsidiaries, or other related entities, except as necessary for registry management and operations.
Confidential information about our business services will not be shared with employees of any DNS services provider, except as necessary for registry management and operations.
We will conduct internal neutrality reviews on a regular basis. In addition, we may mutually agree with ICANN on an independent party that ICANN may hire, at ICANN's expense, to conduct a neutrality review of our operations, ensuring that we comply with all the provisions of this Registry Operator Code of Conduct. The neutrality review may be conducted as often as once per year. We will provide the analyst with reasonable access to information and records appropriate to complete the review. The results of the review will be provided to ICANN.
We plan a complete transition to a Thick EPP based Registry. Our plan will be carried out through three Phases. The first, Phase I, involves seamless migration to our RRP based .org registry. Phase II involves dual concurrent support of EPP and RRP. During this phase registrars migrate from RRP to EPP. Since our current database schema supports all the requirements for implementing EPP and RRP, we are confidant that an EPP implementation can be developed and installed within the 135-day time frame after the EPP documents make it to Proposed Standard. During Phase II, we will announce the end-of-life date for RRP Registry support after consulting the registrar community and ICANN. In Phase III, we will assist registrars in migrating to a thick EPP based registry. Phase III consists of registrars populating the registry with contact information and associating the contacts with the appropriate domain names.
for a complete discussion of how Transfers, Deletes and Grace periods work during the transition please see [C18.1] Steps of Proposed Transition.
C23. and C24. Intentionally omitted.
| TOC |
The following services will be offered for fee:
We believe the price to register or renew a name in the .org registry should not be lower than the lowest price charged for other TLDs, as that simply encourages speculation. However, the price should not be higher: noncommercial organizations should not pay more than other types of registrants. We will monitor the market and on a quarterly basis will adjust our prices accordingly.
Our planning assumptions are that the wholesale price for domain names will go down 10% per year over the 5-year period. Based on our analysis of market conditions:
The difference in price is based on our costs for debt financing of the initial startup phase of the .org registry. We're perfectly happy to accept a lower startup price if the other TLD registries have similar price adjustments.
Stability of the .org registry function is our first priority. As detailed in the accompanying Consolidated Pro Forma Financial Statements, we believe that stability can be achieved even if the wholesale price of registering a domain name goes down significantly faster than 10% per year.
The following services will be offered without fee:
Please see Performance Specification Summary for a summary of our service level targets for production DNS, Whois, and SRS services. We regard these proposed metrics, based on common practice in the Internet services industry, as a starting point for quantifying the performance and capabilities of the registry. Other appropriate metrics will be developed in consultation with ICANN and the registrar community.
The initial set of metrics is described in more detail below.
In addition we will strive to develop and maintain the strictest performance specification for servicing SRS transactions in either RRP or EPP and for servicing the public's DNS or Whois queries. Furthermore we will regularly publish the statistics and raw data for full disclosure of our operational performance.
Definitions of terms included below shall be as described in [C17.13] System Reliability.
Processing time is a critical component in a transaction-based service like the SRS. Processing Time measures the quality of service while the registry is Available. Processing time refers to the amount of time it takes to process a single request.
Processing Time specification for Add, Modify and Delete is three (3) seconds for 95% of the transactions processed for a Monthly Time-frame. That is 95% of the Add, Modify and Delete commands will take three (3) seconds or less from the time the SRS received the request until the SRS emits a response.
Processing Time Specification for a Check command is 1.5 seconds for 95% of the transactions processed in a Monthly Time-frame. That is, 95% of the Checks will take 1.5 seconds or less from the time the SRS received the request until the SRS emits a response.
Processing Time Specification for a Whois query is 1.5 seconds for 95% of transactions. That is, 95% of Whois queries will take less than 1.5 seconds from the time the Whois server receives the request until it emits a response.
Processing Time Specification for Domain Name Resolution is 150 milliseconds for 95% of transactions. That is, 95% of nameserver resolutions will take less than 150 milliseconds from the time the server receives a query until it emits a response.
Processing Time Specification for DNS Updates is 5 minutes for 95% of transactions. That is, 95% of all updates applied to data to be reflected in the published .org zone will be published in less than 5 minutes from receipt of the successful SRS transaction from a registrar.
Processing Time Specification for Whois Updates is 5 minutes for 95% of transactions. That is, 95% of all updates applied to data to be reflected in the published port 43 Whois service will be published in less than 5 minutes.
As previously discussed another critical parameter of service availability for the registry is the update frequency of the publicly available information provided by the Whois and DNS services. Our DNS architecture will operate at a normal update latency of 5 minutes for 95% of updates on a monthly basis, with a service goal of 3 minutes for the great majority of updates and 99.9% of updates in 15 minutes or less. The Whois service will be held to a similar standard, as described in Performance Specification Summary.
As noted above in Performance Metrics, we are fully prepared to meet the Cross-Network Nameserver Performance Requirements as described by ICANN, which are based on an expectation of less than 10% packet loss and less than 300ms round trip time between query and response for DNS queries sent from diverse locations in the public Internet.
C29. Intentionally omitted.
| TOC |
Our proposal would provide ICANN and the public with the first registry operator operating solely for the public benefit. We have years of experience operating this type of infrastructure and have provided many of the core functions on which registry operators and registrars depend.
Selection of our team to operate the .org registry will have a strong ripple effect. We will enhance competition at the registry level because of our strong commitment to keep prices as low as possible as detailed in [C26] Maximum Price. Our commitment to provide freely available software in binary and source format for both registrar and registry solutions will have a strong impact on competition, particularly at the registry level. Our team is well known for production-quality solutions and our software will enable new registries to quickly enter the market, operating in either the public or some private interest.
We provide public solutions and operate public services. Our team views our role as policy neutral. For example, if ICANN wished to greatly enlarge the number of TLDs available, our freely available software would allow other organizations to operate registries or to have those registries quickly and easily hosted on our own operating environment. In summary, we can help facilitate and support an environment with more registry operators, more TLD policy bodies, and more choice for consumers. We can do so by setting a Best Current Practices standard of how to operate a rock-solid registry for the .org TLD.
Neither the applicant nor any entity identified in item C13 operates a DNS registry having more than 500,000 registered names. On the other hand, we've helped operate some of the largest databases (the EDGAR and Patent database involved tens of millions of documents) and busiest services (e.g., the "F" root server) on the Internet.
We have no such affiliations.
C34. Intentionally omitted.
| TOC |
Our team has worked the vast majority of our careers in the noncommercial Internet user community. Our program managers and board have over 250 years of collective public service to the Internet between them. Our program managers will have direct and immediate involvement in the day-to-day operations of the registry, and our staff and volunteers usually provide a response time to incoming e-mail that rivals the response times we promise for core .org services in Performance Specifications.
Because we operate production services in the public eye, we have a very direct and immediate communications pipeline with our users. If something isn't working or could be working better, we get immediate feedback.
We will operate the .org registry as a fully public process. Our code will be public from very early releases, all enhancements to our service will be fully vetted by open public forums and IETF review, and our support functions will have the direct involvement and supervision of our program managers.
We will operate a variety of web sites and email services that are aimed at our various constituencies. In addition to the extensive support infrastructure for registrars, we will build a web portal for registrants in the .org TLD that will provide our end users with a direct communication channel with the .org registry and a public forum for discussions of our operations.
One of our primary goals is responsiveness to noncommercial organizations around the world. We believe that our constituencies range from formal organizations, such as charted NGOs and 501(c)(3) non-profits, to loose collectives and unincorporated groups, such as open source developers and many other active communities on the Internet. We participate extensively in public forums, both Internet-specific and general-purpose, and we intend to make the .org TLD a dynamic, responsive home to these groups.
In terms of formal advisory bodies, we spent a great deal of time in the bid preparation process attempting to formulate charters for a variety of advisory bodies. We felt it important that any advisory body have real teeth and not simply serve in a token figurehead role. After a great deal of deliberation, we determined that the best way to keep operational stability for the .org registry and still maintain responsiveness is a five-part strategy:
In addition, we intend to seek formal partnerships with a variety of noncommercial organizations. We have already signaled our Intent to Donate to the Internet Society. We will work with a wide variety of organizations, both within Internet infrastructure and in the rest of society, to make the .org public utility serve the needs of the public.
| TOC |
While we must commend and compliment ICANN for the clear and complete proposal process in the competition for the privilege of running the .org registry, we respectfully submit that with multiple bids contending for this opportunity, the global Internet community will want to make a choice based on an examination of the options that are available to them.
We would thus encourage ICANN and the Internet community to examine all the bids and make a decision after a careful assessment of the relative merits of all the options. We have made available a page < click here > on the World Wide Web where supporters of our bid, after they've examined all the facts, to signal their support for the IMS/ISC bid to make .org a public trust at <http://trusted.resource.org/> We would encourage ICANN to watch this and other URLs for evidence of public support.
While we do feel that it is premature to summarize public support for our bid before it is public, initial indications are that noncommercial organizations and the general Internet community view the service we are offering to provide very positively. A large number of organizations have asked for briefings, and we begin the briefing process for those organizations immediately after our bid is public. Early evidence of community support in public forums such as The New York Times, Slashdot, and ICANN Watch has been quite positive.
C37. Intentionally omitted.
| TOC |
A series of steps will be taken that will substantially differentiate the .org TLD from gTLDs and ccTLDs:
Four aspects of our work will be particularly important in differentiating the .org TLD:
Our core operation includes intensive work on tools such as registry software and registrar software. We will be constantly improving our tools as standards evolve and as our customers teach us better ways to do things. The .org TLD will receive a series of improvements in performance, stability, and functionality over time by a team of experienced service operators and software developers.
Our advanced development program, which is under the direction of Carl Malamud, Rebecca Malamud, and Marshall T. Rose will provide a long horizon, developing ways to substantially improve core functions. It is important to note that we do not view the .org TLD as a guinea pig: all new innovations are published first as prototypes, then submitted to an internal reality check, then submitted to the IETF as Internet-Drafts with working code. Only after consensus is reached and operational experience achieved will changes be proposed to the community on how a registry might operate.
An example of our advanced development program can be found in a recently submitted Internet-Draft on Assigned Names and Number Allocation (ANANA). In this work and in the software we have written to implement the ANANA protocols, we demonstrate how a series of specifications and protocols can be used to automate namespace management and to provide a clean separation between the policy aspects of allocating names and the technical aspects of access control, validation of incoming requests for allocation, and distribution of results. Our work is based on some extensions to the XML protocols to add access control capability to logical namespaces and has service specifications that allow batch and interactive modes of accessing the service.
As a proof of concept of the ANANA concepts, we have applied them to a variety of core Internet namespaces, including the IANA registries. It is our hope to begin applying these same concepts to the concept of personal and organizational namespaces. If our research and implementation proves successful, we will attempt to apply the work to the modernization of existing personal and organizational registry solutions, such as Whois.
Again, it is important to note that the advanced development aspect of our work is separated from the core operations functions. A "5 nines," rock-solid operational service is the goal for our operation of the .org TLD. Our advanced development is but one of many sources of improvements to how registries operate, and when it comes to modifications in the core service we look to our customers, other registries, standards bodies, and ICANN for guidance.
The marketing of .org is the third method by which we differentiate this TLD. We have strong roots in the noncommercial world, our team has several prolific writers and public speakers, and we have very strong experience using the Internet to reach out to new communities. As the operators of the .org TLD, we intend to apply those skills with vengeance to make .org a dynamic, useful home for the noncommercial organizations of the world.
Deep domains were the original intention of the DNS architects. They thought most users of the Internet would occupy 3rd and 4th levels of the domain hierarchy. For example, Marshall T. Rose registered his domain name under dbc.mtview.ca.us, for the Mt. View subdomain of the California subdomain of the U.S. TLD. Over time, it was thus with some surprise that the DNS architects saw their system evolve from a tree into a bush.
Our deep domains program will attempt to develop well-known resources in the .org TLD. For example, our own resource.org domain includes three well-developed branches: public.resource.org, bulk.resource.org, and xml.resource.org. We intend to develop media.org, phone.org, fax.org, and resource.org into utilities for the general public. We will also work with other .org registrants to encourage them to develop their domains to include broad communities of users or to become general-purpose public utilities.
In sum, a well-run public utility responsive to the needs of users and able to achieve both stability and innovation is the differentiation we propose for the .org TLD.
C39. Intentionally omitted.
| TOC |
Our financial analysis in the attached Consolidated Pro Forma Financial Analysis details our revenue and expense projections under various market conditions. Our primary goal is stability of the .org TLD service. As such we have set a minimum of US$500,000 in operating capital for each month of operation. Our startup costs are financed by our own capital, supplemented by a US$2.5 million line of credit of which we anticipate drawing US$1.5 million for startup costs, leaving a substantial cushion for changes in market conditions.
We would use the VeriSign endowment to more quickly achieve our goals for stability. As detailed in [C25] Registry Services for Fee, this would result in lower costs to consumers as well as increased stability of the .org TLD.
We would also use the VeriSign endowment to accelerate deployment of our core deliverables, including the production of freely available software for registrars and registries, and to more quickly productize innovations such as namespace management from our advanced development program.
We would use also use the VeriSign endowment to accelerate our Internet Public Works Program, which is used to fund programs that differentiate the .org registry and produce solutions for core Internet infrastructure. For example, use of the endowment would accelerate the deployment of BIND 9 and secure DNS.
Finally, we would use the VeriSign endowment to work with other organizations on the net to provide services that benefit the .org registrants and core Internet infrastructure. An example of such cooperation is detailed in the accompanying Intent to Donate in which we certify our intention to use 8% of gross revenues to fund IETF and IAB activities in the Internet Society. Program Managers, in close cooperation with .org registrants, registrars, and registries, will develop proposals for other such programs to be reviewed in a public comment period and then decided by our board of directors.
We are a non-profit entity and our operation of the .org registry as a public service with benefit to .org registrants, the marketplace, and the broader Internet community at large, is entirely consistent, indeed is the essence of, the terms of the endowment.
We are fully prepared and capable of operating the .org registry without the VeriSign endowment, but we believe that our use of those funds will provide greater public benefit to current .org registrants and to other registry operators, including future operators of the .org TLD.
| TOC |
Attached are the following documents for the Internet Multicasting Service.
Attached are the following documents for the Internet Software Consortium:
Please see previous section C50.1.
For the Internet Multicasting Service:
For the Internet Software Consortium:
For account numbers and contact names, please contact us.
Attached are the following documents:
A full on-line due diligence area is maintained by the Internet Multicasting Service. Please contact us for login information.
Please see the attached Joint Statement of Authority.
Please see [C36] Support for Proposal and http://trusted.resource.org/.
| TOC |
By signing this .org Proposal, the undersigned certifies (a) that he or she has authority to do so on behalf of the applicant and, (b) on his or her own behalf and on behalf of the applicant, that all information contained in this proposal, and all documents attached to this proposal, is true and accurate to the best of his/her/its knowledge and information. The undersigned and the applicant understand that any material misstatement or misrepresentation will reflect negatively on the application of which this proposal is a part and may cause cancellation of any delegation of a top-level domain based on that application.
/Carl Malamud/ Signed Carl Malamud Chairman Internet Multicasting Service June 16, 2002
| TOC |
|||Hollenbeck, S. and M. Srivastava, "NSI Registry Registrar Protocol (RRP) Version 1.1.0", RFC 2832, May 2000.|
|||Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.|
|||Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.|
|||Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.|
|||Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985.|
|||Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.|
|||Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.|
|||Mockapetris, P., "DNS encoding of network names and other types", RFC 1101, April 1989.|
|||Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.|
|||Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection and Operation of Secondary DNS Servers", BCP 16, RFC 2182, July 1997.|
|||Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.|
|||Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.|
|||Waitzman, D., "IP over Avian Carriers with Quality of Service", RFC 2549, April 1999.|
|||Hollenbeck, S., "Extensible Provisioning Protocol", draft-ietf-provreg-epp-06 (work in progress), January 2002.|
|||Hollenbeck, S., "Extensible Provisioning Protocol Domain Name Mapping", draft-ietf-provreg-epp-domain-04 (work in progress), January 2002.|
|||Hollenbeck, S., "Extensible Provisioning Protocol Host Mapping", draft-ietf-provreg-epp-host-04 (work in progress), January 2002.|
|||Hollenbeck, S., "Extensible Provisioning Protocol Contact Mapping", draft-ietf-provreg-epp-contact-04 (work in progress), January 2002.|
|||Hollenbeck, S., "Extensible Provisioning Protocol Transport Over TCP", draft-ietf-provreg-epp-tcp-04 (work in progress), January 2002.|
| TOC |
|||Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987.|
|||Malamud, C. and M. Rose, "Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures", RFC 1528, October 1993.|
|||Malamud, C. and M. Rose, "Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies", RFC 1529, October 1993.|
|||Malamud, C. and M. Rose, "Principles of Operation for the TPC.INT Subdomain: General Principles and Policy", RFC 1530, October 1993.|
|||Rose, M., "Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures", RFC 1703, October 1994.|
|||Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A Means for Expressing Location Information in the Domain Name System", RFC 1876, January 1996.|
|||Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.|
|||Rekhter, Y., Thomson, S., Bound, J. and P. Vixie, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.|
|||Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.|
|||Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.|
|||Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.|
|||Eastlake, D., "DNS Request and Transaction Signatures ( SIG(0)s)", RFC 2931, September 2000.|
|||Vixie, P. and D. Wessels, "Hyper Text Caching Protocol (HTCP/0.0)", RFC 2756, January 2000.|
|||Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.|
|||Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.|
|||Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.|
|||Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.|
|||Rose, M., "On the Design of Application Protocols", RFC 3117, November 2001.|
|||New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, November 2001.|
| TOC |
|||Abley, J., "Edge Policy Propagation Control", draft-jabley-eppc-00 (work in progress), February 2002.|
|||Manning, B., Vixie, P. and E. Guttman, "The DISCOVER opcode", draft-dnsext-opcode-discover-00 (work in progress), April 2002.|
|||Rose, M., "A Transient Prefix for Identifying Profiles under Development by the Working Groups of the IETF", draft-mrose-beep-transientid-02 (work in progress), March 2002.|
|||Rose, M., Crocker, D. and G. Klyne, "The APEX Presence Service", draft-ietf-apex-presence-06 (work in progress), January 2002.|
|||Rose, M., Masinter, L. and S. Hollenbeck, "Guidelines for The Use of XML within IETF Protocols", draft-hollenbeck-ietf-xml-guidelines-04 (work in progress), June 2002.|
|||Rose, M., Crocker, D. and G. Klyne, "The Application Exchange Core", draft-ietf-apex-core-06 (work in progress), January 2002.|
|||Rose, M., "IM Simple Exchange (IMSX)", draft-mrose-simple-exchange-01 (work in progress), January 2002.|
|||Rose, M., Crocker, D. and G. Klyne, "The APEX Access Service", draft-ietf-apex-access-08 (work in progress), January 2002.|
|||Rose, M. and D. Crocker, "Toward a Quantitative Analysis of IETF Productivity", draft-etal-ietf-analysis-00 (work in progress), March 2002.|
|||Rose, M., "The ANANA Datastore", draft-anana-datastore (work in progress), June 2002.|
| TOC |
|||Malamud, C., "DEC Networks and Architectures", February 1989.|
|||Malamud, C., "Ingres", July 1989.|
|||Malamud, C., "Stacks : Interoperability in Today's Computer Networks", October 1991.|
|||Malamud, C., "Exploring the Internet: A Technical Travelogue", October 1992.|
|||Malamud, C., "Analyzing Sun Networks", June 1991.|
|||Malamud, C., "Analyzing DECnet/OSI Phase V", August 1991.|
|||Malamud, C., "Analyzing Novell Networks", July 1992.|
|||Malamud, C., "A World's Fair for the Global Village", September 1997.|
|||Rose, M., "The Open Book: A Practical Perspective on OSI", January 1990.|
|||Rose, M., "The Internet Message : Closing the Book With Electronic Mail (Prentice Hall Series in Innovative Technology)", October 1992.|
|||Rose, M. and D. Lynch, "The Internet Handbook", January 1993.|
|||Rose, M. and K. McCloghrie, "How to Manage Your Network Using SNMP", January 1995.|
|||Rose, M., "The Simple Book: An Introduction to Internet Management, Revised Second Edition", March 1996.|
|||Rose, M. and D. Strom, "The Simple Book", July 1998.|
|||Rose, M., "BEEP: The Definitive Guide", March 2002.|
|||Vixie, P. and F. Avolio, "Sendmail: Theory and Practice", December 2001.|
| TOC |
|||Malamud, C., "http://town.hall.org/", April 1993.|
|||Rose, M. and C. Malamud, "http://www.tpc.int/", August 1993.|
|||Malamud, R. and C. Malamud, "http://mappa.mundi.net/", June 1999.|
|||Internet Software Consortium, "http://f.root-servers.org/", August 1999.|
|||Rose, M., "http://www.beepcore.org/", July 2000.|
|||Malamud, R. and C. Malamud, "http://betterdogfood.com/", July 2000.|
|||Malamud, R., "http://undesign.org/", April 2001.|
|||Malamud, R. and C. Malamud, "http://nate.malamud.com/", April 2001.|
|||Rose, M., "http://xml.resource.org/", July 2001.|
|||Malamud, R. and C. Malamud, "http://bulk.resource.org/", December 2001.|
|||Vixie, P. and F. Avolio, "http://smtp.al.org/", December 2001.|
|||Malamud, R. and C. Malamud, "http://not.invisible.net/", December 2001.|
| TOC |
|Internet Multicasting Service|
|P.O. Box 217|
|Stewarts Point, CA 95450|
|Internet Software Consortium|
|950 Charter Street|
|Redwood City, CA 94063|
| TOC |
| TOC |
On occasion the registry may send e-mail notifications to registrars, as described in Message Passing to Registrars. The machine-readable portions of these e-mails will be formatted as follows.
Message subject: "Receipt of Transfer Request: <domain>.ORG"
Message body as follows:
------------------------------------------------------------ Transfer Request for: Domain Name: <domain>.ORG Requesting Registrar: <textual registrar name> Current Registrar: <textual registrar name> <multi-line human-readable descriptive text> ------------------------------------------------------------
Message subject: "Completion of Transfer Request: <domain>.ORG"
Message body as follows:
------------------------------------------------------------ Notification of Completion of Transfer Request Domain Name: <domain>.ORG Requesting Registrar: <textual registrar name> Current Registrar: <textual registrar name> <multi-line human-readable descriptive text> ------------------------------------------------------------
Message subject: "Auto-Acknowledgement of Transfer Request: <domain>.ORG"
Message body as follows:
------------------------------------------------------------ Notification of Auto-Acknowledgement of Transfer Request: Domain Name: <domain>.ORG New Registrar: <textual registrar name> Previous Registrar: <textual registrar name> <multi-line human-readable descriptive text> ------------------------------------------------------------
Message subject: "Non-Completion of Transfer Request: <domain>.ORG"
Message body as follows:
------------------------------------------------------------ Notification of Decline of Transfer Request Domain Name: <domain>.ORG Requesting Registrar: <textual registrar name> Current Registrar: <textual registrar name> <multi-line human-readable descriptive text> ------------------------------------------------------------
| TOC |
The following template describes the machine-parsable portions of the output from whois.isc.org for queries corresponding to domains with no associated contact objects.
------------------------------------------------------------ Whois Server Version <version> <multi-line human-readable descriptive text> Domain Name: <domain>.ORG Registrar: <textual registrar name> Whois Server: <referral (registrar) Whois server name> Referral URL: <referral (registrar) URL> Nameserver: <hostname> Nameserver: <hostname> <0 to 11 additional Nameserver records> Updated Date: <DD-MMM-YYYY> <<< Last update of Whois database: <date in common UNIX format> <<< <multi-line human-readable descriptive text> ------------------------------------------------------------
| TOC |
The following template describes the machine-parsable portions of the output from whois.isc.org for queries corresponding to domains with associated contact objects.
------------------------------------------------------------ Whois Server Version <version> <multi-line human-readable descriptive text> Domain Name: <domain>.ORG Registrar: <textual registrar name> Referral URL: <referral (registrar) URL> Nameserver: <hostname> Nameserver: <hostname> <0 to 11 additional Nameserver records> Updated Date: <DD-MMM-YYYY> Registrant name: <textual registrant name> Registrant street 1: <address information> Registrant street 2: <address information> Registrant city: <address information> Registrant region: <address information> Registrant code: <address information> Registrant country: <address information> Admin name: <textual registrant name> Admin e-mail: <e-mail address> Admin phone: <phone number> Admin fax: <phone number> Admin street 1: <address information> Admin street 2: <address information> Admin city: <address information> Admin region: <address information> Admin code: <address information> Admin country: <address information> Technical name: <textual registrant name> Technical e-mail: <e-mail address> Technical phone: <phone number> Technical fax: <phone number> Technical street 1: <address information> Technical street 2: <address information> Technical city: <address information> Technical region: <address information> Technical code: <address information> Technical country: <address information> <<< Last update of Whois database: <date in common UNIX format> <<< ------------------------------------------------------------
| TOC |
Carl Malamud created the first Internet radio station and put the SEC's EDGAR database on-line. A serial social entrepreneur, he's helped establish and lead a number of non-profit organizations, including the Internet Multicasting Service and the Internet Software Consortium. He was founding CEO of two Silicon Valley startups which he led through several rounds of financing, was a visiting professor at the MIT Media Lab and Keio University, and has 20 years experience leading large-scale computer networking projects in the public and private sectors. Carl is the author of 8 books, numerous articles, and a few RFCs.
Rebecca Malamud's interface design and creative work has been profiled by numerous organizations, including The Art Directors Club of New York, Communication Arts, USA Today, CNN, The New York Times, The Wall Street Journal, and ABC News. A career creative hell-bent on true community, Rebecca has led the creative and community efforts of the Internet Multicasting Service since 1995 including primary operating responsibility for projects such as the Internet 1996 World Exposition, Mappa.Mundi Magazine, north.pole.org, and many others. She has worked in executive and creative direction positions in numerous organizations ranging from Silicon Valley startups to traditional print shops and is responsible for a large number of community-based Internet projects.
Becky's latest creation is IMS Signals, the first glimpse of an architecture for conversational applications that will form the form the foundation for the IMS NetTopBox and Core Technologies Programs.
Paul Vixie has been contributing to Internet protocols and UNIX systems as a protocol designer and software architect since 1980. Early in his career, he developed and introduced sends, proxynet, rtty, cron and other lesser-known tools. Today, Paul is considered the primary modern author and technical architect of BINDv8 the Berkeley Internet Name Domain Version 8, the open source reference implementation of the Domain Name System (DNS). He formed the Internet Software Consortium (ISC) in 1994, and now acts as Chairman of its Board of Directors. The ISC reflects Paul's commitment to developing and maintaining production quality open source reference implementations of core Internet protocols.
More recently, Paul co-founded MAPS LLC (Mail Abuse Prevention System), a California non-profit company established in 1998 with the goal of hosting the RBL (Realtime Blackhole List) and stopping the Internet's email system from being abused by spammers. Vixie was also the Chief Technology Officer of Metromedia Fiber Network Inc (MFNX.O).
Along with Frederick Avolio, Paul co-wrote "Sendmail: Theory and Practice" (Digital Press, 1995:2001). He has authored or co-authored several RFCs, including a Best Current Practice document on Classless IN-ADDR.ARPA Delegation. He is also responsible for overseeing the operation of F.root-servers.net, one of the thirteen Internet root domain nameservers.
Suzanne Woolf worked from 1989-2000 at the Information Sciences Institute, where she worked in the Network Division. Her assignments included automation of record keeping for the IANA, operations of the RWhois service for the .US domain, and technical support to a variety of government- and privately-funded projects in network technology development. She served as the Technical Operations Manager for ICANN during its first year of operation. Before joining the Internet Software Consortium as Program Manager, she was Manager of Operations Systems and Support for a large ISP.
Joe Abley has worked in numerous positions as a lead engineer including backbone architecture, design, deployment, and maintenance for the AboveNet/MFN global IP network and technical lead in the early design work which led to the roll-out of Telstra Saturn's (now TelstraClear's) broadband packet VPN infrastructure in New Zealand. He led the design and and deployment of nameserver infrastructure for the AQ, TK and PN country-code top-level domains. Joe was the architect and deployment prime for a high-capacity international network between NZ and the USA for Internet access, using unidirectional satellite broadcast in conjunction with bi-directional under-sea cable, with appropriate latency-sensitive traffic prioritization over the satellite and terrestrial paths.
Joe participates actively in NANOG, NZNOG and the IETF and is author or co-author of publications on Edge Policy Propagation Control, and IPv4 multi-homing and IPv6 multihoming. He is a contributor to OpenBSD, FreeBSD, and ISC BIND.
Luther Brown began his career at CBS, then moved on to NBC News where he produced political and campaign coverage for ten years. He has worked in such diverse areas as speechwriting for the U.S. Secretary of Health and Human Services, developing training material for the Environmental Protection Agency, representing the Wilderness Society, and producing and consulting on broadcast issues for the City of Atlanta. Luther received his law degree from Georgetown University Law Center and pursued doctoral coursework in English at Rutgers.
Brad Burdick has run systems for IMS since 1993. He personally oversaw the operation of the first 24-hour/day streaming audio and video feeds on the Internet, turned EDGAR and Patents into the world's largest WAIS database and then converted most of the U.S. government into XML, and in 1996 helped activate the first Internet DS3 over the Pacific ocean, part of a network that included a 2-terabyte disk farm distributed in 8 countries.
Michael Graff is a lead contributor to BIND 8, BIND 9, and NetBSD. He is the author of loadable device modules for file systems under NetBSD and he has done device driver programming for DS3, HSSI, and T1 interface cards for NetBSD, FreeBSD, BSDI, and linux. In addition to his work on BIND at ISC, Michael coordinated over 1200 individuals for the RSA-129 project, which factored a large cryptographically secure number. Prior to working for ISC, Michael was the author of the first generation of PGP Key Servers, which were in use at over 50 sites in 10 countries. He was also the coordinator of the PGP Network, the collection of PGP Key Servers.
Lynda McGinley is the Executive Director of the Internet Software Consortium. Lynda has been active in system and network administration for the past 16 years, working at the University of Colorado, Qwest Advanced Technologies, and Network Daemon Associates. She has been managing the USENIX terminal room for the past 5 years. Lynda has been President of the Board of Directors of the Colorado Internet Cooperative, and a member of the Board of Directors of XOR Networking Engineering, Inc.
Lynda is a contributing author of the third edition of the UNIX System Administration Handbook. She is professionally active in SAGE, USENIX, and FRUUG.
Rick H. Wesson is a technical expert in the areas of DNS & Registry Registrar Protocols; Automation of Provisioning Systems; and, Online Fraud Detection. He has the following affiliations:
Rick has consulted in the San Francisco Bay Area since 1993 working for a variety of technology companies. In 1999, he was the technical lead for CORE, one of the first testbed registrars. In 2000-2002, he helped build the technical infrastructure of many ICANN accredited registrars, including Name Secure, Domain Bank, PSI-Japan, TuCows, Catalog.com, and other DNS related companies like Nominum and Name Zero. He continues to provide protocol implementations for registrars for RRP, EPP, and Whois.
Rick Adams is the founder of UUNET Technologies and the author of RFC 1036. He serves on the board of the Internet Multicasting Service.
Dave Farber is the Alfred Fitler Moore Professor of Telecommunication Systems in the School of Engineering and Applied Sciences at the University of Pennsylvania and Professor of Business and Public Policy at the Wharton School. A former Chief Technologist for the FCC, he is the creator of the interesting-people list. Dave is a member of the board of the Internet Multicasting Service.
Teus Hagen has been involved in many aspects of the Internet and has been a key participant in the growth of the net in Europe. He was the principal founder of the Dutch UNIX users group NLUUG and the European UNIX Users Group (EUUG), the umbrella organization for 26 national UNIX users groups and the European sister organization of USENIX.
In 1994, he joined the NLnet Foundation as President. NLnet was reorganized as a corporation with the Foundation as sole shareholder. Currently, he is the general director and president for the NLnet Foundation. In 1997 the NLnet ISP Corporation was sold to UUnet/Worldcom, at which time the Foundation began leading and sponsoring Internet technology research and development projects in Holland, Europe and the world, including funding for the Internet Software Consortium.
Daniel Karrenberg has helped to build the European Internet since the early 80s. As one of the founding members of the German Unix Users Group he has been involved in the setting up of EUnet, a pan-European coperative network providing electronic mail and news to businesses and academic institutions all over Europe. Karrenberg is one of the founders of RIPE, the IP coordination body for Europe and surrounding areas. In 1992, he established RIPE NCC, the first regional internet registry providing IP numbers to thousands of Internet service providers in more than 90 countries. Karrrenberg led the RIPE NCC until 1999; he currently helps to develop new RIPE NCC services. Recently his contributions have been recognised by the Internet Society with its "Jon Postel Service Award." Karrenberg's current interests include measurements of Internet performance and routing as well as security within the Internet infrastructure. In general he likes building new and interesting things. Daniel is a member of the board of the Internet Multicasting Service.
Evi Nemeth is retired from the Department of Computer Science at the University of Colorado and is a part-time researcher at CAIDA, the Cooperative Association for Internet Data Analysis at the University of California's San Diego Supercomputer Center. She has coordinated MBONE broadcasts from the IETF, INET, and USENIX since 1993. She has served on the boards of directors of the Internet Software Consortium and the Colorado Internet Cooperative. Evi's current research focuses on DNS behavior and performance at the root nameserver level, including recent publications on DNS Root/gTLD Performance Measurements and DNS Measurements at a Root Server.
A member of the IMS Board of Directors since 1993, Marshall lives with internetworking technologies as a theorist, implementer, and agent provocateur. He is held accountable for the design, specification, and implementation of several Internet-standard technologies, and is an author of over 60 of the Internet's Request for Comment (RFC) Series. He is the author of several professional texts on network management, electronic mail, directory services, and application framing protocols. His latest book is The Beep Book. Marshall chairs the Protocol Advisory Board, which provides a technical reality check to work products before they are submitted as Internet-Drafts and participates actively in the Core Technologies Program. His most recent work for IMS has been definition of the ANANA Datastore.
Paul Vixie is a member of the board of the Internet Software Consortium.
Stephen Wolff taught Electrical Engineering in The Johns Hopkins University for ten years and subsequently spent fifteen years leading a computing- and network-related research group at the U.S. Army Research Laboratory. In 1983 he took a sabbatical half-year as a Program Director in the Mathematics Division of the U.S. Army Research Office.
From 1986 to 1995 he was Director of the Division of Networking and Communications Research and Infrastructure (NCRI, now ANIR) at the U.S. National Science Foundation, responsible for the NSFNET, the NSF participation in the National Research and Education Network element of the HPCC program, and NSF's support programs for basic research in networking and communications. While at NSF, he was among the founders of the inter-agency and international research networking management and advisory structure whose descendants today include the Large-Scale Networking (LSN) working group and the President's Information Technology Advisory Committee (PITAC).
He left Federal service and joined Cisco Systems in 1995, where he currently directs the Advanced Internet Initiatives Division with responsibility for Cisco's participation in Internet2, the U.S. government's Next Generation Internet and IT2 programs, and similar and related projects both domestically and abroad. Dr. Wolff holds two patents and is the author of several dozen technical reports and articles; he a member of AAAS and ACM, a Pioneer Member of the Internet Society, and a Life Member of IEEE.
Pindar Wong (email@example.com) is the immediate past Chairman of the Asia and Pacific Internet Association, the Executive Committee Chairman of the Asia Pacific Regional Internet Conference on Operational Technologies, Advisor to the Asia Pacific Networking Group, and Member of the Editorial Advisory Board of Cisco Systems' Internet Protocol Journal. He is also the Chairman of VeriFi (Hong Kong) Ltd., a discrete Internet infrastructure consultancy. Previously he co-founded Hong Kong's first licensed ISP in 1993, was the alternate chair of Asia Pacific Network Information Centre, and was appointed by the Internet Architecture Board to the Policy Oversight Committee. He served as Vice Chairman of ICANN's Board of Directors from 1999-2000 and Vice-Chairman of the At Large Study Committee 2001-2002. Prior to his involvement in commercial Internet services, he was a doctoral candidate and Sir Edward Youde research fellow at the Hong Kong University of Science and Technology.
| TOC |
This document is available in the following formats:
|TOP||THE .ORG TLD IS A PUBLIC TRUST||»|