idnits 2.17.1 draft-faltstrom-registry-registrar-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 312 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of lines with control characters in the document. ** The abstract seems to contain references ([ENUM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 53 has weird spacing: '..."), the and r...' -- 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 (June 14, 2001) is 8345 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) -- Missing reference section? 'ENUM' on line 38 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P Faltstrom 2 Internet-Draft Cisco Systems 3 Expires: December 14, 2001 June 14, 2001 5 Explanation of the registry/registrar concept 6 draft-faltstrom-registry-registrar-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on September 27, 2001. 31 Copyright Notice 33 Copyright (C) The Internet Society (2001). All Rights Reserved. 35 Abstract 37 In discussions between IETF and ITU regarding administration of 38 services specificed according to RFC 2916 [ENUM], it is observed 39 that several documents talk about registries and registrars 40 in a way which is not in accordance with normal use in the DNS. 42 To help the discussions, IETF has via the ISOC Sector Membership 43 in ITU-T submitted this text to the Q.1/2 Rapporteurs meeting in 44 Oslo 25th - 29th June 2001. 46 1. Introduction 48 Many documents that have been circulated regarding ENUM issues in the 49 ITU-T have reflecte considerable confusion regarding DNS terminology. 50 In particular, there appears to be confusion and inconsistent use of 51 the terms "registry" and "registrar". Also, when DNS "zones" are 52 hierarchically separated (at what is referred to as a "zone cut", 53 using a process technically known as "delegation"), the and roles of 54 these parties appear to be further confused. 56 This document explains the terms, and argues that no attempt should 57 be made to redefine them in an ENUM world relative to other DNS 58 applications. 60 2. Zones and Delegations 62 A domain name can exist in only one zone in the DNS. This is 63 established in the definition of the DNS, where all domain names are 64 found by querying first a server for the root zone, and then 65 repeatedly querying servers in a recursive manner until the requested 66 record is either found, or an authoritative "NO" is received. 68 The recursion is based on a concept called delegations. 70 The root zone contains delegations to the various top-level domains 71 (TLDs) that exist. Each of those TLDs may (and usually does) have 72 further delegations to servers that handle child (hierarchically 73 subsidiary) domains of those TLD's. This relationship can be repeated at 74 any place in the domain name hierarchy where a dot (".") is found: 75 I.e., any domain may be structured to have one or more delegated 76 subdomains, which may, in turn, have delegated subdomains, and so on, 77 and each of those subdomains may be administered by a different 78 individual or organization. 80 For a given subdomain, the delegation itself consists of DNS records 81 that identify the authoritative name servers for the subdomains. 83 The examples below assume that DNS records have not been "cached": 84 caching makes the process of finding a name more efficient (i.e., 85 some steps may be bypassed since relevant information is already on 86 hand), but does change the basic logic of the system. 88 Example: The root zone contains a delegation for the domain INT, 89 which points at the name servers for the INT domain. In the INT zone, 90 delegations are present for subdomains of INT, such as ITU.INT. To 91 find the IP address for WWW.ITU.INT, one first queries the root 92 server. The root server gives back pointers to the name servers for 93 INT. When queried, they, in turn, give back pointers to the name 94 servers for ITU.INT. Those servers are then queried to obtain the IP 95 address. 97 3. Registry and Registrar 99 The organization that operates the DNS server(s) for a specific zone 100 is called a registry. To get any kind of information into a zone, one 101 has to contact that very registry. Given the way the DNS is designed 102 (see above), the registry function for a given zone is necessarily a 103 monopoly. 105 To allow competition regarding registration services the market has 106 introduced the concept of a "registrar". The registrar is an 107 organization that can act, from a customer perspective, as a proxy 108 for the registry. So the customer (registrant) who wants names 109 registered in a specific zone does not approach the registry 110 directly, but instead contacts a registrar. The registrar collects 111 the necessary information, ensures that registrar-level conditions 112 are adhered to, and then passes the information to the registry and 113 verifies that the changes to the zone are performed. 115 This way the registry can be extremely lightweight (not doing more 116 than running a database and creating the zone file) while the 117 registrars do all the work (which might include invoicing the 118 registrant). The division of labor between registry and registrar is, 119 however, not fixed by the DNS protocols. It differs somewhat among 120 the various domain that use this scheme today (examples are the TLDs 121 "COM", "UK" and "SE"). And, since the division of responsibilities 122 between registrar and registry is, in general, a market-driven 123 mechanism rather than fundamental to the DNS, many zones (especially 124 deep in the hierarchy) do not use it. 126 5. Delegations 128 When requesting a delegation, the administrator of the child domain 129 becomes a registrant in the parent domain, and because of this, the 130 registrant contacts the registrar for the parent domain and requests 131 the delegation. The registrar passes information to the registry and 132 sees that the delegation is performed. 134 On the other hand, the delegation itself (at the zone file level) is 135 from the registry in the parent zone directly to the registry for the 136 child zone. 138 In other words, the registry at one level in the DNS tree is the 139 registrant of a domain name in the parent level. 141 The chain of zones is only between registries (and the zone files 142 they maintain), while the registrars (if they exist) only act on 143 behalf of registries as an aid to competition and greater registrant 144 administrative flexibility. 146 6. Services referenced by URIs according to RFC 2916 148 An end user (consumer) might have an email address at one email 149 service provider, a SIP address at an IP-Telephony provider, and an 150 E.164 number at a Telco. These might be three different service 151 providers, providing three different services. Each one of these 152 services can be identified by a URI (in a "NAPTR" DNS record). The 153 protocol specified by RFC 2916 specifies that the necessary 154 information to access each of the services, using only the customer's 155 telco-based E.164 number, can be stored as URIs in the DNS. 157 Given that one can only have one registry for each zone in DNS, one 158 can only have one registry for the zone that holds the NAPTR records 159 for all three services. At this level, as at every other level in 160 the DNS tree, one can, of course, have multiple registrars if 161 competition at that level and for those services is desired. 163 7. Tiers 165 The term "tier" has been introduced into ENUM discussions in ITU-T. 166 When that term is used together with the concepts of registry and 167 registrar, there is confusion about roles, i.e., which entities 168 perform which functions. 170 We have understood that the Tier definition is more closely bound to 171 functional layers than to names of particular entities or roles. 173 Tier 0: Management of the e164.arpa zone 174 Tier 1: Management of a CC 175 Tier 2: Management of a full E.164 number 177 Given this view on the specific Tiers, and the descriptions above, 178 one can conclude the following. 180 7.1 Tier 0 182 RFC 2916 defines in its IANA considerations section the following: 184 4. IANA Considerations 186 This memo requests that the IANA delegate the E164.ARPA domain 187 following instructions to be provided by the IAB. Names within this 188 zone are to be delegated to parties according to the ITU 189 recommendation E.164. The names allocated should be hierarchic in 190 accordance with ITU Recommendation E.164, and the codes should 191 assigned in accordance with that Recommendation. 193 Delegations in the zone e164.arpa (not delegations in delegated 194 domains of e164.arpa) should be done after Expert Review, and the 195 IESG will appoint a designated expert. 197 Through the IAB, the IETF has appointed RIPE-NCC as the operator of 198 the e164.arpa zone. The IESG intends to appoint ITU, or an 199 ITU-designated subdivision or entity, the designated expert for 200 determining the contents and delegations of the top-level ("tier 0") 201 E164.ARPA zone. The IAB and RIPE-NCC continue to wait for ITU to 202 come with suggestions on how this root is to be administrated between 203 the two organizations and how the registry of the zone (today 204 RIPE-NCC) is to verify whether an application is authoritative or not. 206 7.2 Tier 1 208 The national level. As a national matter and choice, this level may 209 be organized into several registries or may be only a single 210 registry. Various examples of how Tier 1 can be organized for a given 211 country are described in other contributions to this meeting, but it 212 is important to remember that the selection of an organizational 213 approach and structure, as well as the particular operators involved, 214 are strictly national matters: the protocols, the DNS, and the 215 structure at Tier 0 permit a very broad range of options. 217 Also, whether there is single registry in Tier 1 for a telephony 218 country code, or if have more than one is used (e.g., additional 219 levels are introduced, such as one handling the CC, and then one for 220 each NDC) then the registries in child zones for the CC can contact a 221 registrar for the parent zone if competition is desired. 223 I.e. as is described in section 5, delegations are done directly from 224 parent registry to child registry, but the request for delegation 225 goes potentially from child registry via a registrar for the parent 226 zone to the parent registry. 228 7.3 Tier 2 230 At Tier 2 only the NAPTR resource records are stored in DNS. This 231 means that a registry that operates at Tier 2 operates a zone that 232 corresponds, according to RFC 2916, to the full subscriber number. 233 The registry can, as is described above, be accessed through 234 registrars if desired, but, most important, as is described in 6, 235 there should be equal access for all service providers who provide 236 services for the same customer in the zone. I.e. all service 237 providers must be able to enter information in the zone. This can 238 happen by having the consumer (registrant) take necessary information 239 from the service provider and giving it to the registry of his 240 choice, or a registrar for the same registry, or, in principle, by a 241 range of other alternatives. As at Tier 1, how a given set of zones 242 and the associated administrative and registration arrangements are 243 structured is strictly a national matter. 245 8. Proposal 247 It is proposed that ITU-T in its documents very carefully verifies 248 that the terms "registry", "registrar", "domain" and "zone" are used 249 consistently and according to definitions in this document and 250 elsewhere in IETF standard definitions and specifications of the DNS. 251 Altered use of these terms, and introduction of new terms such as 252 "ENUM Service registry" with conflicting meanings, only adds 253 confusion and misunderstandings. For example, the definition of 254 "ENUM Service registry" has very little to do with the definition of 255 the term "registry". 257 References 259 Authors' Address 261 Patrik Faltstrom 262 Cisco Systems Inc 263 Arstaangsvagen 31J 264 117 43 Stockholm 265 Sweden 267 Email: paf@cisco.com 268 URI: http://www.cisco.se 270 Full Copyright Statement 272 Copyright (C) The Internet Society (2001). All Rights Reserved. 274 This document and translations of it may be copied and furnished to 275 others, and derivative works that comment on or otherwise explain it 276 or assist in its implementation may be prepared, copied, published 277 and distributed, in whole or in part, without restriction of any 278 kind, provided that the above copyright notice and this paragraph 279 are included on all such copies and derivative works. However, this 280 document itself may not be modified in any way, such as by removing 281 the copyright notice or references to the Internet Society or other 282 Internet organizations, except as needed for the purpose of 283 developing Internet standards in which case the procedures for 284 copyrights defined in the Internet Standards process must be 285 followed, or as required to translate it into languages other than 286 English. 288 The limited permissions granted above are perpetual and will not be 289 revoked by the Internet Society or its successors or assigns. 291 This document and the information contained herein is provided on an 292 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 293 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 294 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 295 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 296 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 298 Acknowledgement 300 Funding for the RFC editor function is currently provided by the 301 Internet Society.