idnits 2.17.1 draft-ietf-enum-infrastructure-07.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 231. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 241. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 248. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 254. 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 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 (November 13, 2007) is 6008 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) ** 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 draft: draft-ietf-enum-infrastructure-enum-reqs (ref. '4') Summary: 3 errors (**), 0 flaws (~~), 2 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: May 16, 2008 P. Pfautz 5 Intended Status: Proposed Standard AT&T 6 R. Stastny 7 Oefeg 8 November 13, 2007 10 The E.164 to Uniform Resource Identifiers (URI) 11 Dynamic Delegation Discovery System (DDDS) Application for 12 Infrastructure ENUM 13 draft-ietf-enum-infrastructure-07 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 16, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document defines the use case for Infrastructure ENUM and 46 proposes its implementation as a parallel namespace to "e164.arpa" as 47 defined in RFC3761, as the long-term solution to the problem of 48 allowing carriers to provision DNS records for telephone numbers 49 independently of those provisioned by end users (number assignees). 51 Table of Contents 53 1. Terminology....................................................2 54 2. Introduction...................................................2 55 3. Zone Apex for Infrastructure ENUM..............................3 56 4. IANA Considerations............................................3 57 5. Security and Privacy Considerations............................3 58 6. Acknowledgements...............................................4 59 7. References.....................................................4 60 7.1 Normative References.......................................4 61 7.2 Informative References.....................................4 62 Authors' Addresses................................................4 63 Intellectual Property and Copyright Statements....................5 65 1. Terminology 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in BCP 14, RFC-2119 [5]. 71 2. Introduction 73 ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that transforms 74 E.164 numbers [2] into domain names and then uses the DNS (Domain 75 Name Service) [3] to discover NAPTR records that specify what 76 services are available for a specific domain name. 78 ENUM as originally defined was based on the end-user opt-in 79 principle. While this has great potential to foster new services and 80 end-user choice in the long-term, the current requirements for IP- 81 based interconnection of Voice over IP (VoIP) domains require the 82 provisioning of large numbers of allocated or served (hosted) numbers 83 of a participating service provider, without the need for individual 84 users to opt-in or not and so that service providers can provision 85 their own ENUM information that is separate, distinct, and likely to 86 be different from what and end-user may provision. This is 87 particularly important if Infrastructure ENUM is used for number 88 portability applications, for example, which an end-user would be 89 unlikely to be interested in provisioning but which a service 90 provider would likely find essential. 92 In addition, while it is possible that service providers could 93 mandate that their users opt-in into e164.arpa through end-user 94 contract terms and conditions, there are substantial downsides to 95 such an approach. Thus, for all these reasons and many others, ENUM 96 for end-user provisioning is ill-suited for use by service providers 97 for the interconnection of VoIP domains. 99 As VoIP evolves and becomes pervasive, E.164-addressed telephone 100 calls need not necessarily traverse the Public Switched Telephone 101 Network (PSTN). Therefore, VoIP service providers have an interest 102 in using ENUM, on a so-called "Infrastructure" basis, to keep VoIP 103 traffic on IP networks on an end-to-end basis, both within and 104 between service provider domains. This requires of means of 105 identifying a VoIP point of interconnection to which calls addressed 106 to a given E.164 number may be delivered and Infrastructure ENUM 107 provides this means. Calls that can originate and terminate on IP 108 networks, and do not have to traverse the PSTN, will require fewer or 109 no points of transcoding, and can also involve additional IP network 110 services that are not possible on the PSTN, among other benefits. 112 Requirements for Infrastructure ENUM are provided in[4]. 114 3. Zone Apex for Infrastructure ENUM 116 This document proposes that Infrastructure ENUM be implemented by 117 means of a parallel namespace to e164.arpa dedicated to 118 Infrastructure ENUM, in a domain which is to be determined. Use of a 119 parallel namespace allows carriers and end users to control their 120 ENUM registrations for a number independently without forcing one to 121 work through the other. 123 Infrastructure ENUM Tier 2 resource records in the Infrastructure 124 ENUM tree would be controlled by the service provider that is 125 providing services to a given E.164 number, generally referred to in 126 various nations as the "carrier of record" (see [4]). The definition 127 of a carrier of record for a given E.164 number is a national matter 128 or is defined by the entity controlling the numbering space. 130 See also Section 3, Requirements, in [4]. 132 4. IANA Considerations 134 This document contains no requested IANA actions. 136 IANA has created a registry for Enumservices as originally specified 137 in RFC 2916 and revised in RFC 3761. Enumservices registered with 138 IANA are valid for Infrastructure ENUM as well as end-user ENUM. 140 5. Security and Privacy Considerations 141 This document proposes a new zone apex for ENUM to meet the 142 requirements of Infrastructure ENUM. The over-the-network protocol 143 of ENUM is unchanged by the addition of an apex, and as such, the 144 Security considerations of RFC3761 [1] still apply. Specific 145 considerations related to the security of an Infrastructure ENUM apex 146 are given in more detail in Section 4, Security Considerations, in 147 [4]. 149 Infrastructure ENUM registrations proposed by this draft 150 should resolve to service provider points of interconnection rather 151 than end user equipment. Service providers need to take appropriate 152 measures to protect their end user customers from unwanted 153 communications as with other types of interconnections. 155 6. Acknowledgements 157 The authors wish to thank Lawrence Conroy, Patrik Faltstrom, Michael 158 Haberler, Otmar Lendl, Steve Lind, Alexander Mayrhofer, Jim Reid, and 159 Richard Shockey for their helpful discussion of this draft and the 160 concept of Infrastructure ENUM. 162 7. References 164 7.1 Normative References 166 [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 167 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 168 Application (ENUM)", RFC 3761, April 2004. 170 [2] ITU-T, "The International Public Telecommunication Number Plan", 171 Recommendation E.164, February 2005. 173 [3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 174 1034, November 1987. 176 [4] Lind, S., Pfautz, P., "Infrastructure ENUM Requirements", draft- 177 ietf-enum-infrastructure-enum-reqs-04, May 2007. 179 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 180 Levels", RFC 2119, March 1997. 182 7.2 Informative References 184 None 186 Authors' Addresses 188 Jason Livingood 189 Comcast Cable Communications 190 1500 Market Street 191 Philadelphia, PA 19102 192 USA 194 Phone: +1-215-981-7813 195 Email: jason_livingood@cable.comcast.com 197 Penn Pfautz 198 AT&T 199 200 S. Laurel Ave 200 Middletown, NJ 07748 201 USA 203 Phone: +1-732-420-4962 204 Email: ppfautz@att.com 206 Richard Stastny 207 Oefeg 208 Postbox 147 209 1103 Vienna 210 Austria 212 Phone: +43-664-420-4100 213 Email: Richard.stastny@oefeg.at 215 Intellectual Property and Copyright Statements 217 Full Copyright Statement 219 Copyright (C) The IETF Trust (2007). 221 This document is subject to the rights, licenses and restrictions 222 contained in BCP 78, and except as set forth therein, the authors 223 retain all their rights. 225 This document and the information contained herein are provided on an 226 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 227 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 228 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 229 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 230 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 231 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 233 Intellectual Property 234 The IETF takes no position regarding the validity or scope of any 235 Intellectual Property Rights or other rights that might be claimed to 236 pertain to the implementation or use of the technology described in 237 this document or the extent to which any license under such rights 238 might or might not be available; nor does it represent that it has 239 made any independent effort to identify any such rights. Information 240 on the procedures with respect to rights in RFC documents can be 241 found in BCP 78 and BCP 79. 243 Copies of IPR disclosures made to the IETF Secretariat and any 244 assurances of licenses to be made available, or the result of an 245 attempt made to obtain a general license or permission for the use of 246 such proprietary rights by implementers or users of this 247 specification can be obtained from the IETF on-line IPR repository at 248 http://www.ietf.org/ipr. 250 The IETF invites any interested party to bring to its attention any 251 copyrights, patents or patent applications, or other proprietary 252 rights that may cover technology that may be required to implement 253 this standard. Please address the information to the IETF at ietf- 254 ipr@ietf.org. 256 Acknowledgment 258 Funding for the RFC Editor function is currently provided by the IETF 259 Administrative Support Activity (IASA).