idnits 2.17.1 draft-masek-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-26) 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 pages 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 22 instances of too long lines in the document, the longest one being 664 characters in excess of 72. ** There are 839 instances of lines with control characters in the document. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 65 has weird spacing: '...betical names...' == Line 761 has weird spacing: '...e local servi...' == Line 763 has weird spacing: '... has an inter...' -- 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 (August 1996) is 10116 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: 11 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft-masek-itld-admin-00.txt Jan Masek 2 ISI 3 August 1996 4 Expire in six months 6 New Registries assignment, new iTLD formats and implementation 7 of International Top Level Domains 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. It also 31 discusses a new format/ special class of iTLDs to be implemented 32 to facilitate deployment of innovative Internet services. Further it 33 discusses the issues surrounding additional international top level 34 domains (iTLDs) and registries, qualification proposals for 35 operating such a registry, and justifications for the positions 36 expressed in this paper. 38 This document describes policies and procedures to 40 o allow open competition in domain name registration in the 41 iTLDs, 43 o and provide the IANA with a legal and financial umbrella 45 Note that while cooperation between competing iTLD registries is 46 allowed, it is not required. This is specifically not assumed in 47 this proposal, and is considered to be an operational aspect of a 48 registry best determined, and coordinated, by contractual agreements 49 between private interests. 50 ....draft-masek-itld-admin-01.txt Aug. 1996 52 The NEWDOM, IETF, and related mailing lists are encouraged to read, 53 and comment, on this material. Presuming a consensus can be found 54 within these audiences, the distribution of this memorandum should be 55 expanded to include general commentary from the Internet community. 57 1. Introduction 59 For the purpose of delegation, the top level domains (TLDs) fall into 60 the categories listed below. While all are described to provide 61 context, only the last is the subject of this document. 63 1.1. National TLDs 65 The two-character alphabetical namespace is, and will remain, reserved for ISO 66 country codes under existing accepted Internet RFCs except for the NEW TOP 67 LEVEL DOMAIN NAMES proposed in this draft. 69 National TLDs such as AF, FR, US, ... ZW are named in accordance 70 with ISO 3166, and have, in the major part, been delegated to 71 national naming registries. Any further delegation of these TLDs 72 is undertaken by the Internet Assigned Number Authority (IANA), in 73 accordance with the policies described in RFC 1591. 75 It is good practice for these delegated TLD registries to publicly 76 document the applicable management policies and further delegation 77 procedures for these national domains, as, for example, RFC 1480 78 does for the US domain. 80 1.2. US Governmental TLDs 82 1.2.1. Delegation of the GOV TLD is described by RFC 1816, and is 83 under the authority of the US Federal Networking Council (FNC). 85 1.2.2. Delegation of the MIL domain is under the authority of the 86 DDN NIC. See RFC 1956. 88 1.3. Infrastructure TLDs 90 TLDs such as IN-ADDR.ARPA and INT are under the authority of the 91 IANA and may be delegated to others, e.g., IN-ADDR.ARPA is 92 currently delegated to the Internic for day-to-day management. 93 They are created for technical needs internal to the operation of 94 the Internet at the discretion of the IANA in consultation with 95 the IETF. See RFC 1591 for general guidance on the use of the INT 96 and ARPA domains. 98 ....draft-masek-itld-admin-01.txt Aug. 1996 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 COM, ORG, and NET are the current generic international top level 112 domains (iTLDs) which are open to general registration. They are 113 currently delegated to the Internic by the authority of the IANA. 114 See RFC 1591 for general guidance on the use of the COM, NET, and 115 ORG domains. 117 The INT top level domain is also used for a very restricted class 118 of international organizations established by treaties between the 119 governments of countries. See RFC 1591 for general guidance on 120 the use of the INT domains. 122 1.5.1. The intent for these iTLDs is discussed in RFC 1591. 123 Generally, COM is for commercial organizations (e.g., companies 124 and corporations), NET is for the internal infrastructure of 125 service providers, and ORG is for miscellaneous organizations 126 (e.g., non-profit corporations, and clubs). 128 1.5.2. There is a perceived need to open the market in commercial 129 iTLDs to allow competition, differentiation, and change, and 130 yet maintain some control to manage the Domain Name System 131 operation. 133 The current situation with regards to these domain spaces, and 134 the inherent perceived value of being registered under a single 135 top level domain (.COM) is undesirable and should be changed. 137 Open, free-market competition has proven itself in other areas 138 of the provisioning of related services (ISPs, NSPs, telephone 139 companies) and appears applicable to this situation. 141 It is considered undesirable to have enormous numbers 142 (100,000+) of top-level domains for administrative reasons and 143 the unreasonable burden such would place on organizations such 144 as the IANA. 146 It is not, however, undesirable to have diversity in the top- 147 ....draft-masek-itld-admin-01.txt Aug. 1996 148 level domain space, and in fact, positive market forces dictate 149 that this diversity, obtained through free competition, is the 150 best means available to insure quality service to end-users and 151 customers. 153 1.5.3. As the net becomes larger and more commercial, the IANA 154 needs a formal body to accept responsibility for the legal 155 issues which arise surrounding DNS policy and its 156 implementation. 158 1.6. This memo deals with introducing new registries for iTLDs and 159 additional iTLDs names, it does not deal with the longer term 160 issue of the management and charter of the current iTLDs (COM, 161 NET, and ORG), or the specialized TLDs (EDU, GOV, MIL, INT, and 162 ARPA). 164 The current iTLDs may come under the provisions of this document 165 when their current sponsorship relationship ends. 167 The specialized iTLDs have such restrictive requirements for 168 registration that they do not play a significant role in the 169 competitive business environment. 171 1.7. Trademarks 173 Domain names are intended to be an addressing mechanism and are 174 not intended to reflect trademarks, copyrights or any other 175 intellectual property rights. 177 Except for brief mentions in sections 6.1, 6.4, and 9.3, 178 trademarks are not further discussed in this document. 180 1.8. Observations 182 There seem to be three areas of disagreement about the proposal to 183 increase the number of top level domains: (1) trademark issues, 184 (2) competition, and (3) directory service. 186 1.8.1. Trademark Issues 188 The statement is made that "increasing the number of top level 189 domains does not solve the trademark problem". This may be 190 because "the trademark problem" has no solution. 192 The Domain Name System was created to simply name computers 193 attached to the Internet. There was no intention that domain 194 names identify products or services in any way, or that domain 195 names have any relationship to trademarks. 196 ....draft-masek-itld-admin-01.txt Aug. 1996 197 Two points must be kept in mind: (a) domain names are and must 198 be unique, and (b) trademarked names are not necessarily unique 199 (and there are many examples of non-unique trademarks). 201 There are no international trademarks. There is no official 202 international registry of world wide trademarks. Trademarks 203 may be registered per country (and in the United States (at 204 least) per State). The World Intellectual Property 205 Organization offers an international arbitration service on 206 such matters. 208 There are "strong" trademarks that are registered in many 209 countries and are vigorously defended. These may come close to 210 being unique. There are many "not so strong" trademarks that 211 may be regional or business sector specific (for example, 212 United Air Lines and United Van Lines, or the Acme Brick 213 Company and the Acme Electric Corporation)). 215 There are two conflicting goals of different trademark holders 216 with respect to domain names: (a) to protect their trademarks 217 against infringement, and (2) to have access to the domain name 218 system to use their trademarks in a domain name. 220 Trademark infringement is the use of a trademarked name in a 221 way that may confuse the consumer about the source or quality 222 of a product or service. For strong trademarks there may also 223 be infringement if the use of a trademarked name dilutes the 224 value of the trademark. 226 Holders of strong trademarks want to control every use of their 227 trademark. These people would say it is pointless to create 228 additional top level domains since they will acquire, reserve, 229 and otherwise protect their trademarked name in every top-level 230 domain so no new users will get access to domain names this 231 way, and besides you are just making more work for the lawyers. 232 While these holders of strong trademarks might not actually 233 acquire their names in all the possible top-level domains (no 234 extra income to the registries), they probably would take steps 235 to stop any infringement thus making those names unavailable to 236 anyone else (extra income to the lawyers). 238 Holders of not so strong trademarks want the ability to use 239 their trademarked name in a domain name while some other holder 240 of the same mark for a different purpose also can use their 241 trademarked name in a domain name. These people would say it 242 is essential to create additional top-level domains to permit 243 fair access to domain names by holders of not so strong 244 trademarks. 245 ....draft-masek-itld-admin-01.txt Aug. 1996 246 I would suggest that the number of not so strong trademarks far 247 exceeds the number of strong trademarks and that the domain 248 name system should provide for the needs of the many rather 249 than protecting the privileges of the few. Thus new top-level 250 domains should be created. 252 1.8.2. Competition 254 Another concern with the current situation in the Domain Name 255 System is that there is one registry for the top-level domain 256 names and it is charging fees apparently unconstrained by 257 effective regulation or competition; it is in a monopoly 258 position. Given this, it is reasonable to introduce 259 competition in the form of other registries to provide 260 comparable services. 262 There is a question, though, about how equal the service must 263 be to provide effective competition. Does the establishment of 264 new registries provide effective competition with the existing 265 registry and the most popular top-level domain (that is, the 266 COM domain)? 268 Will people be willing to change their domain name to get 269 better service or lower price? A name acquires substantial 270 value as it is used and it becomes a significant undertaking to 271 change a name. It is unlikely that many companies registered 272 in one domain (for example COM) will change to another (new) 273 domain. 275 Can other top-level domains be successful? It seems that it is 276 most likely that for new top-level domains to be successful 277 they will have to attract users new to the Internet. This may 278 require marketing efforts and promotion (that is, exactly the 279 competition that is currently missing). This can have a 280 significant impact very quickly. Given that the number of 281 users of the Internet is doubling every year, in three years 282 the current population of Internet users - and domain names - 283 will be a small minority of only one-eighth of the population. 285 Is there a practical way to share a single domain name between 286 competing registries? There are technical solutions to this 287 problem. But are there are manageable administrative 288 arrangements for this situation. I am not convinced there are. 290 Even if a manageable administrative arrangement for competing 291 registries to operate in the same top-level domain can be 292 found, these arrangements can be introduced in multiple top- 293 level domains in the future. 294 ....draft-masek-itld-admin-01.txt Aug. 1996 295 While new single registry top-level domains may allow only a 296 limited form of competition, it is a better situation than we 297 have now, and it can be generalized in the future. Thus there 298 is no "competition" argument to prevent creating new top-level 299 domains. 301 1.8.3. Directory Service 303 Is the Domain Name System a directory service? 305 Is it reasonable to expect that if one thinks of a company name 306 that the string "www.company-name.com" will be the locator for 307 that company's web page? Even though it works some of the time 308 now, it is less likely to work in the future even if all 309 company names are registered in the COM domain due to more 310 frequent clashes in names and the requirement of uniqueness. 312 The creation of additional top-level domain names allows 313 companies to have more natural names in one of the various 314 top-level domains. This will make it harder to guess the 315 actual domain name for a company, but probably no harder that 316 it will become if all companies must find unique names in the 317 COM domain. 319 This directory problem is not really a Domain Name System 320 problem. The Domain Name System provides a name to address 321 look up service. It assumes that one starts with the exactly 322 correct name and allows the look up of information associated 323 with that name. The Domain Name System does not (and never 324 was) intended to provide a general search facility. It is much 325 more appropriate to use application level search tools like the 326 various web search systems, or directory services like the 327 X.500 directory service to find the exact Domain Name System 328 based on a fuzzier description of the company identity. 330 The nub of this issue is the question "Should domain names be 331 guessable?" My answer is that it is not possible in general to 332 have guessable domain names, so we shouldn't try too hard. 333 Thus there is no "directory service" argument to prevent 334 creating new top-level domains. 336 1.8.4. Side Remarks 338 1.8.4.1. Case Law on Trademarks and Domain Names 340 Trademark holders must assume that domain names are related 341 to trademarks. One of the requirements to keep a trademark 342 is that it be defended. If a trademark holder becomes aware 343 ....draft-masek-itld-admin-01.txt Aug. 1996 344 of something that might be an infringement of the trademark, 345 it would be folly not to pursue the issue, lest it turn out 346 to be important, and they loose their trademark because of 347 lack of action. That they take this action doesn't mean 348 that it is required, just that there is some doubt. Until 349 one of these cases actually makes it to a high-level court, 350 no one is going to know for sure. 352 The courts will either decide that domain names don't 353 infringe trademarks, simply because of their existence 354 (unless possibly someone has a trademark on a full name like 355 "isi.edu" or "cisco.com") at which stage the trademark 356 holders will know that they don't have to go chasing every 357 domain that happens to use their magic word somewhere in it, 358 or they made decide that the use of "foo.com" is actually a 359 violation of someone's trademark on "foo", in which case 360 people may make trademark searches before registering domain 361 names. 363 Even if the use of a trademarked word in a domain name is 364 ruled to not inherently infringe the trademark it is still 365 possible to use the domain name in a way that would be an 366 infringement of the trademark. 368 It is also possible that creating new top-level domains will 369 strengthen the interpretation that the Domain Names System 370 simply names computers and is not related to trademarks by 371 making it clear that in a domain name like "foo.com" or 372 "foo.bus" the "foo" part cannot be extracted and be left 373 with any meaning at all, it means something only with the 374 complete suffix appended as an indivisible string. 376 Treating the Domain Name System as a directory service may 377 also strengthen the arguments that domain names identify 378 products and services and thus are subject to trademark 379 considerations. 381 In two real cases in the United States courts have found 382 that use of the equivalent of the "foo" in "foo.com" is a 383 violation of trademark. For practical purposes the law is 384 now established - the use of someone else's trademark in a 385 domain name in and of itself can be an infringement of 386 trademark. 388 1.8.4.2. Proposal to Eliminate International Top-Level Domains 390 There is a viewpoint that the problems generated by the 391 Unites States legal system should be confined there (and the 392 ....draft-masek-itld-admin-01.txt Aug. 1996 393 same for every country in the world). This argues to 394 eliminate the international top-level domains (COM, NET, 395 and ORG) altogether and proposes to sweep the current users 396 of those domains into the country code domains. One logical 397 consequence of this view is that corporations in the United States should be registered in COM.US. 399 This argument suggests that the trademarked words versus 400 domain names issue is a United States only phenomenon. 401 While this might be possible, I think it is short sighted. 402 When the number of companies registering domain names in 403 other countries reaches a large number or a substantial 404 percentage of the number of companies in that country, I think 405 they will find they have substantially the same problems as 406 currently occur with the COM domain. 408 This proposal would not fix the trademark, competition, or 409 directory issues, but it would repatriate them. There is 410 presumably no existing law, but it might be relatively easy 411 to establish that acme-cleaners.co.uk and acme- 412 cleaners.com.us were distinct and non-confusing to 413 consumers. So there may be actually some improvement with 414 respect to not so strong trademarks. 416 While this is an interesting suggestion, it is completely 417 unrealistic. The concept of moving - renaming - all the 418 over 200,000 companies now registered in the COM domain is 419 simply a non-starter. 421 So, the argument goes, just close the COM (and NET and ORG) 422 domain to new registrations and tell all those making 423 registration requests "were sorry, COM was a mistake, you 424 now have to register under your country code". After all, 425 by the growth argument, in a couple of years the number of 426 companies in COM will be a small percentage of the total 427 population. 429 I don't think this will work. There would certainly be a 430 lot of complaints (and probably legal actions) suggesting 431 that some unfair practices were being followed and that the 432 new requesters were being arbitrarily disadvantaged. I 433 think it would be hard to argue that over 200,000 434 registrations following a procedure in place over 5 years 435 was a small mistake. 437 By the way, I've explored the possibility that there might 438 be technical reasons to limit the size of a domain. For 439 example, not enough disk space, or too big to transfer for 440 .....draft-masek-itld-admin-01.txt Aug. 1996 441 backup, or whatever. The technical experts say not to 442 worry, there are solutions for all those possible problems. 444 A key point in this little story is the statement "This 445 would not fix the trademark, competition, or directory 446 issues, but it would repatriate them.", which is an 447 admission that no problem is solved by this proposal, rather 448 the problem is moved to some other sphere of responsibility. 449 As a practical matter, the suggestion is to close COM and 450 open COM.US. The result would be a lot of pain for 451 registration authorities and staff as well as the companies 452 denied registration in the COM domain, and not much else. 453 All the existing conflicts would emerge at once. Much pain, no gain. 455 A side point to this proposal is that it reinforces 456 nationalistic tendencies rather than supports the shared 457 world spanning community feeling. 459 1.8.4.3 Addressing future needs on the Internet 461 Another compelling reason for expanding iTLDs is the fact 462 that new needs may be inadequately served within the pool 463 of current iTLDs. In the same way that over time, tele- 464 communications numbering has evolved to enable new types 465 of features or services, it would be wise to open Internet 466 addressing now to similar possibilities. An example of 467 this is with operator services dialing. For decades, the 0 468 enabled a direct connection to the operator. Following the 469 break up of the AT&T monopoly during the early 80s in 470 the U.S., suddenly an operator could be for local service OR 471 for long distance service. This was resolved by enabling 472 the dialing of the 00 sequence in order to reach a long 473 distance operator. This was not a small undertaking. Since 474 switches are programmed to connect a call in fractions of a 475 second, a complex time out feature had to be built into 22,000 476 switches made by dozens of different manufacturers. 478 Just because Internet addressing has had a specific format 479 so far should not justify any delays in the provision of new 480 services which may require as in the 00 telecommuni- 481 cations example above, for addressing rules to accommodate for 482 an evolution of the format. More detailed information will be 483 provided in section 6.1.1 of this document regarding 484 iTLDs with an expanded formats. 486 2. Goals 488 First, to facilitate administration of the domain name subsystem within the 489 ....draft-masek-itld-admin-01.txt Aug. 1996 490 Internet by ensuring that there is an open and competitive 491 marketplace for clients to obtain and subsequently maintain 492 delegation of subdomains within the iTLDs, while preserving the 493 operational integrity of the Internet DNS itself. This goal addresses 494 the availability/quantity of domain name possibilities. 496 Secondly, to be responsive to innovative possibilities over the 497 Internet by enabling addressing under a new expanded format 498 not previously exploited. 500 The specific measures to achieve these objectives are as follows: 502 2.1. Provide the IANA with the international legal and financial 503 umbrella of the Internet Society (ISOC), 505 2.2. Allow open competition in domain name registration in the iTLDs, 506 which will then allow registries to charge for their services, 508 2.3. Allow multiple registries to operate cooperatively and fairly in 509 the existing iTLDs and/or other multi-registry iTLDs which may be 510 created, 512 2.4. Facilitate creation of new iTLDs in a fair and useful, but 513 reliable, fashion and phase in a new class of iTLDs referred 514 here as NEW FORMAT iTLDs, 516 2.5. Provide for reliable maintenance of the registrants of an iTLD 517 should the current delegatee no longer wish to maintain it, and 519 2.6. Define iTLD policies and procedures by open methods, modeled on 520 the IETF process and/or using IETF mechanisms when appropriate. 522 2.7. Specify in its assignment agreements that registries must be prepared 523 to offer their services within 90 days of assignment. A maximum grace period of 30 524 days would be extended after which the iTLD would have to be returned in order 525 to be assigned to the second petitioner if any or be made available again to the 526 next entity petitioning for it. 528 3.0 Scope of this Document 530 This document describes the administrative structure for the 531 operation of the iTLDs. While other administrative issues may exist 532 within the broader domain of the DNS, they are not addressed in this 533 document. 535 Specifically: 537 ....draft-masek-itld-admin-01.txt Aug. 1996 538 3.1. Only those relationships between the IANA, IETF, and ISOC which 539 are specifically necessary for responsible maintenance of the 540 iTLDs are described. 542 3.2. The Board of Trustees acts for the ISOC, the IAB for the IETF, 543 and the IANA for itself. 545 3.3. Long range maintenance of the IANA is not described; although it 546 is believed that the IANA should draw financial support from a 547 wide community. 549 3.4. The IETF is not directly involved in operation of the net. 550 Hence it serves the iTLD administrative work mainly in a technical 551 capacity, such as the formalization of new protocols and the 552 handling of technical appeals. 554 3.5. The ISOC does not directly operate the net. But it takes legal 555 responsibility for standards processes and some network management 556 processes, manages funds, and participates in the appeals process. 558 3.6. The IANA and any necessary ad hoc groups deal with operational 559 details. 561 3.7. The ISOC, the IETF, and the IANA are not to be legally or 562 financially responsible for the registries. The registries must 563 be responsible for themselves. 565 3.8. Creation of a large staff is not desired. 567 4. Technical Assumptions 569 Further growth within the iTLDs can be accommodated technically, and 570 tools are in evidence to automate much of the process of registration 571 and maintenance of entries within the DNS as well as multiple 572 administrative access to a single delegated domain. 574 4.1. The size of current TLD databases such as COM, while large, is 575 not really a burden on servers, nor is it expected to become so in 576 the near future. 578 4.2. Procedures which allow mutual exclusion for the creation of 579 names within a single TLD are being developed within the IETF's 580 "dnsind" and "dnssec" working groups, and a test implementation is 581 available. 583 4.3. Tools are being developed to ease the processes of registration 584 and running the information servers which are expected of 585 registries. 586 ....draft-masek-itld-admin-01.txt Aug. 1996 588 5. The Process 590 5.1. The IANA continues to supervise and control all operational 591 aspects of the iTLDs, and is the second level of the appeals 592 process after the registries (which are the first level). It 593 appoints three members to the ad hoc iTLD group. The IANA may 594 directly review appeals and/or it may ask the Internet DNS Names 595 Review Board (IDNB) to participate in the review of an appeal. 596 The IANA has the option of asking the IDNB to review an appeal, or 597 the IANA may handle the appeal itself. 599 As described in RFC 1591 regarding a dispute between parties 600 contending for the management of a national TLD, the IDNB, a 601 committee established by the IANA, will act as a review panel for 602 cases in which the parties can not reach agreement among 603 themselves. 605 Now the role of the IDNB is expanded to include appeals on a 606 technical basis of the process documented in this memo. 608 5.2. The IETF, as part of its normal procedures, publishes documents 609 which describe technical and operational aspects of the domain 610 space including the iTLDs. It also provides an appeals procedure 611 for process issues and appoints two members to the ad hoc iTLD 612 group(s). That is, it reviews appeals that question whether the 613 process was properly followed. 615 5.3. The ISOC provides the legal and financial umbrella, and the 616 final level of the appeal process. It provides an appeals 617 procedure for procedural issues and appoints two members to the ad 618 hoc iTLD group(s). The ISOC assumes legal liability for the 619 process and the iTLDs. The ISOC reviews appeals that question the 620 fairness of the process itself (not the application of the process 621 to a particular case). 623 5.4. The ad hoc working group, for developing procedures and deciding 624 creation of new iTLDs and chartering of registries, consist of 625 seven members appointed by the IANA (3), the IETF (2), and the 626 ISOC (2). 628 5.5. Note that 'ad hoc' means 'for this purpose only.' In this case, 629 a new ad hoc group is created and convened on a periodic basis 630 (probably annual) when needed to change procedures or to review 631 registry and iTLD applications. 633 ....draft-masek-itld-admin-01.txt Aug. 1996 635 5.6. It is estimated that approximately thirty (30) new iTLDs 636 allocated to approximately ten (10) new registries will be created 637 per year. It is expected that this will continue for the next 638 five years - unless something significant happens to change this 639 plan. 641 In this first year of this plan significantly more new iTLDs and 642 registries may be chartered, perhaps up to one-hundred-fifty (150) 643 iTLDs allocated to up to fifty (50) registries. 645 5.7. The policies and procedures to be used by the ad hoc working 646 group will be decided by the first ad hoc group in an open process 647 and will be clearly documented. This group will be appointed and 648 convene in the next few months. It is expected that these 649 policies and procedures will mature over time. 651 5.8. Multiple registries for the COM TLD database, and multiple 652 registries for other (new and old) iTLDs may be created in the 653 future. 655 5.9. New iTLDs and registries will be created over time. This is a 656 direct change to RFC 1591. New iTLDs may be created with a non- 657 exclusive administration arrangement (multiple registries for one 658 iTLD). 660 5.10. The intent is similar to the licensing of radio stations in 661 some countries. 663 5.11. Registries pay for charters, and the fees collected are kept in 664 a fund managed by the ISOC and used for the iTLD process (such as for 665 insurance against an iTLD registry withdrawal or collapse), and 666 possibly to support an evolved future funding model for the IANA. 668 6. Selection of iTLDs and Registries 670 6.1. The New Registries and iTLDs 672 There will be up to one-hundred-fifty (150) new iTLDs allocated to 673 as many as fifty (50) new registries, with no more than two thirds 674 (2/3) in the same country, created in 1996, and chartered to 675 operate for up to five years. 677 In the case that all the applications are from one country (for 678 example, United States) then only thirty-three (33) new 679 registries and only ninety-nine (99) new iTLDs would be 680 established 682 .....draft-masek-itld-admin-01.txt Aug. 1996 684 Up to three iTLDs may be operated by any single organization. 685 Each new registry will choose up to 3 new iTLD names it will 686 manage under its charter. 688 There will be no institution of multiple registries per iTLD in 689 1996 by the ad hoc committee. Registry operators are encouraged 690 to make such arrangements on their own initiative. 692 Summary: A new registry gets up to three new iTLDs for exclusive 693 management for a period of up to five years; if the registry 694 chooses it may establish a joint management of one or more of its 695 iTLDs with other registries. All registries will be reviewed 696 after five years, it is very likely that registries that provide 697 good services will be rechartered. 699 6.1.1. The new iTLD Name Space 701 It is desirable to maintain a "short" suffix on these iTLDs to 702 permit easier use by the public. As such, the presumption will 703 be that only three-character alphanumeric iTLDs will be 704 assigned with the exception described in paragraph below under 705 the title of NEW iTLDs FORMATS. 707 The space of new iTLD names will be restricted to alpha numeric 708 strings of exactly 3 characters. iTLD names are case 709 independent (i.e., COM = com = cOm). 711 NEW iTLD FORMATS 713 As reported earlier, the telecommunications community has over time 714 allowed changes and enhancements to telecommunications 715 numbering plans to accommodate new services or marketplace 716 conditions. The operator 00 example mentioned earlier is 717 one. Another one is 800 numbers which have permitted a 718 zero in the first position such as 800-0XX-XXXX, 719 a numbering sequence historically not permitted on the 720 public network. Another variation is regional dialing 721 plans. In some areas of the country, one must only dial 722 7 digits when calling within the same area code. In other 723 parts of the country, the 1 + all ten digits are required. 724 Another change is within the 800, toll free area code which 725 now allows the charge to consumer of special fees. 726 Emergency 911 service well known in many large 727 metropolitan areas is not available everywhere. 728 Many large areas of the country have no 911 service 729 enabled to this date. 731 ....draft-masek-itld-admin-01.txt Aug. 1996 733 So in summary, dialing or services are not always uniform, 734 ubiquitous or consistent. What is certain thought is that 735 if a new concept is allowed to begin, it has then a chance to 736 serve some or all of the Internet community. On the other 737 hand, to prohibit growth, creativity and diversity just 738 because a small break from tradition is required would run 739 against the widespread principle of responding to the 740 marketplace which has characterized the Internet so far. 741 Further, two character iTLDs already exist but not exactly 742 with the characteristics proposed in this draft so that the 743 transition requested in effect is very minimal. 744 So for those compelling reasons having to do with better 745 serving the Internet community, the following 746 NEW iTLD FORMATS will now be allowed: 748 iTLDs with 2 symbols 750 These symbols will be allowed because of two main reasons: 752 A)They have worldwide significance without regard to the language spoken in a given country. This is important because the Internet has an interest 753 in serving all although its origin may be rooted in countries where English 754 is the primary language. 756 B) They are easily graphically distinguishable from traditional alpha and/or 757 numerical formats now recognized. In other words, they will 758 look and feel different to the Internet community. This is a positive 759 point as far as expanding into new services. The rationale here is 760 if the addressing looks different, it helps highlight how different the actual 761 service is. A parallel can be drawn again to telecommunications numbering. In the U.S., a complete telephone number is comprised of 10 digits. However, shorter numbers exist for the provision of special services. One of these groups of abbreviated dialing format is the N11 group. For example, 411 reaches directory services, 911 emergency, 611 repair services. Because they are different does not diminish network integrity or reliability. Moreover, a nationwide 411 access to local directory is an of an immense benefit to telephone users who otherwise would have to locate a different directory service telephone number for every single local serving area. In a city as large as Los Angeles, this 762 could mean dozens of different directory assistance numbers. Clearly 763 the Internet has an interest in making access to services as simple and 764 useful as possible. 766 These special formats would also acquire by default the 3 symbol version 767 so that no traffic would be denied. in other words 768 . 770 ....draft-masek-itld-admin-01.txt Aug. 1996 772 domainname.SS = connection to service / content 773 domainame.SSS= connection to domainname.SS service / content 775 Where S stands for symbol. The 3 symbol version would not be promoted. 776 Routing/access would simply not be denied. 778 The symbols proposed for inclusion in this special class are: 780 .## 781 .$$ 782 .** 783 .++ 784 .?? 786 Other symbols have either less symbolic value or are not graphically 787 suitable to be conveyed for easy accurate description. These 5 788 proposed iTLDs bring with themselves enormous user recognition 789 worldwide as well as the potential for possibly millions of new 790 additional domain names. 792 Returning to the topic on new standard format iTLDS: 794 ::= 796 ::= | 798 ::= A | B | C | ... | Z 800 ::= 0 | 1 | 2 | ... | 9 802 These names must be generic, i.e., not well known company 803 identifiers or trademarks. iTLDs which are previously 804 registered trademarks are specifically excluded from 805 consideration as appropriate assignments. 807 A possible exception might be for a generic term that is 808 trademarked substantially world wide and is not associated 809 with a particular product or service or purpose other than 810 domain name registration. 812 This condition may be impossible to enforce, since on a world 813 wide basis in may be very difficult to determine if a 814 particular string of letters is a trademark in any country or 815 is the identification of a well known company in any country. 817 ....draft-masek-itld-admin-01.txt Aug. 1996 818 In any case neither the IANA nor the ad hoc committee plan 819 to spend any time or energy on research in this area. The 820 applicants to operate registries and manage iTLDs are on their 821 honor not to select iTLD names knowingly in violation of this 822 condition. 824 6.2. Who May Apply 826 Persons or organizations wishing to operate registries and manage 827 iTLDS shall send applications to the IANA in accordance with the 828 provisions of this memo. 830 A "person or organization" may be a single person or organization 831 or any group of persons and organizations which may combine to 832 offer registration services under one name as a cooperative or 833 competitive provider of services, provided that all partners in 834 the confederation or alliance shall otherwise be in compliance 835 with the terms of this document. 837 Organizations granted iTLD names may add or remove additional 838 cooperating registration partners at their discretion, provided 839 that doing so does not violate the provisions of this memorandum. 841 6.3. Open Process 843 The applications for iTLD domain names and registries shall be 844 evaluated in a neutral, impartial, and open manner. 846 The proceedings and evaluations of the applications submitted 847 shall be available for public inspection via an on-line procedure 848 (e.g., web site) along with the decisions made. 850 Financial and business aspects of proposals are kept confidential 851 during the evaluation process. The complete proposal of the 852 successful applicants, including these aspects, will be made 853 public at the completion of the ad hoc committee process. 855 6.3. Review Criteria 856 All applications are judged on three criteria: Registration 857 Services, Operational Resources, and Business Aspects. 859 Business aspects are not necessarily the most important criteria, 860 reliability, quality of service, sustainability, are also 861 important aspects. 863 When a registry which has provided good quality and reliable 864 service comes up for charter renewal, barring unusual 865 circumstances, the charter renewal application should be approved. 866 ....draft-masek-itld-admin-01.txt Aug. 1996 868 6.3.1. Registration Services 870 Each registry provide the following administrative services and 871 policies for each iTLD they administer: 873 1) Access to the Registration Database 875 The DNS database files and "whois" databases maintained by any 876 iTLD operator are deemed to be publicly available and public, 877 non-protected, information. The intent is to allow easy access 878 to the information needed to investigate and correct 879 operational problems. 881 A registry shall provide guaranteed availability of the 882 registration data in a useful form should transfer of 883 responsibility become necessary, e.g., regular publication of 884 the information, or regular deposits of copies of the 885 information with a reputable "escrow holder" instructed to 886 release the information to the IANA. 888 The IANA is authorized to designate an organizations as the 889 escrow holder of said database information for the purposes 890 described below under "Termination of Registries". 892 The escrow holder will have to keep very up to date copies 893 of the database probably through some automated system that 894 makes a copy on a daily basis. 896 There may be reasons (other than "transfer of responsibility" 897 or "termination of registries") to provide controlled access to 898 the data held by the escrow holder for special purposes, such 899 as legal proceedings in trademark cases. 901 The registry must provide a means, via the "whois" protocol, to 902 search the database of second-level domains maintained by this 903 registry and return common directory information. This 904 information shall include, but not necessarily be limited to: 906 a) The "owner" of the second-level domain, including contact 907 name(s), physical address(es), and telephone number(s) of 908 the persons responsible for the operation of the second- 909 level domain. 911 b) The nameserver hostnames and IP addresses serving that 912 second-level domain. 914 ....draft-masek-itld-admin-01.txt Aug. 1996 916 c) The current status (operational, on hold, pending, etc) of 917 that second-level domain. 919 There is no intent to have a "global phonebook" of second-level 920 domain holders. The intent is to provide information necessary 921 for tracking down and resolving operational problems. 923 iTLD registries are expected to provide their own directory 924 service, and "rWhois" is designated as one of the operational 925 choices which a registry may wish to utilize. However, no 926 attempt is made to mandate any particular technical or 927 organizational requirements from a registry to service requests 928 for lookups of a domain holder in other, competing registries 929 and iTLDs. 931 Internal database and operational issues are to be decided by 932 the registry. These issues, including pricing to customers of 933 the registry, are properly free-market issues and are excluded 934 from the control of the IETF, IANA, ISOC and other related 935 organizations. 937 2) A help desk and staff to answer questions via electronic 938 mail, fax and normal telephone during customary business hours. 940 3) Published policies on services offered, registration 941 procedures, and fees. 943 4) A clear description of the appeals mechanism within the 944 registry, including the entry point for appeals and the 945 expected response time. 947 5) All of the public information identified in points 1 through 948 4 above shall be made available via WWW, FTP, and automated 949 email responder at an address associated with the organization. 951 6.3.2. Operational Resources 953 1) Internet Connectivity 955 A description of the Internet connectivity to the site where 956 each nameserver for each iTLD will be located. 958 For example, a diagram showing full multi-homed connectivity to 959 the organization's computers which will serve as the iTLD 960 nameservers, with each leg of that connectivity being at a 961 non-aggregated data rate of <*** whatever ***>. 962 ....draft-masek-itld-admin-01.txt Aug. 1996 964 And route advertisement via BGP4 for this organization's 965 connectivity must be operational for the connections maintained 966 under this provision, and the network involved should be 967 operating in a "defaultless" configuration. 969 2) Nameserver Performance 971 The description of at least two (2) nameservers for the iTLDs 972 in question. These nameservers shall run the latest 973 "consumable" release of the BIND code (4.9.x at present), and 974 may include local enhancements, changes, or operational 975 improvements. 977 The names and IP addresses of the hosts which are proposed to 978 serve the iTLDs. 980 6.3.3. Business Aspects 982 A description of the applicant which shows sufficient business 983 viability that the registry is likely to operate successfully 984 for at least five years (this is not a business plan, rather 985 some documentation that lends credibility to the applicant's 986 proposal). 988 An initiation fee of USD 10000 payable to the "Internet 989 Society" to be deposited in the "iTLD fund"; and each registry 990 established under this plan will contribute one percent (1%) of 991 its gross income from fees, dues, or other charges to its 992 customers to the "Internet Society" to be deposited in the 993 "iTLD fund", to be paid on a quarterly basis. 995 Included in gross income above are only fees related specifically 996 to the registration process of second level domain names. Any other fees 997 not related to the process of registration itself are excluded from the 1 % 998 contribution. The intention is for funding to be provided for the Internet 999 but it should not mean that operators who choose to branch out with 1000 expanded offerings and invest their own funds for such offerings 1001 be expected to pay fees for such offerings. 1003 6.4. The Application 1005 All of the information required to be supplied with an application 1006 should be prepared for transmission via email in plain ASCII text, 1007 in English. The details of the submission of applications will be 1008 determined by the ad hoc committee. 1010 ....draft-masek-itld-admin-01.txt Aug. 1996 1012 The application shall include the following: 1014 6.4.1. Applicant Name 1016 The name of the applicant, including the contact information. 1018 6.4.2. iTLD Names 1020 The three three-character iTLDs proposed ( or 2 as described earlier ), 1021 along with a statement indemnifying the IANA and the ISOC for any 1022 infringement of trademark which may be created by the IANA 1023 authorizing this assignment. 1025 6.4.3. The Criteria Statements 1027 The applicant's approach to the three criteria of section 6.3, 1028 Registration Services, Operational Resources, and Business 1029 Aspects. 1031 These statements should include: 1033 A clear statement of the charter, policies, and procedures, 1035 a statement of registrant qualification procedures, 1037 a statement that they will be non-discriminatory in the sense 1038 of treating all applicants equally (if a registry chooses to 1039 operate the iTLD "CHM" for companies in the chemical business 1040 it may decline to register companies not in that business) 1042 a description demonstrating the organizational and technical 1043 competence to run a registry and the expected accompanying 1044 information services, 1046 a statement that the registry will 1048 (1) abide by the results of the appeals process (as 1049 described in this memo) and the direction of the IANA, and 1051 (2) hold harmless ISOC, IANA, IETF, the ad hoc committee, 1052 and 1054 (3) obtain the usual prudent insurance. 1056 ....draft-masek-itld-admin-01.txt Aug. 1996 1058 6.4.4. The Application Fee 1060 A non-refundable application fee of USD 1000 payable to the 1061 "Internet Society" for each qualifying iTLD to be deposited in 1062 the "iTLD fund". This application fee is only payable once 1063 it has been confirmed that an iTLD is available and that the 1064 applicant has been found to be the first to apply for such iTLD. 1065 Applicants to more than one iTLD will be given a full status concerning 1066 all their separate applications and will have 7 calendar days 1067 from written notification to abandon one or more applications. 1069 This application fee secures an available iTLD for an applicant 1070 on a first come / first served basis pending the full review 1071 of the other aspects relevant to their application. 1073 6.5. Charters are for a period of five years, but annual progress 1074 reports are submitted for review by IANA and the ad hoc group. Only 1075 in exceptional cases of radical change or abuse of a charter may the 1076 IANA or the ad hoc group recommend to the IANA and ISOC that the 1077 charter be reevaluated before the charter period is reached (see 1078 appeals process, and termination of registries sections). 1080 6.9. Sorting Out the iTLD Requests 1082 It is possible that several applicants will request the same 1083 iTLDs. 1085 Suppose that two or more of the registry applicants that have been 1086 otherwise approved by the ad hoc committee have requested the same 1087 name as one of their new iTLDs. 1089 The ad hoc committee will have to use an unbiased and fair method to 1090 select which applying registry is to manage that iTLD. 1092 This could result is some approved registries having fewer than three 1093 iTLDs to manage. 1095 After all the original iTLD requests of the approved registries have 1096 been resolved any registries with fewer than three iTLDs to manage 1097 will be asked to propose additional iTLD names until three non- 1098 conflicting names have been selected. 1100 6.10. Contract 1102 The actual agreement to establish a new registry will take the form 1103 of a contract between the registry organization and the Internet 1104 Society (ISOC). 1106 6.11. Schedule 1108 There are several stages that each take some time: forming the ad hoc 1109 committee, finalizing the procedure, accepting the applications, and 1110 evaluating the applications. 1112 6.9.1. Assume the ad hoc committee is be formed day 1. 1114 6.9.2. The ad hoc committee will finalize and announce its procedures 1115 by day 30. 1117 6.9.3. The ad hoc committee will accept applications until day 90. 1119 6.9.4. The ad hoc committee will review the applications and announce 1120 its selections by day 135. 1122 For example suppose the ad hoc committee was formed on 1-May-96. 1123 Then the schedule would be: 1125 01-Jul-96 ad hoc committee formed 1127 01-Aug-96 procedures finalized, 1128 begin accepting applications 1130 01-Oct-96 stop accepting applications, 1131 begin evaluation 1133 15-Nov-96 announce selections 1135 7. Termination of Registries 1137 iTLD registries may decide they no longer wish to operate their 1138 registry. Likely, the operation will not be profitable when this 1139 occurs, yet the registrants under the iTLD may need to be supported 1140 for a considerable time. 1142 Some portion of the fees in the ISOC-managed iTLD fund may be used to 1143 pay for some other organization to operate the failing iTLD or 1144 registry until it again becomes viable or until the registrants have 1145 safely migrated elsewhere. 1147 While it is unclear how expensive providing even temporary service 1148 for the iTLDs of a failed registry might be, the iTLD process must be 1149 prepared for the case where a very popular, possibly because it is 1150 low cost, iTLD or registry fails. 1152 Some views on the possible scenarios: 1154 It will be very expensive. 1156 Bailing out the registrants of a failing domain could be very 1157 expensive, even on the order of a million USD (remember, a 1158 likely failure mode may be because someone thought they could 1159 do it for less). 1161 It is not a big deal. 1163 It is presumed that any registry with a significant client base 1164 will constitute a legitimate on-going business interest with 1165 revenue prospects sufficient to insure that the registry will 1166 in fact be transferred to another organization. 1168 As an example, presuming 5,000 registrants of a given registry 1169 and a fee of 50 USD per year, a revenue stream of 250000 USD 1170 per year would inure to the benefit of any organization taking 1171 over the services of a defunct organization. 1173 Should a registry close without having significant second-level 1174 registrations in place at that time, the impact to the Internet 1175 users as a whole will be minimal or non-existent. 1177 Succession issues related to the relationships between customers of a 1178 registry and that registry itself are properly contractual matters 1179 between the registry and its customers, and when properly attended to 1180 do not involve the IETF, ISOC, or the IANA. 1182 The IANA or its designee may operate an "escrow holder" to insure 1183 that the records contained in a registry will remain available in the 1184 event of intentional or accidental destruction due to a registry 1185 forfeiting a iTLD. 1187 Organizations providing registry services may elect to terminate 1188 their involvement in this program and release the iTLD namespace 1189 delegated to their organization under the following circumstances: 1191 7.1. Any organization may transfer the authority for, and 1192 registration services provided, for a iTLD to any other 1193 organization provided that the new registration authority complies 1194 with all provisions of this memorandum. The business and 1195 financial terms under which this transfer is conducted shall be 1196 properly between the old and new registry organizations and not 1197 under the jurisdiction of the IANA, the IETF or the ISOC. However, 1198 the IANA must be notified of such a transfer, and the charter of 1199 the registry for the management of these iTLDs shall be reviewed 1200 as a renewal of the charter at the next normal session of the ad 1201 hoc committee. 1203 7.2. iTLDs which are "orphaned" by a registry that constructively 1204 abandons them or ceases business operations without first securing 1205 a successor organization to assume the authority and registration 1206 services for that namespace shall be deemed "abandoned". 1207 Abandoned iTLD namespace shall be auctioned to the highest bidder 1208 by an open, competitive bid process adjudicated by the IANA or its 1209 designees, which shall be conducted without undue delay. During 1210 the interim period in question the IANA shall be authorized to 1211 designate one or more firm(s) to hold the existing registration 1212 records to prevent the interruption of service. 1214 7.3. An organization that is found by the IANA to be in violation of 1215 the terms of this delegation memorandum shall be given notice by 1216 the IANA of intent to recover the iTLD domain space allocated 1217 under this policy via normal postal mail. Within 30 days, the 1218 organization against which the complaint has been lodged shall a) 1219 cure the violation(s) of this policy, (b) transfer authority to 1220 another organization under 7.1 above, or (c) constructively 1221 abandon for public auction the namespace under the provisions of 1222 7.2 above. Where the facts are disputed regarding possible 1223 violations of this policy, the IANA is authorized to promulgate 1224 reasonable adjudication policies which should include an 1225 arbitration provision. 1227 8. Finances 1229 It is desirable to keep the ISOC, IANA and IETF from becoming 1230 involved in operational and contractual aspects of the iTLD 1231 registries, and it is further desirable to separate, to the extent 1232 possible, the IETF and IANA funding from these organizations. 1234 It is presumed in the best interest of the IETF, the IANA, ant the 1235 ISOC to see that this separation of function is preserved. 1237 Note: 1238 Indemnification provisions from the registries to the IANA and 1239 related organizations may not serve to properly insulate the 1240 ISOC, IANA and IETF from legal proceedings, as it should be 1241 presumed that any organization which is legally challenged in a 1242 significant fashion may be unable to properly pay any judgments 1243 levied against it. Current "deep pockets" legal practice 1244 exposes related organizations to the negative effects of these 1245 legal actions should the original organization be unable to 1246 fulfill its financial obligations. 1248 There is a concern that the presence of a funding path creates 1249 a tying arrangement between for-profit organizations and a set 1250 of non-profit organizations which up to now have not been 1251 legally, financially, or otherwise encumbered by the actions of 1252 these registries. 1254 8.1. A registry may charge as it sees fit, within the bounds of the 1255 policy published when it is chartered. 1257 8.2. The ISOC manages all finances in a separate iTLD fund with open 1258 reporting and published budgets. Agreement of the ISOC, the IANA, 1259 and the IETF is required on all budgets. 1261 8.3. Charter fee income may be used to pay legal costs of the IANA, 1262 IETF, ISOC, and ad hoc groups when legal disputes arise from the 1263 iTLDs process. 1265 8.4. Charter fee income is also used to pay modest and publicly 1266 visible costs of the chartering process, e.g., the costs of the ad 1267 hoc committee, the administrative staff, and costs incurred by the 1268 ISOC. 1270 8.5. Charter fee income may also be used to fund the IANA if and when 1271 it becomes necessary. 1273 8.6. Should the reserves be too large, a consensus of the IANA, IETF, 1274 and ISOC would allow disbursements for the general network good, 1275 e.g., scholarships for engineers from developing countries. 1277 8.7. The ISOC may charge a modest amount for administering the iTLD 1278 account. 1280 9. Appeals 1282 Arbitration to resolve conflicts is encouraged. That an appeals 1283 process is specified should not preclude use of arbitration. The 1284 appeals process described here is for when arbitration has failed or 1285 when the parties decide not to use arbitration, yet they do not wish 1286 to exercise recourse to lawyers and courts. 1288 9.1. The appeals process does not apply to disputes over Intellectual 1289 Property Rights on names (trademark, service mark, copyright). 1290 These disputes are best left to arbitration or the courts. 1291 Registries may require appropriate waivers from registrants. 1293 9.2. The appeals process does not apply to charging and billing. 1294 This is left to market forces, arbitration, and the courts. 1296 9.3. The appeals process applies to all other aspect of registry 1297 processing of registration requests. 1299 9.4. A registrant's first recourse is to the registry which has 1300 denied them registration or otherwise failed to provide the 1301 expected service. 1303 9.5. All registries must specify in their applications an entry point 1304 and a process for appeals, as well as a response time, and must 1305 subsequently conform to them. 1307 9.6. If appellant is dissatisfied with the registry response, appeal 1308 may be escalated to the IANA. The IANA hears appeals based only 1309 on technical issues. Note that the IANA may use the IDNB to 1310 process the appeal. 1312 9.7. The IANA must define its entry point for appeals and must 1313 respond to appeals within four weeks. 1315 9.8. If appellant is dissatisfied with the IANA response, and the 1316 appeal has nontrivial process aspects, the appeal may be escalated 1317 to the IETF. The IETF hears appeals based only on process issues, 1318 that is, claims that the procedure was not followed. 1320 9.9. If appellant is dissatisfied with the IANA and, if invoked, the 1321 IETF response, appeal may be escalated to the ISOC. The ISOC 1322 appeals process hears appeals only about the fairness of the 1323 procedure. I.e. the decision of IANA and/or IETF is final, 1324 unless there is an appeal that the procedure itself is unfair. 1326 9.10. The appeals process works by email. Appellant must provide 1327 concise history of the case and summarize grounds of appeal. The 1328 IANA, the IETF, or the ISOC may ask for information from third 1329 parties. All information is normally treated as nonconfidential 1330 and may be made publicly available. Confidential information is 1331 considered only in special circumstances. 1333 9.11. The IANA, the IETF and the ISOC may establish appeals sub- 1334 committees chosen either from their own membership or outside of 1335 it by whatever means each deems reasonable for their procedures 1336 and purposes. 1338 10. Security Considerations 1340 There are no known security considerations beyond those already 1341 extant in the DNS. 1343 11. Acknowledgments 1345 This memo has been inspired or contains 1346 substantial inclusion of material from a draft by Jon Postel. 1347 The appeals section was originally written by Brian Carpenter. 1349 12. Author's Address 1351 Phone: +1 213-936-4255 1352 Jan Masek Fax: +1 213-936-6789 1353 302 North La Brea Ave. # 1000 Los Angeles, CA 90036 1354 Email: JanKmasek@AOL.COM