idnits 2.17.1 draft-adpkja-dnsop-special-names-problem-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6761]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 665: '...f an application MUST NOT rely on name...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 08, 2016) is 2965 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1034' is defined on line 680, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dnsop-dns-terminology' is defined on line 704, but no explicit reference was found in the text == Unused Reference: 'I-D.lewis-domain-names' is defined on line 714, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 718, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-lewis-domain-names-02 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Abley 3 Internet-Draft Dyn, Inc. 4 Intended status: Informational P. Koch 5 Expires: September 9, 2016 DENIC 6 A. Durand 7 ICANN 8 W. Kumari 9 Google 10 March 08, 2016 12 Problem Statement for the Reservation of Top-Level Domains in the 13 Special-Use Domain Names Registry 14 draft-adpkja-dnsop-special-names-problem-01 16 Abstract 18 The dominant protocol for name resolution on the Internet is the 19 Domain Name System (DNS). However, other protocols exist that are 20 fundamentally different from the DNS, and may or may not share the 21 same namespace. 23 When an end-user triggers resolution of a name on a system which 24 supports multiple, different protocols (or resolution mechanisms) for 25 name resolution, it is desirable that the protocol used is 26 unambiguous, and that requests intended for one protocol are not 27 inadvertently answered using another. 29 [RFC6761] introduced a framework by which, under certain 30 circumstances, a particular domain name could be acknowledged as 31 being special. This framework has been used twice to reserve top- 32 level domains (.local and .onion) that should not be used within the 33 DNS to avoid the possibility of namespace collisions in parallel use 34 of non-DNS name resolution protocols. 36 Various challenges have become apparent with this application of the 37 guidance provided in [RFC6761]. This document aims to document those 38 challenges in the form of a problem statement, to facilitate further 39 discussion of potential solutions. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on September 9, 2016. 58 Copyright Notice 60 Copyright (c) 2016 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 3. RFC6761 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 4. Architectural considerations . . . . . . . . . . . . . . . . 6 79 5. Technical considerations . . . . . . . . . . . . . . . . . . 8 80 6. Organizational considerations . . . . . . . . . . . . . . . . 9 81 6.1. Non-exhaustive list of external organizational 82 considerations . . . . . . . . . . . . . . . . . . . . . 9 83 6.2. IETF Internal considerations . . . . . . . . . . . . . . 10 84 6.2.1. Process . . . . . . . . . . . . . . . . . . . . . . . 10 85 6.2.2. Technical criteria . . . . . . . . . . . . . . . . . 11 86 6.2.3. Name evaluation . . . . . . . . . . . . . . . . . . . 12 87 6.2.4. The ICANN process to evaluate names . . . . . . . . . 12 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 93 10.2. Informative References . . . . . . . . . . . . . . . . . 15 94 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 16 95 A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 A.2. Pithy Quotes from History . . . . . . . . . . . . . . . . 16 97 A.3. Change History . . . . . . . . . . . . . . . . . . . . . 17 98 A.3.1. draft-adpkja-special-names-problem-00 . . . . . . . . 17 99 Appendix B. Change history . . . . . . . . . . . . . . . . . . . 17 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 102 1. Terminology 104 Clear and unambiguous use of terminology is important for the clear 105 formulation of any problem statement. The DNS protocol suffers from 106 imprecise and overloaded terminology (e.g. see RFC7719). The use of 107 terms and concepts from other naming systems that are similar (but 108 different) simply confuses matters further. 110 In the interests of clarity, the following terms used in this 111 document are to be interpreted as follows: 113 Registry (n): the Special-Use Domain Names Registry created by 114 [RFC6761] and published at 117 [This section to be completed following review and refinement of the 118 rest of the text.] 120 2. Introduction 122 A number of systems use the last label in a name to act as a switch 123 to a different, non-DNS resolution process - examples of such 124 switches include: .local (use mDNS) and .onion (use Tor). This 125 switch practice is not explicitly documented anywhere, and the method 126 for accomplishing this varies by implementation. As an interesting 127 aside, the full semantics of domain names isn't really documented 128 anywhere either, although [Ed Lewis domain-names draft] is a current 129 attempt to rectify this. 131 This technique of using the last label as a switch has a number of 132 properties which make it attractive to people implementing alternate 133 name resolution systems, including: 135 o The names can follow the common DNS syntax of LDH labels, 136 separated by dots. This means that these names can be entered in 137 any application which takes exiting DNS names. 139 o The switch to the new resolution process can be implemented in a 140 number of ways, such as custom application code, a shim in the 141 normal DNS resolution process, or on the system's configured DNS 142 servers. 144 o The names "look" like names to users. 146 At this point, one should note RFC6303, which already defines 147 "locally served zones", with the important difference that per 148 RFC6303 the names get registered for special treatment if they are 149 already special - they are not declared special by the registration. 151 [RFC6761] defines ways to reserve domain names and could be read to 152 augment the technical exemption made in [RFC2860] (IETF-ICANN MoU): 154 "Note that (a) assignments of domain names for technical uses 155 (such as domain names for inverse DNS lookup), (b) assignments of 156 specialized address blocks (such as multicast or anycast blocks), 157 and (c) experimental assignments are not considered to be policy 158 issues, and shall remain subject to the provisions of this 159 Section 4." 161 The framework in [RFC6761]RFC6761 has recently been used to reserve 162 the .onion label, allowing it to be used as a switch to the tor 163 resolution process[RFC7686]. By the .onion label in the "Special-Use 164 Domain Names" registry [TODO: WK - Link], The Tor Project can be 165 assured that there will not be a .onion TLD created in the IANA 166 rooted DNS, and thus the possibility of collisions in the namespace 167 will be avoided. 169 The discussions in the DNSOP WG and the IETF Last Call processes 170 about the .onion registration in the Special Use Domain Names 171 registry (1,200 messages) have made it apparent that clarity about if 172 and how to treat this "protocol switching" practice would help a lot 173 in deciding the merit of future similar applications. 175 One possible outcome of the discussion would be to decline to 176 recognize such usage of domain names in the architecture, another one 177 is to formalize it and better understand the issues that come with 178 it. 180 An additional consideration is that names which follow the DNS syntax 181 (including those which use alternate name resolutions processes to 182 the DNS) are in the same namespace as names in the DNS. This means 183 that currently both the IETF (through [RFC6761]) and ICANN are making 184 allocations or reservations from a shared namespace. If this 185 continues to be the case, in order to avoid conflict, close 186 coordination is necessary. 188 3. RFC6761 190 In Section 5, [RFC6761] describes seven questions to be answered to 191 justify how and why a particular domain name is special. These seven 192 questions can be broadly categorized as follows: 194 1. impact on end-users; 196 2. impact on applications; 198 3. impact on name resolution APIs and libraries; 200 4. impact on recursive resolvers; 202 5. impact on authoritative DNS servers; 204 6. impact on DNS server operators; 206 7. impact on DNS registries and registrars. 208 The intent of those seven questions was originally to serve as the 209 justifications for *why* the special-use registration should be 210 granted, demonstrating that it (a) provides a result that the 211 community judges to be good, and (b) the aforementioned good result 212 cannot reasonably be achieved in another way. The rough consensus 213 from significant discussion was that .onion did satisfy both (a) and 214 (b), but this was not clearly demonstrated by the answers to the 215 "seven questions". Furthermore, it is unclear if and how these 216 questions could reliably and unambiguously be used to make the 217 determination, leading to the conclusion that they are generally 218 inadequate for making the determination whether a particular domain 219 name qualifies as requiring special/different treatment. 220 Applications which follow the [RFC6761] process are likely to devolve 221 into a "beauty contest". More over, the answers to the seven 222 questions are not available in a machine readable form to 223 applications that want to follow [RFC6761]. 225 So the answers to these seven questions can better be seen as 226 providing guidance to the corresponding seven audiences on how to 227 handle a special-use domain name once it has been reserved by 228 inclusion in the Registry, and not as entrance filters for inclusion 229 in the registry. 231 They specify desired behavior in the internet for handling a 232 particular domain name, not the basis for deciding whether the effort 233 to implement special behavior across all of those audiences is worth 234 the cost. This indifference to costs is not necessarily scalable. 236 The justification in [RFC6761] is concerned with the rationale of 237 reserving a domain name that precludes its subsequent use as a 238 generic top level domain name. However, the document fails to offer 239 such a rationale, and instead requires the justification of the 240 reserved name to include the provision of guidance to a number of 241 audiences (users, application developers, DNS resolver applications, 242 DNS resolution service operators, and name registries and registrars) 243 as to how to handle names that are listed in this registry. But this 244 guidance is not, in and of itself, an adequate rationale for the 245 selection of a particular name value to be reserved in this registry. 247 What is missing in [RFC6761] is the consideration of the name itself. 248 If one were to contrast the procedures relating to the admission of a 249 name to the IETF Special Use Name registry to the processes 250 associated with the New gTLD Program operated by ICANN, then it is 251 evident that the IETF process does not admit many considerations 252 which appear to be areas of evaluation in the new gTLD program. More 253 on this in a subsequent section. 255 This memo proposes to categorize considerations related to the usage 256 of RFC6761 registry for protocol switches in 3 categories: 257 Architectural, Technical and Organizational. This memo then lists a 258 number of questions to drive the discussion. The list of issues 259 discussed here is non-exhaustive. 261 However, some voices have noted that [RFC6761] describes other 262 alternative special handling aside from protocol switches. That 263 alternative special handling must be considered carefully at the time 264 of publication of the defining RFC, regardless of the nature of the 265 special use. 267 4. Architectural considerations 269 The first thing to consider in this discussion is that not all names 270 (or domain names) are part of the Domain Name System. See [ID-lewis- 271 domain-names] for an in-depth discussion on this topic. 273 At the time of writing, two top-level domain names reserved by 274 inclusion in the Registry are used by name resolution protocols other 275 than the DNS and went through the [RFC6761] process: 277 .local is used by the Multicast DNS protocol specified in 278 [RFC6762] which is similar in some respects to the DNS, but which 279 uses a different well-known port number and is limited to a 280 particular multicast scope; 282 ONION is used to construct names that designate services reachable 283 via the Tor network using onion routing. 285 The two name resolution protocols described above are, to varying 286 degrees, different from the DNS, and the namespaces used in each 287 naming scheme are also different (albeit similar, in the .local 288 case). The top-level label is effectively being used as a name 289 resolution protocol identifier. At the core of the issue is that 290 different "strings" that look like "domain names" (i.e. are within 291 the same name space) but are not DNS names are used interchangeably 292 in the URI (or URN). In particular, DNS imposes constraints on name 293 syntax. An example of such constraints is the 64 octet limit per 294 label. Strings used in the ONION domain do not have that constraint. 295 It could be argued that in the absence of a more elegant alternative, 296 a pragmatic choice to embed protocol selectors as namespace tokens 297 has effectively already been made. The running code and effective 298 consensus in how it should be used by significant user bases should 299 not be discounted. Although the reservation of names in the DNS 300 namespace can be made at any level, the two examples above 301 demonstrate use-cases for reservation at the top-level, and hence 302 that case must be considered. 304 The underlying discussion here is the tussle between the applications 305 and the network. Application architects see using special name tags 306 (a la .onion) as an easy way to get new features deployed. They 307 consider the hurdles of deploying new URI schemes such as 308 http:/onion/onion-name as too onerous and too slow to deploy for 309 their needs. Network architects worry of overloading the semantics 310 of DNS names and/or creating a name space that is larger than the DNS 311 namespace. They refer to bad precedents such as .uucp and .bitnet. 313 The fundamental point to consider here is the unicity (or 314 multiplicity) of the name space. Are we talking about one namespace 315 with different resolution protocols or independent name spaces? 317 It might it be helpful to point out that the property of interest 318 here is the assurance of uniqueness of a name, and another way of 319 thinking about the question is whether it applies across domain names 320 as people expect or need it to? None of this would matter if people 321 didn't expect names constructed according to whatever rules they're 322 following to be unique across a set of names that spans multiple 323 operating environments and resolution protocols. 325 In [RFC2826] the IAB noted that 327 "To remain a global network, the Internet requires the existence 328 of a globally unique public name space. The DNS name space is a 329 hierarchical name space derived from a single, globally unique 330 root." 331 "Maintaining a globally-unique public namespace that supports 332 different name resolution protocols is hence an architectural 333 requirement, and some facility for reservation of top-level 334 domains in the DNS is necessary." 336 If we were to accept the notion that the last label of a domain name 337 is actually a protocol switch, we are actually building a catalog of 338 all top level domains and what resolution protocol each one invokes. 339 Note that such a catalog does not formally exist today, as [RFC6761] 340 is an exception list to the general case which is supposed to use 341 regular DNS as resolution protocol. Such a catalog may remain a 342 concept to guide this discussion or be implemented as an actual IANA 343 registry. In effect, it would associate TLDs with indications on how 344 applications and resolvers should treat them. However, such an 345 approach would leave open the question of not-yet-defined TLDs. No 346 resolution mechanism could be associated with those. 348 It should also be noted that there are choices for a protocol switch 349 other than reserving labels. In particular, a proposal to move those 350 protocol switches under a specific top level domain has been 351 discussed (.ALT). If that architecture choice is made, some of the 352 questions listed in the sections below would become moot. 354 Note: [RFC6761] mentions the reserved names could be any label in any 355 random string, not just the rightmost one (or ones). However, this 356 creates a number of complications and has not seen much support in 357 the community as of now. 359 5. Technical considerations 361 Each of the seven questions posed by [RFC6761] has the potential to 362 describe why special handling of the requested name(s) in 363 applications by a particular audience may be necessary. However, 364 aside from reserving the name, it is not entirely clear what any of 365 those audiences might further expect as a result of a successful 366 request to add a top-level domain to the Registry. 368 For example, reservation of a top-level domain by the IETF does not 369 guarantee that DNS queries for names within a reserved domain will 370 not be sent over the Internet. The requirements of the operators of 371 recursive resolvers in the DNS cannot be relied upon to be 372 implemented; the impact on the operators of DNS authoritative servers 373 hence cannot be reliably assumed to be zero. In the case of [I- 374 D.ietf-dnsop-onion-tld], leakage of .onion queries on the Internet 375 might lead to disclosure of private information that, in some cases, 376 might pose a risk to the personal safety of end-users. 378 At the time of writing, the [RFC6761] registry does not include 379 direct guidance for any of the seven audiences, relying instead upon 380 a reference for each entry in the Registry to the document that 381 requested its insertion. Such documents might well be opaque to many 382 readers; ([RFC6762] is a seventy-page protocol specification, for 383 example, which is arguably not the most effective way to set 384 expectations of non-technical end-users). 386 Useful reservations of top-level domains should be accompanied by 387 documentation of realistic expectations of each of the seven 388 audiences, and the evaluation of particular requests should consider 389 the practical likelihood of those expectations being met and the 390 implications if they are not. 392 Here is a non-exhaustive list of additional questions that have 393 surfaced in discussion of requests for names to be added to the 394 Special Use Names registry: 396 What does it mean to have a "non-DNS" entry in the registry 397 described above? 399 Are applications supposed to check that registry to know what to 400 do? 402 Can/Should applications do this check dynamically? 404 What if an application makes this dynamic check and realizes the 405 name contains a switch it does not know how to treat? 407 Similar questions applies to resolvers (DNS and non-DNS); what is the 408 expected behavior? 410 One particular avenue of investigation would be to see if such 411 considerations could be encoded in machine understandable code in an 412 extension of the current [RFC6761] registry. 414 6. Organizational considerations 416 Organizational considerations can be broken down in two categories, 417 internal and external. 419 6.1. Non-exhaustive list of external organizational considerations 421 The policy surrounding the implementation and management of top-level 422 domains in the DNS has been developed using a multi-stakeholder 423 process convened by ICANN according to the MoU between ICANN and IETF 424 [RFC2860]. It is out of scope for this document to revisit that MoU. 426 Whilst discussing the particular attributes that make a domain name 427 special, [RFC6761] notes that "the act of defining such a special 428 name creates a higher-level protocol rule, above ICANN's management 429 of allocatable names on the public Internet." 431 [RFC2860] draws a line between what is policy and what is technical. 432 A variety of opinions have been expressed regarding whether [RFC6761] 433 blurs this line. In particular, see http://www.circleid.com/ 434 posts/20151222_whats_in_a_name/ for a certain viewpoint on the topic. 435 As noted earlier, it is out of scope for this document to analyse 436 this issue beyond noting that such a variety of views exist. 438 Taking a different perspective, it has been argued that [RFC6761] 439 specifically extends the DNS protocol to include special treatment 440 for names in the registry, and that there's nothing in 2860 at all 441 that limits the IETF's authority to change the protocol. 443 However, it should be noted that, if the IETF were to formalize the 444 concept of protocol/name switch in the Internet architecture, 445 coordination would be require between ICANN and IETF on such names. 446 Using the analogy described above of a catalog/registry of such 447 switches, care must be taken to make sure we do not end up with 2 448 process streams allowed to create entries without any 449 synchronization. 451 6.2. IETF Internal considerations 453 6.2.1. Process 455 [RFC6761] specifies the way in which "an IETF 'Standards Action' or 456 'IESG Approval' document" should present answers to the questions 457 described above (see Section 2), but does not describe the process by 458 which the answers to those questions should be evaluated. 460 For example, it is not clear who is responsible for carrying out an 461 evaluation. A document which requests additions to the Registry 462 might be performed by the IESG, by the IAB, by the DNSOP working 463 group, by an ad-hoc working group, by expert review or any 464 combination of those approaches. [RFC6761] provides no direction. 466 As an illustration of the inconsistency that has been observed 467 already, [RFC6762] was published as an AD-sponsored individual 468 submission in the INT area, and the IESG evaluation record does not 469 reveal any discussion of the reservation of the .local top-level 470 domain in the DNS. [I-D.ietf-dnsop-onion-tld], however, was 471 published as a working group document through DNSOP, and an extensive 472 discussion by both the participants of DNSOP and the IESG on the 473 merits of the request took place. The evaluation process, in the 474 absence of clear direction, is demonstrably inconsistent. 476 We should point to RFC 5226 and explicitly quote the definition of 477 "Standards Action" or "IESG Approval": 479 IESG Approval is not intended to be used often or as a "common 480 case"; indeed, it has seldom been used in practice during the 481 period RFC 2434 was in effect. Rather, it is intended to be 482 available in conjunction with other policies as a fall-back 483 mechanism in the case where one of the other allowable approval 484 mechanisms cannot be employed in a timely fashion or for some 485 other compelling reason. IESG Approval is not intended to 486 circumvent the public review processes implied by other policies 487 that could have been employed for a particular assignment. IESG 488 Approval would be appropriate, however, in cases where expediency 489 is desired and there is strong consensus for making the assignment 490 (e.g., WG consensus). 492 So, while it is very interesting to note that [RFC6761] was an AD 493 sponsored individual submission in spite of two active DNS related 494 WGs, 6762 is probably clean: it defines the protocol and is itself on 495 standards track. 497 RFC 7686 however, while on standards track, does not define the TOR 498 protocol, so it was used to fulfill the 'standards action' 499 requirement by the letter. It contains normative references to non- 500 IETF protocols, which is noteworthy. 502 A comparison of the two '7 question forms' reveals that at least the 503 responses to questions 2, 3, and 4, differ significantly while there 504 is no defined way to communicate the difference to the affected 505 software entities. 507 An alternate view has been expressed with regard to the protocol 508 evaluation. It states that the authority belongs to the IESG to seek 509 whatever support it likes, within the established process, in making 510 standards decisions, including delegating evaluation of a specific 511 registry change proposal to a WG or a directorate. The IESG might 512 have varied what guidance it sought, but that does not constitute 513 "inconsistency" under the process. That being said, more complete 514 evaluation guidance would be helpful to the IESG and the community. 516 6.2.2. Technical criteria 518 Regardless of the actual name being proposed as protocol and/or 519 namespace switch, it is also not clear what technical criteria the 520 evaluation body should use to examine the merit of an application for 521 such a reserved name/protocol switch. For example, is large scale 522 prior deployment an acceptable criteria? A number of voices have 523 clearly answered "no" to that question as it would only encourage 524 "squatting" on names. 526 However, in the case of .local and .onion, those particular domain 527 names were already in use by a substantial population of end-users at 528 the time they were requested to be added to the Registry. Rightly or 529 not, the practical cost of a transition away from the requested 530 strings was argued as a justification for their inclusion in the 531 registry. 533 6.2.3. Name evaluation 535 With regard to the actual choice of name, [RFC6761] is silent. The 536 answers to the seven questions are expected to tell how a name, 537 presumably already chosen outside of the process, might be handled if 538 it is determined to be a "special use" name. However, it is silent 539 on how to choose a name or how to evaluate a specific proposed name. 541 6.2.4. The ICANN process to evaluate names 543 Section 4.3 of [RFC2860] says: 545 Two particular assigned spaces present policy issues in addition 546 to the technical considerations specified by the IETF: the 547 assignment of domain names, and the assignment of IP address 548 blocks. 550 This remains as true today as when it was written (2000). Domain 551 names have a number of considerations that have complex policy issues 552 that ICANN deals with and which the IETF may not be well equipped to 553 handle. 555 The ICANN process applicant have to go through to get a name is 556 described in the applicant guide book 557 https://newgtlds.icann.org/en/applicants/agb/guidebook-full- 558 04jun12-en.pdf which is a 338 page document. It should however be 559 noted that the current round of gTLD application is closed and rules 560 may differ in the next round if and when it happens. 562 Considerations include, but are not limited to: 564 Geographical During the most recent round of new gTLD applications, 565 there were a number of applications for so call "geographic" 566 terms. These included applications for .amazon and .patagonia. 567 The .amazon application in particular was controversial - the 568 governments of Brazil and Peru requested that ICANN's Governmental 569 Advisory Committee (GAC) to issue a warning that granting .amazon 570 to Amazon would "prevent the use of this domain for purposes of 571 public interest related to the protection, promotion, and 572 awareness raising on issues related to the Amazon biome." The 573 IETF is not well suited to evaluating this sort of issue. 575 Brands / Trademark law If Wile E. Coyote approached the IETF 576 requesting that the IETF reserve .acme, a trademark held by a 577 large corporation making anvils and giant slingslots, the IETF 578 could become embroiled in trademark lawsuit - and even if the IETF 579 were not, we have enough armchair lawyers that the discussions 580 would be extremely annoying :-). Closely related to this issue is 581 "protected designation of origin (PDO)" - for example, Champagne. 583 String similarity ICANN has an entire process for evaluating the 584 string similarity / confusability between applied for (and 585 current) strings - for example, under what conditions would the 586 IETF be able to make a determination if someone attempted to use 587 RFC6761 to reserve .c0m? 589 International Organization Names Certain names and organizations get 590 additional protection under trademark law - well known examples of 591 this are the RedCross/RedCrescent and the International Olympic 592 Committee (IOC). Whether or not this should be the case is well 593 outside anything that the IETF should have an opinion on but, 594 undoubtedly, there are many within the community who will have an 595 opinion (and will want to argue it ad nauseam :-)) 597 Offensive Terms There are a huge range of these, from the obscure / 598 archaic (waesucks, gadsbudlikins) to the more obvious and current 599 ([xml2rfc-error], [xml2rfc-error] and [xml2rfc-error]. Certain 600 terms are sufficiently offensive that the IETF would have a hard 601 time coming to any useful consensus (other then "Eeeew!") 603 Going back to the IETF process used for the evaluation of .local and 604 .onion, one might ask the following questions: 606 For example, what consideration have there been in the 607 intellectual property rights in the reservation of a name in this 608 Special Use Name registry, and what procedures should be followed 609 in the case of a dispute over the rights to use a name in this 610 manner? Also, to what extent could such a reservation of a name 611 in this Special Use Names registry be used to block competing 612 interests and/or competing technologies? What are the competition 613 and consumer issues that need to be considered if the reservation 614 of a name in this registry causes some form of exclusive access 615 and reduced competitive access, or where there is no ability for 616 consumers to exercise choice in a situation where providers 617 compete in the offering of services? 619 A related consideration is that the current process of admission 620 to the Special Use Name registry appears to admit no formal 621 assessment of environmental impact. Is the name that is proposed 622 to be entered into this registry already being used in local 623 contexts, with or without an association with DNS name resolution, 624 such that its use as a reserved name through an entry in this 625 registry, and its continued use in local contexts could cause harm 626 to users? To what extent can this impact be assessed, and what 627 level of impact is considered acceptable? 629 While the "seven questions" relate to altered behaviours by 630 specific audiences and users of names there is no explicit 631 consideration of the security in this process. Is the 632 registration of such a name a "safe" action for the IETF to take? 633 To what extent could the use of this reserved name be used in a 634 hostile or malicious manner? What measures have been taken to 635 mitigate or otherwise address such potential vulnerabilities? 637 ICANN has created an entire set of groups, organizations, committees, 638 processes and procedures to deal with the evaluation of applied for 639 new TLDs, complete with a cadre of lawyers and policy people. Unless 640 the IETF were willing to do the same, it would have a hard time 641 performing evaluation of the strings themselves, distinct from the 642 evaluation of the technology behind the name resolution system. 644 An alternate view has been expressed, that such a process is not 645 necessary because the IESG is the body that makes the decision on a 646 specific name reserved by RFC6761, and the IETF has a workable appeal 647 process to deal with any potential issues. However, looking at the 648 level of contention created in the ICANN process around the choice of 649 certain names, serious doubts have been expressed to the scalability 650 and ultimate viability of such an appeal process. 652 7. Security Considerations 654 This document aims to provide a problem statement that will inform 655 future work. Whilst security and privacy are fundamental 656 considerations, this document expects that future work will include 657 such analysis, and hence no attempt is made to do so here. See among 658 other places SAC-057 [https://www.icann.org/en/system/files/files/ 659 sac-057-en.pdf] 661 Reserving names has been presented as a way to prevent leakage into 662 the DNS. However, instructing resolvers to not forward the queries 663 (and/or by instructing authoritative servers not to respond) will 664 garantee that such leakage will not happen. The security (or 665 privacy) of an application MUST NOT rely on names not being exposed 666 to the Internet DNS resolution system. 668 8. IANA Considerations 670 This document has no IANA actions. 672 9. Acknowledgements 674 Your name here, etc. 676 10. References 678 10.1. Normative References 680 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 681 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 682 . 684 [RFC1035] Mockapetris, P., "Domain names - implementation and 685 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 686 November 1987, . 688 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 689 Understanding Concerning the Technical Work of the 690 Internet Assigned Numbers Authority", RFC 2860, 691 DOI 10.17487/RFC2860, June 2000, 692 . 694 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 695 RFC 6761, DOI 10.17487/RFC6761, February 2013, 696 . 698 [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 699 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 700 2015, . 702 10.2. Informative References 704 [I-D.ietf-dnsop-dns-terminology] 705 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 706 Terminology", draft-ietf-dnsop-dns-terminology-05 (work in 707 progress), September 2015. 709 [I-D.ietf-dnsop-onion-tld] 710 Appelbaum, J. and A. Muffett, "The .onion Special-Use 711 Domain Name", draft-ietf-dnsop-onion-tld-01 (work in 712 progress), September 2015. 714 [I-D.lewis-domain-names] 715 Lewis, E., "Domain Names", draft-lewis-domain-names-02 716 (work in progress), January 2016. 718 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 719 and E. Lear, "Address Allocation for Private Internets", 720 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 721 . 723 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 724 Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 725 2000, . 727 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 728 DOI 10.17487/RFC6762, February 2013, 729 . 731 Appendix A. Editorial Notes 733 This section (and sub-sections) to be removed prior to publication. 735 A.1. Venue 737 An appropriate forum for discussion of this draft is for now the 738 dnsop working group. 740 A.2. Pithy Quotes from History 742 The question has arisen as to how the toplevel naming authority 743 decides who gets a toplevel name and who must get by with a non- 744 toplevel name. The suggestion was made by MOCKAPETRIS@USC-ISIF 745 that perhaps the existing toplevel nameholders might vote on 746 whether the applicant for a new toplevel name should be granted, 747 with a majority needed for approval. It seems to me this might 748 produce a clique whereby whoever initially gains power will hold 749 it and prevent its "enemies" from getting in too. This will make 750 the toplevel rather less than universal. 752 (E-mail from Robert Elton Maas to the namedroppers mailing list on 9 753 November 1983) 755 My basic point is that as a world-wide network evolves it is 756 ridiculous to force people to name resources in terms of one 757 static hierarchy which very closely resembles the current 758 internetwork topology (as the current scheme does). What we are 759 eventually going to require is a distributed expert for making 760 sense out of a name someone hands it. There will be no simple 761 algorithm to be written on one page of an RFC that will suffice to 762 resolve a name. Rather, a number of heuristics will let a 763 resolver make sense out of a given name by querying other experts 764 which it suspects may be more knowledgeable about the name than it 765 is, or by forwarding a piece of mail to an expert which is at 766 least one level closer to the destination in some hierarchy. 768 (E-mail from Peter Karp to the namedroppers mailing list on 8 769 February 1984) 771 A.3. Change History 773 A.3.1. draft-adpkja-special-names-problem-00 775 Initial draft circulated for comment. 777 Appendix B. Change history 779 [ RFC Editor: Please remove this section before publication] 781 -00 to -01: 783 o Significant readability changes. 785 o [WK: Stopped at end of Sec 3] 787 -00: 789 o Initial draft circulated for comment. 791 Authors' Addresses 793 Joe Abley 794 Dyn, Inc. 795 103-186 Albert Street 796 London, ON N6A 1M1 797 Canada 799 Phone: +1 519 670 9327 800 Email: jabley@dyn.com 801 Peter Koch 802 DENIC 804 Email: pk@denic.de 806 Alain Durand 807 ICANN 809 Email: alain.durand@icann.org 811 Warren 812 Google 814 Email: warren@kumari.net