idnits 2.17.1 draft-ymbk-itld-admin-00.txt: ** The Abstract section seems to be numbered 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-18) 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 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. == 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 (January 1996) is 10321 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 (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT R. Bush 2 draft-ymbk-itld-admin-00.txt RGnet 3 B. Carpenter 4 CERN 5 J. Postel 6 ISI 7 January 1996 9 Delegation of International Top Level Domains (iTLDs) 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months. Internet-Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet- 21 Drafts as reference material or to cite them other than as a working 22 draft or work in progress. 24 To learn the current status of any Internet-Draft, please check the 25 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 26 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 27 munnari.oz.au. 29 0. Abstract 31 This document describes policies and procedures to 32 o allow open competition in domain name registration in the iTLDs, 33 o allow multiple registries for the COM and other iTLDs, 34 o and provide the IANA with a legal and financial umbrella 36 1. Introduction 38 For the purpose of delegation, the top level domains (TLDs) fall into 39 the categories listed below. While all are described to provide 40 context, only the last is the subject of this document. 42 1.1. National TLDs 44 National TLDs such as AF, FR, US, ... ZW are named in accordance 45 with ISO 3166, and have, in the major part, been delegated to 46 national naming registries. Any further delegation of these TLDs is 47 undertaken by the Internet Assigned Number Authority (IANA), in 48 accordance with the policies described in RFC 1591. 50 It is good practice for these delegated TLD registries to publicly 51 document the applicable management policies and further delegation 52 procedures for these national domains, as, for example, RFC 1480 53 does for the US domain. 55 1.2. US Governmental TLDs 57 1.2.1. Delegation of the GOV zone is described by RFC 1816, and is 58 under the authority of the US Federal Networking Council (FNC). 60 1.2.2. Delegation of the MIL domain is under the authority of the 61 DDN NIC. [ is there a descriptive or governing document? ] 63 1.3. Infrastructure TLDs 65 TLDs such as IN-ADDR.ARPA and INT are under the authority of the 66 IANA and may be delegated to others, e.g. IN-ADDR.ARPA is currently 67 delegated to the InterNIC for day-to-day management. They are 68 created for technical needs internal to the operation of the 69 internet at the discretion of the IANA in consultation with the 70 IETF. 72 1.4 The EDU TLD 74 Delegation of the EDU domain is under the authority of the FNC and 75 is currently delegated to the NSF which has contracted to the 76 InterNIC for registration. 78 Over time, the FNC and NSF may decide to use other delegation 79 models, such as those described below for non-governmental zones. 81 Some people (Americans and non-) feel that EDU should be restricted 82 to US institutions. That is outside the scope of this discussion. 84 1.5 The International Top Level Domains (iTLDs) COM, ORG, and NET 86 The iTLDs are generic top level domains which are open to general 87 registration. They are currently delegated to the InterNIC by the 88 authority of the IANA. 90 1.5.1. The intent for these iTLDs is discussed in RFC 1591. 91 Generally, COM is for commercial entities, NET is for the internal 92 infrastructure of service providers, and ORG is for miscellaneous 93 entities. 95 1.5.2. There is a perceived need to open the market in commercial 96 iTLDs to allow competition, differentiation, and change. 98 1.5.3. As the net becomes larger and more commercial, the IANA needs 99 a formal body to accept indemnity for the touchy legal issues which 100 arise surrounding DNS policy and its implementation. 102 2. Goals 104 To facilitate administration of the domain name subsystem within the 105 Internet by ensuring that there is an open and competitive marketplace 106 for clients to obtain and subsequently maintain delegation of sub- 107 domains within the iTLDs, while preserving the operational integrity 108 of the Internet DNS itself. 110 The specific measures to achieve this objective are as follows: 112 2.1. Provide the IANA with the international legal and financial 113 umbrella of the Internet Society (ISOC), 115 2.2. Allow open competition in domain name registration in the iTLDs, 116 which will then allow registries to charge for their services, 118 2.3. Allow multiple registries to operate cooperatively and fairly in 119 the COM domain and/or other multi-registry iTLDs which may be created, 121 2.4. Facilitate creation of new iTLDs in a fair and useful, but 122 reliable, fashion, 124 2.5. Provide for reliable maintenance of the registrants of an iTLD 125 should the current delegatee no longer wish to maintain it, and 127 2.6. Define iTLD policies and procedures by open methods, modeled on 128 the IETF process and/or using IETF mechanisms when appropriate. 130 3.0 Scope of this Document 132 This document describes the administrative structure for the operation 133 of the iTLDs. While other administrative issues may exist within the 134 broader domain of the DNS, they are not addressed in this document. 136 Specifically: 138 3.1. Only those relationships between the IANA, IETF, ISOC, etc. which 139 are specifically necessary for responsible maintenance of the iTLDs 140 are described. 142 3.2. It would not be reasonable for this document to specify what 143 particular agent, board, or committee of the ISOC, IANA, or IETF acts 144 for each. Hence, they are described in generic terms, and left for 145 each organization to specifcy. This specification may change from 146 time to time. 148 At this writing, the Board of Trustees acts for the ISOC, the IAB for 149 the IETF, and the IANA for itself. 151 3.3. Long range maintenance of the IANA is not described; although it 152 is believed that the IANA could draw financial support from a wider 153 community. 155 3.4. The IETF is not directly involved in operation of the net. Hence 156 it serves the iTLD administrative work mainly in a technical capacity, 157 such as the formalization of new protocols and handling of technical 158 appeals. 160 3.5. The ISOC does not directly operate the net. But it takes legal 161 responsibility, provides ad hoc group members, manages funds, and 162 participates in the appeals process. 164 3.6. The IANA and any necessary ad hoc groups deal with operational 165 details. 167 3.7. The ISOC, the IETF, and the IANA are no be legally or financially 168 responsible for the registries. The registries must be responsible 169 for themselves. 171 3.8. Creation of permanent bureaucracy is not desired. 173 4. Technical Assumptions 175 Further growth within the iTLDs can be accommodated technically, and 176 tools are in evidence to automate much of the process of registration 177 and maintenance of entries within the DNS as well as multiple 178 administrative access to a single delegated domain. 180 4.1. The size of current zones such as COM, while large, is not really 181 a burden on servers, nor is it expected to become so in the near 182 future. 184 4.2. Procedures which allow mutual exclusion for the creation of 185 names within a single zone are being developed within the IETF's 186 dnsind and dnssec WGs, and a test implementation is available. 188 4.3. Tools are being developed to ease the processes of registration 189 and running the information servers which are expected of registries. 191 5. The Process 193 5.1. The IANA continues to supervise and control all operational 194 aspects of the iTLDs, and is the first level of the appeals process 195 after that of the registries. It appoints members to the ad hoc iTLD 196 group(s). 198 5.2. The IETF, as part of its normal procedures, publishes documents 199 which describe technical and operational aspects of the domain space 200 including the iTLDs. It also provides an appeals procedure for 201 technical issues and appoints members to the ad hoc iTLD group(s). 203 5.3. The ISOC provides the legal and financial umbrella, and the final 204 level of the appeal process. It provides an appeals procedure for 205 procedural issues and appoints members to the ad hoc iTLD group(s). 206 The ISOC assumes legal liability for the process and the iTLDs. 208 5.4. Ad hoc working groups, for developing procedures and deciding 209 creation of new iTLDs and chartering of registries, consist of seven 210 members appointed by the IANA, the IETF, and the ISOC. 212 5.5. Note that 'ad hoc' means 'for this purpose only.' In this case, 213 an ad hoc group is created and convened on a periodic basis when 214 needed to change procedures or to review iTLD applications. 216 5.6. Some may feel that this is too informal. Should this opinion 217 prevail, a permanent panel would be created, with two members each 218 appointed by the IANA, the IETF, and the ISOC and one member mutually 219 chosen from the general community. Members would serve two year 220 staggered terms. 222 5.7. The process/policy development may take three to six months, and 223 initial chartering another six. It is estimated that approximately 224 five new iTLDs will be created a year. 226 5.8. The policies and procedures to be used by the ad hoc working 227 group will be decided by the zeroeth ad hoc group in an open process 228 and will be clearly documented. This group will be appointed and 229 convene in March or April 1996. It is expected that these policies 230 and procedures will mature over time. 232 5.9. Multiple registries for the COM zone, and registries for new 233 iTLDs will be created. 235 5.10. New iTLDs will be created over time. This is a direct change to 236 RFC 1591. New iTLDs may be created with a non-exclusive 237 administration arrangement, i.e. multiple operators for any further 238 iTLDs may be within the provisions of creation of an iTLD. 240 5.11. The intent is similar to the licensing of radio stations in some 241 countries, a few commercial ones and a few public service ones. 243 5.12. Registries pay for charters, and the fees collected are kept in 244 a fund managed by the ISOC and used solely for the iTLD process, 245 insurance against an iTLD registry withdrawal or collapse, and 246 possibly to support an evolved future funding model for the IANA. 248 6. Selection of iTLDs and Registries 250 6.1. There are useful proposals for registries and iTLDs which are not 251 able to demonstrate solid financial stability and/or raise sufficient 252 funding to ensure continued operation to protect the registrants 253 should their efforts fail. Yet it is desirable that these technical 254 and social experiments be conducted. 256 Hence, two types of charter are provided, commercial and public 257 service, with the understanding that fees from commercial registry 258 charters cross-subsidize low fees from public service efforts. 260 This is intended to provide, among other benefits, a path for 261 migration of the EDU and other TLDs. 263 iTLD and registry charter applications specify whether they are 264 commercial or public service. 266 6.2 An application is for chartering a new registry for an existing 267 iTLD, or for creation of a new iTLD and creation of one or more 268 registries. 270 If a new iTLD is proposed, then it is assumed to allow chartering of 271 multiple registries unless exclusive registration charter is specified 272 in the application. Request for exclusive registration must be well 273 motivated and well justified. 275 6.3. Financial and business aspects of proposals are kept confidential 276 during the evaluation process, as a bidding war is not desirable. 278 Charter approval does not necessarily go to the highest bidder. 279 Reliability, quality of service, sustainability, etc. are more 280 important criteria. 282 6.4. When a registry which has provided good quality and reliable 283 service comes up for charter renewal, barring unusual circumstances, 284 the charter renewal application should be approved. 286 6.5. All applications are judged on 287 6.5.1. a clear statement of charter, policies, and procedures, 288 including whether the iTLD is to have shared registries or be 289 exclusive, 290 6.5.2. organizational and technical competence to run a registry and 291 the expected accompanying information services, 292 6.5.3. innovation in type of service, audience, or technology, 293 6.5.4. a statement of registrant qualification procedures and a 294 statement that they will be non-discriminatory, 295 6.5.5. a clear description of the appeals mechanism within the 296 registry, including its guaranteed response time, 297 6.5.6. a statement that the registry will abide by the results of 298 the appeals process and the direction of the IANA, 299 6.5.7. indemnification of ISOC, IANA, IETF, ad hoc committees, and 300 all others believed to be at risk from this process, as well as the 301 usual prudent insurance, and 302 6.5.8. guaranteed availability of the registration data in a useful 303 form should transfer of responsibility become necessary, e.g. 304 regular publication of the information, or regular deposits of 305 copies of the information with a reputable escrow agent instructed 306 to release the information to the IANA. 308 6.6. In addition, commercial applications are judged on 309 6.6.1. a business and financial plan which shows sufficient 310 viability that the registry is likely to operate successfully for at 311 least five years, 312 6.6.2. a bid to be paid to the iTLD fund if charter is awarded, and 313 6.6.3. a bid to be paid annually to the iTLD fund. 315 6.7. In addition, public service applications are judged on 316 6.7.1. clear demonstration of goals and means which are in the 317 public good and which have not been or might not be satisfied by a 318 commercial applicant, 319 6.7.2. a business and financial plan which need only show viability 320 and cost recovery, and which might even rely on income from donor 321 agencies, and 322 6.7.3. a minimal annual fee of USD5,000 to the iTLD fund. 324 6.8. Charters are for a period of five years, but annual progress 325 reports are submitted for review by IANA and the ad hoc group. Only 326 in exceptional cases of radical change or abuse of a charter may the 327 IANA or the ad hoc group recommend to the IANA and ISOC that the 328 charter be reevaluated before the charter period is reached (see 329 appeals process). 331 7. Finances 333 7.1. A registry may charge as it sees fit, within the bounds of the 334 policy published when it is chartered. 336 7.2. iTLD registries may decide they no longer wish to operate their 337 registry. Likely, the operation will not be profitable when this 338 occurs, yet the registrants under the iTLD may need to be supported 339 for a considerable time. 341 A significant amount of the chartering fees in the ISOC-managed iTLD 342 fund are reserved to pay for some other entity to operate the failing 343 iTLD or registry until it again becomes viable or until the 344 registrants have safely migrated elsewhere. 346 The iTLD process must be prepared for the case where a very popular, 347 possibly because it is low cost, iTLD or registry fails. Bailing out 348 the registrants of a failing domain could be very expensive, even on 349 the order of a million USD (remember, a likely failure mode may be 350 because someone thought they could do it for less). So prudent 351 reserves must be kept. 353 7.3. The ISOC manages all finances in a separate iTLD fund with open 354 reporting and published budgets. Agreement of the ISOC, the IANA, and 355 the IETF is required on all budgets. 357 7.4. Charter fee income is used to pay legal costs of the IANA, IETF, 358 ISOC, and ad hoc groups when serious legal disputes arise from the 359 iTLDs. 361 7.5. Charter fee income is also used to pay modest and publicly 362 visible costs of the chartering process, e.g. the costs of the ad hoc 363 committee. 365 7.6. Charter fee income may also be used to fund the IANA if and when 366 the IANA becomes more openly funded. 368 7.7. Should the reserves be embarrassingly large, a consensus of the 369 IANA, IETF, and ISOC Board would allow disbursements for the general 370 network good, e.g. scholarships for engineers from developing 371 countries, etc. 373 7.8. The ISOC charges a modest amount for administering the iTLD 374 account. 376 8. Appeals 377 Arbitration to resolve conflicts is encouraged. That an appeals 378 process is specified should not preclude use of arbitration. The 379 appeals process described here is for when arbitration has failed or 380 when the parties decide not to use arbitration, yet they do not wish 381 to exercise recourse to lawyers and the courts. 383 8.1. The appeals process does not apply to disputes over Intellectual 384 Property Rights on names (trademark, service mark, copyright). These 385 disputes are best left to arbitration or the courts. Registries may 386 require appropriate waivers from registrants. 388 8.2. The appeals process does not apply to charging and billing. This 389 is left to market forces, arbitration, and the courts. 391 8.3. The appeals process applies to all other aspect of registry 392 processing of registration requests. 394 8.4. A registrant's first recourse is to the registry which has denied 395 them registration or otherwise annoyed them. 397 8.5. All registries must specify in their applications an entry point 398 and a process for appeals, as well as a response time, and must 399 subsequently conform to them. 401 8.6. If appellant is dissatisfied with the registry response, appeal 402 may be escalated to the IANA. 404 8.7. The IANA must define its entry point for appeals and must respond 405 to appeals within four weeks. 407 8.8. If appellant is dissatisfied with the IANA response, and the 408 appeal has nontrivial technical aspects, the appeal may be escalated 409 to the IETF. The IETF hears appeals based only on technical issues. 411 8.9. If appellant is dissatisfied with the IANA and, if invoked, the 412 IETF response, appeal may be escalated to the ISOC. The ISOC appeals 413 process hears appeals only against breach of appeals procedure. I.e. 414 the decision of IANA and/or IETF is final, unless there is an appeal 415 against breach of appeals procedure. 417 8.10. The appeals process works by email. Appellant must provide 418 concise history of the case and summarize grounds of appeal. The 419 IANA, The IETF, or the ISOC may ask for information from third 420 parties. All information is normally treated as nonconfidential and 421 may be made publicly available. Confidential information is 422 considered only in special circumstances. 424 8.11. The IANA, the IETF and the ISOC establish appeals sub-committees 425 chosen either from their own membership or outside of it by whatever 426 means each deems reasonable for their procedures and purposes. 428 9. Appendix A - A Thousand Domains Experiment 430 It has been suggested that the root domain be opened up to a fairly 431 arbitrary registration of new iTLDs. While the idea has its social 432 appeal, 433 o it would be an irreversible decision with no prior experience and 434 o some argue that TLDs, like global variables, should be few and 435 created with great care. 437 Therefore we suggest that one of the early public service proposals 438 that should be seriously considered would be one which proposes a 439 shared iTLD which would have very open creation of sub-registries; 440 thereby conducting the 1,000 domain experiment one level down. 442 10. Security Considerations 444 There are no known security considerations beyond those already extant 445 in the DNS. 447 11. Acknowledgments 449 A lot of significant and constructive input and review was received 450 from the following kind folk: 452 Alan Barrett 453 Robert Elz 454 Geoff Huston 455 John Klensin 457 12. Authors' Addresses 459 Randy Bush 460 Unaligned geek 461 RGnet 462 9501 SW Westhaven Phone: +1 503 227-5665 463 Portland, Oregon 97225 Fax: +1 503 297-9078 464 USA Email: randy@psg.com 466 Brian E. Carpenter 467 IAB Chair 468 Group Leader, Communications Systems Phone: +41 22 767-4967 469 Computing and Networks Division Fax: +41 22 767-7155 470 CERN 471 European Laboratory for Particle Physics Email: brian@dxcoms.cern.ch 472 1211 Geneva 23, Switzerland 474 Jon Postel 475 IANA Phone: +1 310 822-1511 476 USC/Information Sciences Institute Fax: +1 310 823-6714 477 4676 Admiralty Way 478 Marina del Rey, CA 90292 Email: Postel@ISI.EDU