idnits 2.17.1 draft-ietf-enum-infrastructure-enum-reqs-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 299. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 21, 2007) is 6185 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3761 (ref. '2') (Obsoleted by RFC 6116, RFC 6117) ** Obsolete normative reference: RFC 2870 (ref. '6') (Obsoleted by RFC 7720) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM S. Lind 3 Internet-Draft AT&T Labs 4 Intended status: Informational P. Pfautz 5 Expires: November 22, 2007 AT&T 6 May 21, 2007 8 Infrastructure ENUM Requirements 9 draft-ietf-enum-infrastructure-enum-reqs-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 22, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document provides requirements for "infrastructure" or "carrier" 43 ENUM (E.164 Number Mapping), defined as the use of RFC 3761 44 technology to facilitate interconnection of networks for E.164 number 45 addressed services, in particular but not restricted to VoIP (Voice 46 over IP.) 48 Table of Contents 50 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Infrastructure ENUM . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Requirements for Infrastructure ENUM . . . . . . . . . . . . . 4 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 57 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 59 Intellectual Property and Copyright Statements . . . . . . . . . . 8 61 1. Terminology 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in BCP 14, RFC2119 [1]. 67 2. Infrastructure ENUM 69 2.1. Definition 71 Infrastructure ENUM is defined as the use of the technology in 72 RFC3761 [2] by the carrier-of-record (as defined below) for a 73 specific E.164 number [3] to publish the mapping of the E.164 number 74 into a URI [4] that identifies a specific point of interconnection to 75 that service provider's network. It is separate from any URIs that 76 the end user, who registers their E.164 number, may wish to associate 77 with that E.164 number. 79 "Infrastructure ENUM" is distinguished from "End User ENUM", defined 80 in RFC3761 [2], in which the entity or person having the right-to-use 81 a number has the sole discretion about the content of the associated 82 domain and thus the zone content. From a domain registration 83 perspective, the end user number assignee is thus the registrant. 84 Within the infrastructure ENUM namespace, we use the term "carrier- 85 of-record" for the entity having discretion over the domain and zone 86 content and acting as the registrant. The "carrier-of-record" is: 88 o The Service Provider to which the E.164 number was allocated for 89 end user assignment, whether by the National Regulatory Authority 90 (NRA) or the International Telecommunication Union (ITU), for 91 instance a code under "International Networks" (+882) or "Universal 92 Personal Telecommunications (UPT)" (+878) or, 94 o if the number is ported, the service provider to which the number 95 was ported, or 97 o where numbers are assigned directly to end users, the service 98 provider that the end user number assignee has chosen to provide a 99 Public Switched Telephone Network/Public Land Mobile Network (PSTN/ 100 PLMN) point-of-interconnect for the number 102 It is understood that the definition of carrier-of-record within a 103 given jurisdiction is subject to modification by national 104 authorities. 106 2.2. Background 108 Voice service providers use E.164 numbers currently as their main 109 naming and routing vehicle. Infrastructure ENUM in e164.arpa or 110 another publicly available tree allows service providers to link 111 Internet based resources such as URIs to E.164 numbers. This allows 112 service providers in addition to interconnecting via the PSTN/PLMN 113 (or exclusively) to peer via IP-based protocols. Service providers 114 may announce all E.164 numbers or number ranges they host, regardless 115 of whether the final end user device is on the Internet, on IP-based 116 open or closed Next Generation Networks (NGNs) or on the PSTN or 117 PLMN, provided an access point of some type to the destination 118 service provider's network is available on the Internet. There is 119 also no guarantee that the originating service provider querying 120 infrastructure ENUM is able to access the ingress network element of 121 the destination provider's network. Additional peering and 122 accounting agreements requiring authentication may be necessary. The 123 access provided may also be to a shared network of a group of 124 providers, resolving the final destination network within the shared 125 network. 127 3. Requirements for Infrastructure ENUM 129 1. Infrastructure ENUM SHALL provide a means for a provider to 130 populate DNS resource records (RRs) for the E.164 numbering 131 resources for which it is the carrier-of-record in a single 132 common publicly accessible namespace. The single common 133 namespace ultimately designated may or may not be the same as 134 that designated for End User ENUM (e164.arpa.) The FQDN in the 135 resulting resource records will not necessarily belong to or 136 identify the carrier-of-record. 137 2. Queries of infrastructure ENUM fully qualified domain names MUST 138 return a result, even if the result is a Refused (RCODE = 5). 139 Queries must not be rejected without response, e.g., based on 140 access control lists. 141 3. Infrastructure ENUM SHALL support RRs providing a URI that can 142 identify a point of interconnection for delivery to the carrier- 143 of-record of communications addressed to the E.164 number. 144 4. Infrastructure ENUM SHOULD be able to support an IRIS [5] 145 capability that allows qualified parties to obtain information 146 regarding the E.164 numbering resources and the corresponding 147 carrier-of-record. Determination of what information, if any, 148 shall be available to which parties for geographic numbers is a 149 national matter. 150 5. Implementation of Infrastructure ENUM MUST NOT restrict the 151 ability of an end user, in a competitive environment, to choose a 152 Registrar and/or name server provider for End User ENUM 153 registrations. 154 6. The domain name chosen for infrastructure ENUM and any parent 155 domains MUST be hosted on name servers that have performance 156 characteristics and supporting infrastructure which is comparable 157 to those deployed for the Internet root name servers. Those name 158 servers for Infrastructure ENUM should be configured and operated 159 according to the guidelines described in [6]. 160 7. Infrastructure ENUM MUST meet all reasonable privacy concerns 161 about visibility of information over which an end user has no 162 control. It should, for example, support mechanisms to prevent 163 discovery of unlisted numbers by comparison of ENUM registrations 164 against directory listings, or inadvertent disclosure of user 165 identity. 166 8. Proposed implementations of Infrastructure ENUM SHOULD: 167 A. Minimize changes required to existing requirements that are 168 part of RFC 3761 169 B. Work with open as well as closed numbering plans 170 C. Not require additional functionality of resolvers at large 171 though they may require additional functionality in service 172 provider resolvers that would make use of Infrastructure 173 ENUM. 174 D. Minimize the number of lookups required to obtain as many 175 NAPTR (Naming Authority Pointer) records (End User and 176 infrastructure) as possible. 177 E. Minimize knowledge of the numbering plan required of 178 resolvers making use of Infrastrcuture ENUM. 179 F. Maximize synergies with End User ENUM 180 G. Support interworking with private ENUM trees.(In this context 181 a private ENUM tree is one that is not under e164.arpa or 182 whatever namespace is chosen for infrastructure ENUM but uses 183 instead a privately held domain.) 185 4. Security Considerations 187 Existing security considerations for ENUM detailed in [2] still 188 apply. Since Infrastructure ENUM involves carriers where RFC 3761 189 mainly considered indviduals, implementations meeting these 190 requirement SHOULD reconsider the RFC 3761 security model given this 191 difference in actors concerned. Note that some registration 192 validation issues concerning End User ENUM may not apply to 193 infrastructure ENUM. Where the Tier 1 registry is able to identify 194 the provider serving a number e.g., based on industry data for number 195 block assignments and number portability, registration might be more 196 easily automated and a separate registrar not required. 198 Some parties have expressed concern that an infrastructure ENUM could 199 compromise end user privacy by making it possible for others to 200 identify unlisted or unpublished numbers based on their registration 201 in ENUM. This can be avoided if providers register all of the their 202 allocated (as opposed to assigned) numbers. Unassigned numbers 203 should be provisioned to route to the provider's network in the same 204 fashion as assigned numbers and only then provide an indication that 205 they are unassigned. In that way, provider registration of a number 206 in ENUM provides no more information about status of a number than 207 could be obtained by dialing it. 209 Implementers should take care to avoid inadvertant disclosure of user 210 identities, for example in the URIs returned in response to 211 Infrastructure ENUM queries. 213 5. IANA Considerations 215 This document includes no actions to be taken by IANA. The 216 architecture ultimately chosen to meet the requirements may require 217 IANA actions. 219 6. Normative References 221 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 222 Levels", BCP 14, RFC 2119, March 1997. 224 [2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 225 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 226 Application (ENUM)", RFC 3761, April 2004. 228 [3] International Telecommunication Union-Telecommunication 229 Standardization Sector, "The International Public 230 Telecommunication Numbering Plan", Recommendation E.164", 231 February 2005. 233 [4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 234 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 235 January 2005. 237 [5] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information 238 Service (IRIS) Core Protocol", RFC 3981, January 2005. 240 [6] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root Name 241 Server Operational Requirements", BCP 40, RFC 2870, June 2000. 243 Authors' Addresses 245 Steven Lind 246 AT&T Labs 247 180 Park Ave 248 Florham Park, NJ 07932-0971 249 USA 251 Email: sdlind@att.com 253 Penn Pfautz 254 AT&T 255 200 S. Laurel Ave 256 Middletown, NJ 07748 257 USA 259 Email: ppfautz@att.com 261 Full Copyright Statement 263 Copyright (C) The IETF Trust (2007). 265 This document is subject to the rights, licenses and restrictions 266 contained in BCP 78, and except as set forth therein, the authors 267 retain all their rights. 269 This document and the information contained herein are provided on an 270 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 271 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 272 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 273 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 274 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 275 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 277 Intellectual Property 279 The IETF takes no position regarding the validity or scope of any 280 Intellectual Property Rights or other rights that might be claimed to 281 pertain to the implementation or use of the technology described in 282 this document or the extent to which any license under such rights 283 might or might not be available; nor does it represent that it has 284 made any independent effort to identify any such rights. Information 285 on the procedures with respect to rights in RFC documents can be 286 found in BCP 78 and BCP 79. 288 Copies of IPR disclosures made to the IETF Secretariat and any 289 assurances of licenses to be made available, or the result of an 290 attempt made to obtain a general license or permission for the use of 291 such proprietary rights by implementers or users of this 292 specification can be obtained from the IETF on-line IPR repository at 293 http://www.ietf.org/ipr. 295 The IETF invites any interested party to bring to its attention any 296 copyrights, patents or patent applications, or other proprietary 297 rights that may cover technology that may be required to implement 298 this standard. Please address the information to the IETF at 299 ietf-ipr@ietf.org. 301 Acknowledgment 303 Funding for the RFC Editor function is provided by the IETF 304 Administrative Support Activity (IASA).