idnits 2.17.1 draft-postel-iana-itld-admin-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1996) is 10201 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 iana-itld-admin-00 J. Postel 2 ISI 3 May 1996 5 New Registries and the Delegation of International Top Level Domains 7 draft-postel-iana-itld-admin-00.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months. Internet-Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet- 19 Drafts as reference material or to cite them other than as a working 20 draft or work in progress. 22 To learn the current status of any Internet-Draft, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 25 munnari.oz.au. 27 Abstract 29 This document describes a proposed policy, procedure, and control 30 structure for the allocation of additional top-level domains. 31 Further it discusses the issues surrounding additional international 32 top level domains (iTLDs) and registries, qualification proposals for 33 operating such a registry, and justifications for the positions 34 expressed in this paper. 36 This document describes policies and procedures to 38 o allow open competition in domain name registration in the 39 iTLDs, 41 o and provide the IANA with a legal and financial umbrella 43 Note that while cooperation between competing iTLD registries is 44 allowed, it is not required. This is specifically not assumed in 45 this proposal, and is considered to be an operational aspect of a 46 registry best determined, and coordinated, by contractual agreements 47 between private interests. 49 The NEWDOM, IETF, and related mailing lists are encouraged to read, 50 and comment, on this material. Presuming a consensus can be found 51 within these audiences, the distribution of this memorandum should be 52 expanded to include general commentary from the Internet community. 54 1. Introduction 56 For the purpose of delegation, the top level domains (TLDs) fall into 57 the categories listed below. While all are described to provide 58 context, only the last is the subject of this document. 60 1.1. National TLDs 62 The two-character namespace is, and will remain, reserved for ISO 63 country codes under existing accepted Internet RFCs. 65 National TLDs such as AF, FR, US, ... ZW are named in accordance 66 with ISO 3166, and have, in the major part, been delegated to 67 national naming registries. Any further delegation of these TLDs 68 is undertaken by the Internet Assigned Number Authority (IANA), in 69 accordance with the policies described in RFC 1591. 71 It is good practice for these delegated TLD registries to publicly 72 document the applicable management policies and further delegation 73 procedures for these national domains, as, for example, RFC 1480 74 does for the US domain. 76 1.2. US Governmental TLDs 78 1.2.1. Delegation of the GOV TLD is described by RFC 1816, and is 79 under the authority of the US Federal Networking Council (FNC). 81 1.2.2. Delegation of the MIL domain is under the authority of the 82 DDN NIC. See DDS Management Bulletin 9513, dated Nov 7, 1995, 83 "Policy Governing Domain Registration in the '.MIL' and 84 '.SMIL.MIL' Domains" 86 The document can be obtained by either: ftp nic.ddn.mil, cd 87 ddn-news, get bul-9513.txt or http://nic.ddn.mil/ddn-man.html. 89 1.3. Infrastructure TLDs 91 TLDs such as IN-ADDR.ARPA and INT are under the authority of the 92 IANA and may be delegated to others, e.g., IN-ADDR.ARPA is 93 currently delegated to the Internic for day-to-day management. 94 They are created for technical needs internal to the operation of 95 the internet at the discretion of the IANA in consultation with 96 the IETF. See RFC 1591 for general guidance on the use of the INT 97 and ARPA domains. 99 1.4 The EDU TLD 101 Delegation of the EDU domain is under the authority of the FNC and 102 is currently delegated to the NSF which has contracted to the 103 Internic for registration. See RFC 1591 for general guidance on 104 the use of the EDU domain. 106 Over time, the FNC and NSF may decide to use other delegation 107 models, such as those described below for non-governmental TLDs. 109 1.5 The International Top Level Domains (iTLDs) COM, ORG, and NET 111 The iTLDs are generic top level domains which are open to general 112 registration. They are currently delegated to the Internic by the 113 authority of the IANA. See RFC 1591 for general guidance on the 114 use of the COM, NET, and ORG domains. 116 The INT top level domain is also used for a very restricted class 117 of international organizations established by treaties between the 118 governments of countries. See RFC 1591 for general guidance on 119 the use of the INT domains. 121 1.5.1. The intent for these iTLDs is discussed in RFC 1591. 122 Generally, COM is for commercial organizations (e.g., companies 123 and corporations), NET is for the internal infrastructure of 124 service providers, and ORG is for miscellaneous organizations 125 (e.g., non-profit corporations, and clubs). 127 1.5.2. There is a perceived need to open the market in commercial 128 iTLDs to allow competition, differentiation, and change, and 129 yet maintain some control to manage the Domain Name System 130 operation. 132 The current situation with regards to these domain spaces, and 133 the inherent perceived value of being registered under a single 134 top level domain (.COM) is undesirable and should be changed. 136 Open, free-market competition has proven itself in other areas 137 of the provisioning of related services (ISPs, NSPs, telephone 138 companies) and appears applicable to this situation. 140 It is considered undesirable to have enormous numbers 141 (100,000+) of top-level domains for administrative reasons and 142 the unreasonable burden such would place on organizations such 143 as the IANA. 145 It is not, however, undesirable to have diversity in the top- 146 level domain space, and in fact, positive market forces dictate 147 that this diversity, obtained through free competition, is the 148 best means available to insure quality service to end-users and 149 customers. 151 1.5.3. As the net becomes larger and more commercial, the IANA 152 needs a formal body to accept responsibility for the legal 153 issues which arise surrounding DNS policy and its 154 implementation. 156 1.6. This memo deals with introducing new registries for iTLDs and 157 additional iTLDs names, it does not deal with the longer term 158 issue of the management and charter of the current iTLDs (COM, 159 NET, and ORG), or the specialized TLDs (EDU, GOV, MIL, INT, and 160 ARPA). 162 The current iTLDs may come under the provisions of this document 163 when their current sponsorship relationship ends. 165 The specialized iTLDs have such restrictive requirements for 166 registration that they do not play a significant role in the 167 competitive business environment. 169 1.7. Trademarks 171 Domain names are intended to be an addressing mechanism and are 172 not intended to reflect trademarks, copyrights or any other 173 intellectual property rights. 175 Except for brief mentions in sections 6.1, 6.4, and 9.3, 176 trademarks are not further discussed in this document. 178 2. Goals 180 To facilitate administration of the domain name subsystem within the 181 Internet by ensuring that there is an open and competitive 182 marketplace for clients to obtain and subsequently maintain 183 delegation of subdomains within the iTLDs, while preserving the 184 operational integrity of the Internet DNS itself. 186 The specific measures to achieve this objective are as follows: 188 2.1. Provide the IANA with the international legal and financial 189 umbrella of the Internet Society (ISOC), 191 2.2. Allow open competition in domain name registration in the iTLDs, 192 which will then allow registries to charge for their services, 194 2.3. Allow multiple registries to operate cooperatively and fairly in 195 the existing iTLDs and/or other multi-registry iTLDs which may be 196 created, 198 2.4. Facilitate creation of new iTLDs in a fair and useful, but 199 reliable, fashion, 201 2.5. Provide for reliable maintenance of the registrants of an iTLD 202 should the current delegatee no longer wish to maintain it, and 204 2.6. Define iTLD policies and procedures by open methods, modeled on 205 the IETF process and/or using IETF mechanisms when appropriate. 207 3.0 Scope of this Document 209 This document describes the administrative structure for the 210 operation of the iTLDs. While other administrative issues may exist 211 within the broader domain of the DNS, they are not addressed in this 212 document. 214 Specifically: 216 3.1. Only those relationships between the IANA, IETF, and ISOC which 217 are specifically necessary for responsible maintenance of the 218 iTLDs are described. 220 3.2. The Board of Trustees acts for the ISOC, the IAB for the IETF, 221 and the IANA for itself. 223 3.3. Long range maintenance of the IANA is not described; although it 224 is believed that the IANA should draw financial support from a 225 wide community. 227 3.4. The IETF is not directly involved in operation of the net. 228 Hence it serves the iTLD administrative work mainly in a technical 229 capacity, such as the formalization of new protocols and the 230 handling of technical appeals. 232 3.5. The ISOC does not directly operate the net. But it takes legal 233 responsibility for standards processes and some network management 234 processes, manages funds, and participates in the appeals process. 236 3.6. The IANA and any necessary ad hoc groups deal with operational 237 details. 239 3.7. The ISOC, the IETF, and the IANA are not to be legally or 240 financially responsible for the registries. The registries must 241 be responsible for themselves. 243 3.8. Creation of a large staff is not desired. 245 4. Technical Assumptions 247 Further growth within the iTLDs can be accommodated technically, and 248 tools are in evidence to automate much of the process of registration 249 and maintenance of entries within the DNS as well as multiple 250 administrative access to a single delegated domain. 252 4.1. The size of current TLD databases such as COM, while large, is 253 not really a burden on servers, nor is it expected to become so in 254 the near future. 256 4.2. Procedures which allow mutual exclusion for the creation of 257 names within a single TLD are being developed within the IETF's 258 "dnsind" and "dnssec" working groups, and a test implementation is 259 available. 261 4.3. Tools are being developed to ease the processes of registration 262 and running the information servers which are expected of 263 registries. 265 5. The Process 267 5.1. The IANA continues to supervise and control all operational 268 aspects of the iTLDs, and is the second level of the appeals 269 process after the registries (which are the first level). It 270 appoints three members to the ad hoc iTLD group(s). The IANA may 271 directly review appeals and/or it may ask the Internet DNS Names 272 Review Board (IDNB) to participate in the review of an appeal. 273 The IANA has the option of asking the IDNB to review an appeal, or 274 the IANA may handle the appeal itself. 276 As described in RFC 1591 regarding a dispute between parties 277 contending for the management of a national TLD, the IDNB, a 278 committee established by the IANA, will act as a review panel for 279 cases in which the parties can not reach agreement among 280 themselves. 282 Now the role of the IDNB is expanded to include appeals on a 283 technical basis of the process documented in this memo. 285 5.2. The IETF, as part of its normal procedures, publishes documents 286 which describe technical and operational aspects of the domain 287 space including the iTLDs. It also provides an appeals procedure 288 for process issues and appoints two members to the ad hoc iTLD 289 group(s). That is, it reviews appeals that question whether the 290 process was properly followed. 292 5.3. The ISOC provides the legal and financial umbrella, and the 293 final level of the appeal process. It provides an appeals 294 procedure for procedural issues and appoints two members to the ad 295 hoc iTLD group(s). The ISOC assumes legal liability for the 296 process and the iTLDs. The ISOC reviews appeals that question the 297 fairness of the process itself (not the application of the process 298 to a particular case). 300 5.4. The ad hoc working group, for developing procedures and deciding 301 creation of new iTLDs and chartering of registries, consist of 302 seven members appointed by the IANA (3), the IETF (2), and the 303 ISOC (2). 305 5.5. Note that 'ad hoc' means 'for this purpose only.' In this case, 306 a new ad hoc group is created and convened on a periodic basis 307 (probably annual) when needed to change procedures or to review 308 registry and iTLD applications. 310 5.6. It is estimated that approximately ten (10) new registries and 311 thirty (30) iTLDs will be created per year. It is expected that 312 this will continue for the next five years - unless something 313 significant happens to change this plan. In this first year of 314 this plan more new registries may be chartered, perhaps up to 315 fifty (50). 317 5.7. The policies and procedures to be used by the ad hoc working 318 group will be decided by the first ad hoc group in an open process 319 and will be clearly documented. This group will be appointed and 320 convene in in the next few months. It is expected that these 321 policies and procedures will mature over time. 323 5.8. Multiple registries for the COM TLD database, and multiple 324 registries for other (new and old) iTLDs may be created in the 325 future. 327 5.9. New iTLDs and registries will be created over time. This is a 328 direct change to RFC 1591. New iTLDs may be created with a non- 329 exclusive administration arrangement (multiple registries for one 330 iTLD). 332 5.10. The intent is similar to the licensing of radio stations in 333 some countries. 335 5.11. Registries pay for charters, and the fees collected are kept in 336 a fund managed by the ISOC and used for the iTLD process (such as 337 for insurance against an iTLD registry withdrawal or collapse), 338 and possibly to support an evolved future funding model for the 339 IANA. 341 6. Selection of iTLDs and Registries 343 6.1. The New Registries and iTLDs 345 There will be up to fifty (50) new registries, with no more than 346 two thirds (2/3) in the same country, created in 1996, and 347 chartered to operate for up to five years. 349 Up to three iTLDs may be operated by any single organization. 350 Each new registry will choose up to 3 new iTLD names it will 351 manage under its charter. 353 There will be no institution of multiple registries per iTLD in 354 1996 by the ad hoc committee. Registry operators are 355 encouraged to make such arrangements on their own initiative. 357 [In future years, charters may be for a new registry (creating 358 a multiple registry iTLD) for either an existing iTLD or a new 359 iTLD, or for renewing the charter of an existing registry and 360 iTLD(s).] 362 Summary: A new registry gets up to three new iTLDs for 363 exclusive management for a period of up to five years; if the 364 registry chooses it may establish a joint management of one or 365 more of its iTLDs with other registries. All registries will 366 be reviewed after five years, it is very likely that registries 367 that provide good services will be rechartered. 369 6.1.1. The new iTLD Name Space 371 It is desirable to maintain a "short" suffix on these iTLDs to 372 permit easier use by the public. As such, the presumption will 373 be that only three-character alphanumeric iTLDs will be 374 assigned. 376 The space of new iTLD names will be restricted to alpha numeric 377 strings of exactly 3 characters. iTLD names are case 378 independent (i.e., COM = com = cOm). 380 ::= 382 ::= | 384 ::= A | B | C | ... | Z 386 ::= 0 | 1 | 2 | ... | 9 388 These names must be generic, i.e., not well known company 389 identifiers or trademarks. iTLDs which are previously 390 registered trademarks are specifically excluded from 391 consideration as appropriate assignments. 393 A possible exception might be for a generic term that is 394 trademarked substantially world wide and is not associated 395 with a particular product or service or purpose other than 396 domain name registration. 398 This condition may be impossible to enforce, since on a world 399 wide basis in may be very difficult to determine if a 400 particular string of letters is a trademark is any country or 401 is the identification of a well known company in any country. 403 In any case the neither the IANA nor the ad hoc committee plan 404 to spend any time or energy on research in this area. The 405 applicants to operate registries and manage iTLDs are on their 406 honor not to select iTLD names knowingly in violation of this 407 condition. 409 6.2. Who May Apply 411 Persons or organizations wishing to operate registries and manage 412 iTLDS shall send applications to the IANA in accordance with the 413 provisions of this memo. 415 A "person or organization" may be a single person or organization 416 or any group of persons and organizations which may combine to 417 offer registration services under one name as a cooperative or 418 competitive provider of services, provided that all partners in 419 the confederation or alliance shall otherwise be in compliance 420 with the terms of this document. 422 Organizations granted iTLD names may add or remove additional 423 cooperating registration partners at their discretion, provided 424 that doing so does not violate the provisions of this memorandum. 426 6.3. Open Process 428 The applications for iTLD domain names and registries shall be 429 evaluated in a neutral, impartial, and open manner. 431 The proceedings and evaluations of the applications submitted 432 shall be available for public inspection via an on-line procedure 433 (e.g., web site) along with the decisions made. 435 Financial and business aspects of proposals are kept confidential 436 during the evaluation process. The complete proposal of the 437 successful applicants, including these aspects, will be made 438 public at the completion of the ad hoc committee process. 440 6.3. Review Criteria 442 All applications are judged on three criteria: Registration 443 Services, Operational Resources, and Business Aspects. 445 Charter approval does not necessarily go to the highest bidder. 446 Reliability, quality of service, sustainability, are also 447 important aspects. 449 When a registry which has provided good quality and reliable 450 service comes up for charter renewal, barring unusual 451 circumstances, the charter renewal application should be approved. 453 6.3.1. Registration Services 455 Each registry provide the following administrative services and 456 policies for each iTLD they administer: 458 1) Access to the Registration Database 460 The DNS database files and "whois" databases maintained by any 461 iTLD operator are deemed to be publicly available and public, 462 non-protected, information. The intent is to allow easy access 463 to the information needed to investigate and correct 464 operational problems. 466 A registry shall provide guaranteed availability of the 467 registration data in a useful form should transfer of 468 responsibility become necessary, e.g., regular publication of 469 the information, or regular deposits of copies of the 470 information with a reputable escrow agent instructed to release 471 the information to the IANA. 473 The IANA is authorized to designate one or more organizations 474 as "escrow holders" of said database information for the 475 purposes described below under "Termination of Registries". 477 The escrow holder will have to keep very up to date copies 478 of the database probably through some automated system that 479 makes a copy on a daily basis. 481 The registry must provide a means, via the "whois" protocol, to 482 search the database of second-level domains maintained by this 483 registry and return common directory information. This 484 information shall include, but not necessarily be limited to: 486 a) The "owner" of the second-level domain, including contact 487 name(s), physical address(es), and telephone number(s) of 488 the persons responsible for the operation of the second- 489 level domain. 491 b) The nameserver hostnames and IP addresses serving that 492 second-level domain. 494 c) The current status (operational, on hold, pending, etc) of 495 that second-level domain. 497 There is no intent to have a "global phonebook" of second-level 498 domain holders. The intent is to provide information necessary 499 for tracking down and resolving operational problems. 501 iTLD registries are expected to provide their own directory 502 service, and "rWhois" is designated as one of the operational 503 choices which a registry may wish to utilize. However, no 504 attempt is made to mandate any particular technical or 505 organizational requirements from a registry to service requests 506 for lookups of a domain holder in other, competing registries 507 and iTLDs. 509 Internal database and operational issues are to be decided by 510 the registry. These issues, including pricing to customers of 511 the registry, are properly free-market issues and are excluded 512 from the control of the IETF, IANA, ISOC and other related 513 organizations. 515 2) A help desk and staff to answer questions via electronic 516 mail, fax and normal telephone during customary business hours. 518 3) Published policies on services offered, registration 519 procedures, and fees. 521 4) A clear description of the appeals mechanism within the 522 registry, including the entry point for appeals and the 523 expected response time. 525 5) All of the public information identified in points 1 through 526 4 above shall be made available via WWW, FTP, and automated 527 email responder at an address associated with the organization. 529 6.3.2. Operational Resources 531 1) Internet Connectivity 533 A description of the Internet connectivity to the site where 534 each nameserver for each iTLD will be located. 536 For example, a diagram showing full multi-homed connectivity to 537 the organization's computers which will serve as the iTLD 538 nameservers, with each leg of that connectivity being at a 539 non-aggregated data rate of . 541 And route advertisement via BGP4 for this organization's 542 connectivity must be operational for the connections maintained 543 under this provision, and the network involved should be 544 operating in a "defaultless" configuration. 546 2) Nameserver Performance 548 The description of at least two (2) nameservers for the iTLDs 549 in question. These nameservers shall run the latest 550 "consumable" release of the BIND code (4.9.x at present), and 551 may include local enhancements, changes, or operational 552 improvements. 554 The names and IP addresses of the hosts which are proposed to 555 serve the iTLDs. 557 6.3.3. Business Aspects 559 A description of the applicant which shows sufficient business 560 viability that the registry is likely to operate successfully 561 for at least five years (this is not a business plan, rather 562 some documentation that lends credibility to the applicant's 563 proposal), 565 A bid amount in USD to be paid to the iTLD fund if charter is 566 awarded, and 568 A bid amount in USD to be paid annually to the iTLD fund. 570 6.4. The Application 572 All of the information required to be supplied with an application 573 should be prepared for transmission via email in plain ASCII text, 574 in English. The details of the submission of applications will be 575 determined by the ad hoc committee. 577 The application shall include the following: 579 6.4.1. Applicant Name 581 The name of the applicant, including the contact information. 583 6.4.2. iTLD Names 585 The three three-character iTLDs proposed, along with an 586 statement indemnifying the IANA and the ISOC for any 587 infringement of trademark which may be created by the IANA 588 authorizing this assignment. 590 6.4.3. The Criteria Statements 592 The applicant's approach to the three criteria of section 6.3, 593 Registration Services, Operational Resources, and Business 594 Aspects. 596 These statements should include: 598 A clear statement of the charter, policies, and procedures, 600 a statement of registrant qualification procedures, 602 a statement that they will be non-discriminatory in the sense 603 of treating all applicants equally (if a registry chooses to 604 operate the iTLD "CHM" for companies in the chemical business 605 it may decline to register companies not in that business) 607 a description demonstrating the organizational and technical 608 competence to run a registry and the expected accompanying 609 information services, 611 a statement that the registry will 613 (1) abide by the results of the appeals process (as 614 described in this memo) and the direction of the IANA, and 616 (2) hold harmless ISOC, IANA, IETF, the ad hoc committee, 617 and 618 (3) obtain the usual prudent insurance. 620 6.4.4. The Application Fee 622 A non-refundable application fee of USD 1000 payable to the 623 "Internet Society" to be deposited in the "iTLD fund". 625 6.5. Charters are for a period of five years, but annual progress 626 reports are submitted for review by IANA and the ad hoc group. Only 627 in exceptional cases of radical change or abuse of a charter may the 628 IANA or the ad hoc group recommend to the IANA and ISOC that the 629 charter be reevaluated before the charter period is reached (see 630 appeals process, and termination of registries sections). 632 6.9. Schedule 634 There are several stages that each take some time: forming the ad hoc 635 committee, finalizing the procedure, accepting the applications, and 636 evaluating the applications. 638 6.9.1. Assume the ad hoc committee is be formed day 1. 640 6.9.2. The ad hoc committee will finalize and announce its procedures 641 by day 30. 643 6.9.3. The ad hoc committee will accept applications until day 90. 645 6.9.4. The ad hoc committee will review the applications and announce 646 its selections by day 135. 648 For example suppose the ad hoc committee was formed on 1-May-96. 649 Then the schedule would be: 651 01-May-96 ad hoc committee formed 653 01-Jun-96 procedures finalized, 654 begin accepting applications 656 01-Aug-96 stop accepting applications, 657 begin evaluation 659 15-Sep-96 announce selections 661 7. Termination of Registries 663 iTLD registries may decide they no longer wish to operate their 664 registry. Likely, the operation will not be profitable when this 665 occurs, yet the registrants under the iTLD may need to be supported 666 for a considerable time. 668 Some portion of the fees in the ISOC-managed iTLD fund may be used to 669 pay for some other organization to operate the failing iTLD or 670 registry until it again becomes viable or until the registrants have 671 safely migrated elsewhere. 673 While it is unclear how expensive providing even temporary service 674 for the iTLDs of a failed registry might be, the iTLD process must be 675 prepared for the case where a very popular, possibly because it is 676 low cost, iTLD or registry fails. 678 Some views on the possible scenarios: 680 It will be very expensive. 682 Bailing out the registrants of a failing domain could be very 683 expensive, even on the order of a million USD (remember, a 684 likely failure mode may be because someone thought they could 685 do it for less). 687 It is not a big deal. 689 It is presumed that any registry with a significant client base 690 will constitute a legitimate on-going business interest with 691 revenue prospects sufficient to insure that the registry will 692 in fact be transferred to another organization. 694 As an example, presuming 5,000 registrants of a given registry 695 and a fee of 50 USD per year, a revenue stream of 250000 USD 696 per year would inure to the benefit of any organization taking 697 over the services of a defunct organization. 699 Should a registry close without having significant second-level 700 registrations in place at that time, the impact to the Internet 701 users as a whole will be minimal or non-existent. 703 Succession issues related to the relationships between customers of a 704 registry and that registry itself are properly contractual matters 705 between the registry and its customers, and when properly attended to 706 do not involve the IETF, ISOC, or the IANA. 708 The IANA or its designee may operate one or more "escrow services" to 709 insure that the records contained in a registry will remain available 710 in the event of intentional or accidental destruction due to a 711 registry forfeiting a iTLD. 713 Organizations providing registry services may elect to terminate 714 their involvement in this program and release the iTLD namespace 715 delegated to their organization under the following circumstances: 717 7.1. Any organization may transfer the authority for, and 718 registration services provided, for a iTLD to any other 719 organization provided that the new registration authority complies 720 with all provisions of this memorandum. The business and 721 financial terms under which this transfer is conducted shall be 722 properly between the old and new registry organizations and not 723 under the jurisdiction of the IANA, the IETF or the ISOC. However, 724 the IANA must be notified of such a transfer, and the charter of 725 the registry for the management of these iTLDs shall be reviewed 726 as a renewal of the charter at the next normal session of the ad 727 hoc committee. 729 7.2. iTLDs which are "orphaned" by a registry that constructively 730 abandons them or ceases business operations without first securing 731 a successor organization to assume the authority and registration 732 services for that namespace shall be deemed "abandoned". 733 Abandoned iTLD namespace shall be auctioned to the highest bidder 734 by an open, competitive bid process adjudicated by the IANA or its 735 designees, which shall be conducted without undue delay. During 736 the interim period in question the IANA shall be authorized to 737 designate one or more firm(s) to hold the existing registration 738 records to prevent the interruption of service. 740 7.3. An organization that is found by the IANA to be in violation of 741 the terms of this delegation memorandum shall be given notice by 742 the IANA of intent to recover the iTLD domain space allocated 743 under this policy via normal postal mail. Within 30 days, the 744 organization against which the complaint has been lodged shall a) 745 cure the violation(s) of this policy, (b) transfer authority to 746 another organization under 7.1 above, or (c) constructively 747 abandon for public auction the namespace under the provisions of 748 7.2 above. Where the facts are disputed regarding possible 749 violations of this policy, the IANA is authorized to promulgate 750 reasonable adjudication policies which should include an 751 arbitration provision. 753 8. Finances 755 It is desirable to keep the ISOC, IANA and IETF from becoming 756 involved in operational and contractual aspects of the iTLD 757 registries, and it is further desirable to separate, to the extent 758 possible, the IETF and IANA funding from these organizations. 760 It is presumed in the best interest of the IETF, the IANA, ant the 761 ISOC to see that this separation of function is preserved. 763 Note: 765 Indemnification provisions from the registries to the IANA and 766 related organizations may not serve to properly insulate the 767 ISOC, IANA and IETF from legal proceedings, as it should be 768 presumed that any organization which is legally challenged in a 769 significant fashion may be unable to properly pay any judgments 770 levied against it. Current "deep pockets" legal practice 771 exposes related organizations to the negative effects of these 772 legal actions should the original organization be unable to 773 fulfill its financial obligations. 775 There is a concern that the presence of a funding path creates 776 a tying arrangement between for-profit organizations and a set 777 of non-profit organizations which up to now have not been 778 legally, financially, or otherwise encumbered by the actions of 779 these registries. 781 8.1. A registry may charge as it sees fit, within the bounds of the 782 policy published when it is chartered. 784 8.2. The ISOC manages all finances in a separate iTLD fund with open 785 reporting and published budgets. Agreement of the ISOC, the IANA, 786 and the IETF is required on all budgets. 788 8.3. Charter fee income may be used to pay legal costs of the IANA, 789 IETF, ISOC, and ad hoc groups when legal disputes arise from the 790 iTLDs process. 792 8.4. Charter fee income is also used to pay modest and publicly 793 visible costs of the chartering process, e.g., the costs of the ad 794 hoc committee, the administrative staff, and costs incurred by the 795 ISOC. 797 8.5. Charter fee income may also be used to fund the IANA if and when 798 it becomes necessary. 800 8.6. Should the reserves be too large, a consensus of the IANA, IETF, 801 and ISOC would allow disbursements for the general network good, 802 e.g., scholarships for engineers from developing countries. 804 8.7. The ISOC may charge a modest amount for administering the iTLD 805 account. 807 9. Appeals 809 Arbitration to resolve conflicts is encouraged. That an appeals 810 process is specified should not preclude use of arbitration. The 811 appeals process described here is for when arbitration has failed or 812 when the parties decide not to use arbitration, yet they do not wish 813 to exercise recourse to lawyers and courts. 815 9.1. The appeals process does not apply to disputes over Intellectual 816 Property Rights on names (trademark, service mark, copyright). 817 These disputes are best left to arbitration or the courts. 818 Registries may require appropriate waivers from registrants. 820 9.2. The appeals process does not apply to charging and billing. 821 This is left to market forces, arbitration, and the courts. 823 9.3. The appeals process applies to all other aspect of registry 824 processing of registration requests. 826 9.4. A registrant's first recourse is to the registry which has 827 denied them registration or otherwise failed to provide the 828 expected service. 830 9.5. All registries must specify in their applications an entry point 831 and a process for appeals, as well as a response time, and must 832 subsequently conform to them. 834 9.6. If appellant is dissatisfied with the registry response, appeal 835 may be escalated to the IANA. The IANA hears appeals based only 836 on technical issues. Note that the IANA may use the IDNB to 837 process the appeal. 839 9.7. The IANA must define its entry point for appeals and must 840 respond to appeals within four weeks. 842 9.8. If appellant is dissatisfied with the IANA response, and the 843 appeal has nontrivial process aspects, the appeal may be escalated 844 to the IETF. The IETF hears appeals based only on process issues, 845 that is, claims that the procedure was not followed. 847 9.9. If appellant is dissatisfied with the IANA and, if invoked, the 848 IETF response, appeal may be escalated to the ISOC. The ISOC 849 appeals process hears appeals only about the fairness of the 850 procedure. I.e. the decision of IANA and/or IETF is final, 851 unless there is an appeal that the procedure itself is unfair. 853 9.10. The appeals process works by email. Appellant must provide 854 concise history of the case and summarize grounds of appeal. The 855 IANA, the IETF, or the ISOC may ask for information from third 856 parties. All information is normally treated as nonconfidential 857 and may be made publicly available. Confidential information is 858 considered only in special circumstances. 860 9.11. The IANA, the IETF and the ISOC may establish appeals sub- 861 committees chosen either from their own membership or outside of 862 it by whatever means each deems reasonable for their procedures 863 and purposes. 865 10. Security Considerations 867 There are no known security considerations beyond those already 868 extant in the DNS. 870 11. Acknowledgments 872 This memo is a total rip off of a draft by Randy Bush, combined with 873 substantial inclusion of material from a draft by Karl Denninger. 874 The appeals section was originally written by Brian Carpenter. 876 To this base i've made many changes small and large. So to the 877 extent you like this it is probably their work, and to the extent you 878 don't like it it is probably all my fault. 880 A lot of significant and constructive input and review was received 881 from the following: 883 Alan Barrett 884 Randy Bush 885 Brian E. Carpenter 886 Karl Denninger 887 Robert Elz 888 Geoff Huston 889 John Klensin 890 Lawrence Landweber 891 Nick Trio 893 12. Author's Address 895 Jon Postel 896 IANA Phone: +1 310 822-1511 897 USC/Information Sciences Institute Fax: +1 310 823-6714 898 4676 Admiralty Way 899 Marina del Rey, CA 90292 Email: Postel@ISI.EDU