idnits 2.17.1 draft-livingood-shockey-enum-npd-00.txt: -(44): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(45): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(179): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(190): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(235): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 341. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 7 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (July 2005) is 6857 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) == Unused Reference: '11' is defined on line 285, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3761 (ref. '1') (Obsoleted by RFC 6116, RFC 6117) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 3401 (ref. '5') == Outdated reference: A later version (-11) exists of draft-ietf-iptel-tel-np-06 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM Working Group J. Livingood 3 Internet-Draft Comcast Cable Communications 4 Expires: January 8, 2006 R. Shockey 5 NeuStar 6 July 2005 8 IANA Registration for an Enumservice 9 Containing Number Portability and PSTN Signaling Information 10 draft-livingood-shockey-enum-npd-00 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she becomes aware will be disclosed, in accordance with 19 Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 8, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document registers the Enumservice �npd� and subtype �tel� using 45 the URI scheme �tel:� as per the IANA registration process defined in 46 the ENUM specification, RFC 3761. This data is used to facilitate 47 the routing of telephone calls in those countries where Number 48 Portability exists. 50 Table of Contents 52 1. Terminology....................................................2 53 2. Introduction...................................................2 54 3. ENUM Service Registration for NPD..............................3 55 4. Examples.......................................................4 56 4.1 Example of a Ported Telephone Number.......................4 57 4.2 Example of a Non-Ported Telephone Number...................4 58 5. Security Considerations........................................5 59 6. IANA Considerations............................................5 60 7. Acknowledgements...............................................5 61 8. References.....................................................6 62 8.1 Normative References.......................................6 63 8.2 Informative References.....................................6 64 Authors� Addresses................................................7 65 Intellectual Property and Copyright Statements....................7 67 1. Terminology 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in BCP 14, RFC-2119 [1]. 73 2. Introduction 75 ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that transforms 76 E.164 numbers (The International Public Telecommunication Number 77 Plan, ITU-T Recommendation E.164 [2]) into domain names and then uses 78 DNS (Domain Name Service, RFC 1034 [3]) delegation through NS records 79 and NAPTR records (Dynamic Delegation Discovery System (DDDS) Part 80 Three: The Domain Name System (DNS) Database, RFC 3403 [4]) to look 81 up what services are available for a specific domain name. 83 This document registers Enumservices according to the guidelines 84 given in RFC 3761 [1] to be used for provisioning in the services 85 field of a NAPTR [4] resource record to indicate the type of 86 functionality associated with an end point and/or telephone number. 87 The registration is defined within the DDDS (Dynamic Delegation 88 Discovery System [4][5][6][7][8]) hierarchy, for use with the "E2U" 89 DDDS Application defined in RFC 3761. 91 Number portability (NP) allows telephone subscribers to keep their 92 telephone numbers when they change service provider, move to a new 93 location, or change the subscribed services [14]. In many counties, 94 such as the United States and Canada, the functions of naming and 95 addressing on the PSTN have been abstracted. The dialed directory 96 number is not routable on the PSTN and must be translated into a 97 routing number for call completion. 99 The following Enumservice is registered with this document: "npd" to 100 indicate number portability data. The purpose of this Enumservice is 101 to describe information about telephone numbers which cannot be used 102 on the public Internet or a private/peered Internet Protocol (IP) 103 network. Thus, these are numbers which are only reachable via the 104 traditional Public Switched Telephone Network (PSTN). 106 This Enumservice could enable carriers, as well as other service 107 providers and users, to place ported, pooled, and blocks of numbers 108 and their associated PSTN contact information, into ENUM databases, 109 using standardized, non-proprietary methods. This, in turn, could 110 enable such parties to consolidate all telephone number lookups in 111 their networks into a single ENUM lookup, thereby simplifying call 112 routing and network operations, which would then result in either an 113 on-net, or IP-based response, or off-net, or PSTN-based response. It 114 is conceivable that being able to query for this information in ENUM 115 could significantly reduce or eliminate the need for these parties to 116 maintain traditional, SS7/TCAP/SIGTRAN-based query gateways, 117 applications, and protocols in their networks. 119 The service parameters defined in RFC 3761 dictate that a "type" and 120 a "subtype" should be specified. Within this set of specifications 121 the convention is assumed that the "type" (being the more generic 122 term) defines the service and the "subtype" defines the URI scheme. 124 When only one URI scheme is associated with a given service, it 125 should be assumed that an additional URI scheme to be used with this 126 service may be added at a later time. Thus, the subtype is needed to 127 identify the specific Enumservice intended. 129 In this document, there is one URI scheme specified, 'tel:', as 130 specified in RFC 3966 [9], and as further specified with number 131 portability data in draft-ietf-iptel-tel-np-06.txt [10] (Internet- 132 Draft New Parameters for the "tel" URI to Support Number Portability, 133 draft-ietf-iptel-tel-np-06.txt [10]). 135 3. ENUM Service Registration for NPD 137 Enumservice Name: "npd" 139 Enumservice Type: "npd" 141 Enumservice Subtype: "tel" 143 URI Scheme: 'tel:' 144 Functional Specification: 146 This Enumservice indicates that the remote resource identified can be 147 addressed by the associated URI scheme in order to initiate a 148 telecommunication session, which may include two-way voice or other 149 communications, to the PSTN. 151 Security Considerations: See Section 5. 153 Intended Usage: COMMON 155 Authors: 157 Jason Livingood and Richard Shockey (for author contact detail see 158 Authors' Addresses section) 160 Any other information the author deems interesting: 162 None 164 4. Examples 166 The following sub-sections document several examples for illustrative 167 purposes. These examples shall in no way limit the various forms 168 that this Enumservice may take. 170 4.1 Example of a Ported Telephone Number 172 $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.e164.arpa. 173 NAPTR 10 100 "u" "E2U+npd:tel" 174 "!^.*$!tel:+1-215-981-7813;rn=+1-215-981-7600;npdi!" 176 In this example, a Routing Number (rn) and a Number Portability Dip 177 Indicator (npdi) are used as shown in draft-ietf-iptel-tel-np-06.txt 178 [10] (Internet-Draft New Parameters for the "tel" URI to Support 179 Number Portability, draft-ietf-iptel-tel-np-06.txt [10]). The �npdi� 180 field is included in order to prevent subsequent lookups in legacy- 181 style PSTN databases. 183 4.2 Example of a Non-Ported Telephone Number 185 $ORIGIN 3.1.8.7.1.8.9.5.1.2.1.e164.arpa. 186 NAPTR 10 100 "u" "E2U+npd:tel" 187 "!^.*$!tel:+1-215-981-7813;npdi!" 189 In this example, a Number Portability Dip Indicator (npdi) is used 190 [10]. The �npdi� field is included in order to prevent subsequent 191 lookups in legacy-style PSTN databases. 193 5. Security Considerations 195 DNS, as used by ENUM, is a global, distributed database. Thus any 196 information stored there is visible to anyone anonymously. While 197 this is not qualitatively different from publication in a Telephone 198 Directory, it does open or ease access to such data without any 199 indication that such data has been accessed or by whom it has been 200 accessed. 202 Such data harvesting by third parties is often used to generate lists 203 of targets for unsolicited information. Thus, a third party could 204 use this to generate a list that they can use to make unsolicited 205 "telemarketing" phone calls. Many countries have do-not-call 206 registries or other legal or regulatory mechanisms in place to deal 207 with such abuses. 209 Carriers, service providers, and other users may simply choose not to 210 publish such information in the public E164.ARPA tree, but may 211 instead simply publish this in their internal ENUM routing database 212 which is only able to be queried by trusted elements of their 213 network, such as softswitches and SIP proxy servers. 215 Although an E.164 telephone number does not appear to reveal as much 216 identity information about a user as a name in the format 217 username@hostname (e.g., an email or SIP address), the information is 218 still publicly available, thus there is still the risk of unwanted 219 communication. 221 An analysis of threats specific to the dependence of ENUM on the DNS 222 and the applicability of DNSSEC [12] to this is provided in RFC 3761 223 [1]. A thorough analysis of threats to the DNS itself is covered in 224 RFC 3833 [13]. 226 DNS does not make any policy decisions about the records that it 227 shares with an inquirer. All DNS records must be assumed to be 228 available to all inquirers at all times. The information provided 229 within an ENUM NAPTR resource record must therefore be considered to 230 be open to the public, unless otherwise secured through split-DNS or 231 some other method, which is a cause for some privacy considerations. 233 6. IANA Considerations 235 This document registers the 'npd' Enumservice and the subtype �tel� 236 under the Enumservice registry described in the IANA considerations 237 in RFC 3761. Details of this registration are provided in sections 3 238 and 4 of this document. 240 7. Acknowledgements 241 The authors wish to thank Tom Creighton, Jason Gaedtke, Jaime 242 Jimenez, and Chris Kennedy from Comcast Cable, Jonathan Rosenberg 243 from Cisco, and James Yu from NeuStar, for their helpful discussion 244 on this topic. 246 8. References 248 8.1 Normative References 250 [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 251 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 252 Application (ENUM)", RFC 3761, April 2004. 254 [2] ITU-T, "The International Public Telecommunication Number Plan", 255 Recommendation E.164, May 1997. 257 [3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 258 1034, November 1987. 260 [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 261 Three: The Domain Name System (DNS) Database", RFC 3403, October 262 2002. 264 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 265 One: The Comprehensive DDDS", RFC 3401, October 2002. 267 [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 268 Two: The Algorithm", RFC 3402, October 2002. 270 [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 271 Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 272 2002. 274 [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 275 Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002. 277 [9] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 278 December 2004. 280 [10] Yu, J., "New Parameters for the "tel" URI to Support Number 281 Portability", draft-ietf-iptel-tel-np-06.txt, June 2005. 283 8.2 Informative References 285 [11] Bradner, et al., "IANA Registration for Enumservices email, fax, 286 mms, ems and sms", draft-ietf-enum-msg-05.txt, May 2005. 288 [12] Arends, R. and et al., "Protocol Modifications for the DNS 289 Security Extensions", RFC 4035, March 2005. 291 [13] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name 292 System (DNS)", RFC 3833, August 2004. 294 [14] M. Foster, T. McGarry and J. Yu, "Number Portability in the 295 GSTN: An Overview", RFC 3482, February 2003. 297 Authors� Addresses 299 Jason Livingood 300 Comcast Cable Communications 301 1500 Market Street 302 Philadelphia, PA 19102 303 USA 305 Phone: +1-215-981-7813 306 Email: jason_livingood@cable.comcast.com 308 Richard Shockey 309 NeuStar 310 46000 Center Oak Plaza 311 Sterling, VA 20166 312 USA 314 Phone: +1-571-434-5651 315 Email: richard.shockey@neustar.biz 317 Intellectual Property and Copyright Statements 319 Intellectual Property Statement 321 The IETF takes no position regarding the validity or scope of any 322 Intellectual Property Rights or other rights that might be claimed to 323 pertain to the implementation or use of the technology described in 324 this document or the extent to which any license under such rights 325 might or might not be available; nor does it represent that it has 326 made any independent effort to identify any such rights. Information 327 on the procedures with respect to rights in RFC documents can be 328 found in BCP 78 and BCP 79. 330 Copies of IPR disclosures made to the IETF Secretariat and any 331 assurances of licenses to be made available, or the result of an 332 attempt made to obtain a general license or permission for the use of 333 such proprietary rights by implementers or users of this 334 specification can be obtained from the IETF on-line IPR repository at 335 http://www.ietf.org/ipr. 337 The IETF invites any interested party to bring to its attention any 338 copyrights, patents or patent applications, or other proprietary 339 rights that may cover technology that may be required to implement 340 this standard. Please address the information to the IETF at 341 ietf-ipr@ietf.org. 343 Disclaimer of Validity 345 This document and the information contained herein are provided on an 346 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 347 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 348 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 349 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 350 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 351 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 353 Copyright Statement 355 Copyright (C) The Internet Society (2005). This document is subject 356 to the rights, licenses and restrictions contained in BCP 78, and 357 except as set forth therein, the authors retain all their rights. 359 Acknowledgment 361 Funding for the RFC Editor function is currently provided by the 362 Internet Society.