idnits 2.17.1 draft-lind-infrastructure-enum-reqs-01.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 on line 241. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 218. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 225. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 231. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 18, 2005) is 6765 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. '2') (Obsoleted by RFC 6116, RFC 6117) -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 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 Expires: April 22, 2006 P. Pfautz 5 AT&T 6 October 18, 2005 8 Carrier/Infrastrucure ENUM Requirements 9 draft-lind-infrastructure-enum-reqs-01 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 April 22, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document provides requirements for "infrastructure" or "carrier" 43 ENUM, defined as the use of RFC 3761 technology to facilitate 44 interconnection of networks for E.164 number addressed services, in 45 particular but not restricted to VoIP. 47 Conventions used in this document 49 RFC2119 [1] provides the interpretations for the key words "MUST", 50 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 51 "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. 53 1. Infrastructure ENUM 55 1.1. Definition 57 Infrastructure ENUM is defined as the use of the technology in 58 RFC3761 [2] by the carrier-of-record for a specific E.164 number [3] 59 to map a telephone number into a URI that identifies a specific point 60 of interconnection to that service provider's network that could 61 enable the originating party to establish communication with the 62 associated terminating party. It is separate from any URIs that the 63 end-user, who registers their E.164 number, may wish to associate 64 with that E.164 number. 66 For purposes of this document, "Carrier of Record" refers to the 67 entity that provides PSTN service for an E.164 number with the 68 understanding that this definition is ultimately a matter for 69 national authorities to determine. 71 1.2. Background 73 Carriers use E.164 numbers currently as their main naming and routing 74 vehicle. Carrier ENUM in e164.arpa or another publicly available 75 tree allows Carriers to link Internet based resources such as URIs to 76 E.164 numbers (Note: this is the other way round then User ENUM). 77 This allows Carrier in addition to interconnecting via the PSTN (or 78 exclusively) to peer via IP-based protocols. Carriers may announce 79 all E.164 numbers or number ranges they host, regardless if the final 80 end-user device is on the Internet, on IP-based closed NGNs or on the 81 PSTN, provided an access (e.g. SBC or gateway) to the destination 82 carriers network is available on the Internet. There is also no 83 guarantee that the originating carrier querying Carrier ENUM is able 84 to access the ingress network element of the destination carriers 85 network. Additional peering and accounting agreements requiring 86 authentication may be necessary. The access provided may also be to 87 a shared network of a group of carriers, resolving the final 88 destination network within the shared network. 90 2. Requirements for Infrastructure ENUM 91 2.1. 93 Infrastructure ENUM SHALL provide a means for a carrier to populate 94 DNS RRs in a common publicly accessible namespace for the E.164 95 numbering resources for which it is the carrier-of-record. 97 2.2. 99 Queries of infrastructure ENUM FQDNs MUST return a result, even if 100 the result is NXDOMAIN. Queries must not be rejected, e.g. based on 101 ACLs. 103 2.3. 105 Infrastructure ENUM SHALL support RRs providing a URI that can 106 identify a point of interconnection for delivery of communications 107 addressed to the E.164 number. 109 2.4. 111 Infrastructure ENUM SHALL support an IRIS capability that allows 112 qualified parties to obtain information regarding the E.164 numbering 113 resources and the corresponding carrier-of-record. 115 2.5. 117 Implementation of Infrastructure ENUM MUST NOT restrict the ability 118 of an end-user, in a competitive environment, to choose a Registrar 119 and/or Tier 2 name server provider for end-user ENUM registrations. 121 2.6. 123 Infrastructure ENUM SHALL be implemented under a TLD that can support 124 reliability and performance suitable for PSTN applications. 126 2.7. 128 Infrastructure ENUM MUST meet all reasonable privacy concerns about 129 visibility of information an end user has no control over, for 130 example discovery of unlisted numbers, or inadvertent disclosure of 131 user identity. 133 2.8. 135 Proposed implementations of Infrastructure ENUM SHOULD 137 a. Minimize changes required to existing requirements that are part 138 of RFC 3761 139 b. Work with open numbering plans 141 c. Restrict additional functionality to carrier resolvers. 143 d. Minimize the number of lookups required to obtain as many NAPTR 144 records (end-user and carrier) as possible. 146 e. Minimize the client knowledge of the numbering plan required. 148 f. Maximize synergies with end-user ENUM 150 g. Support interworking with private ENUM trees. 152 3. Security Considerations 154 Existing security considerations for ENUM detailed in [2] still 155 apply. Note that some registration validation issues concerning end 156 user ENUM may not apply to carrier ENUM. Where the Tier 1 registry 157 is able to identify the carrier serving a number e.g., based on 158 industry data for number block assignments and number portability, 159 registration might be more easily automated and a separate registrar 160 not required. 162 Some parties have expressed concern that a carrier ENUM could 163 compromise end user privacy by making it possible for others to 164 identify unlisted or unpublished numbers based on their registration 165 in ENUM. This can be avoided if carriers register all of the their 166 allocated (as opposed to assigned) numbers. Unassigned numbers 167 should be provisioned to route to the carrier's network in the same 168 fashion as assigned numbers and only then provide an indication that 169 they are unassigned. In that way, carrier registration of a number 170 in ENUM provides no more information about status of a number than 171 could be obtained by dialing it. 173 4. IANA Considerations 175 IANA considerations will depend on the architecture ultimately chosen 176 to meet the requirements. 178 5. Normative References 180 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 181 Levels", BCP 14, RFC 2119, March 1997. 183 [2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 184 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 185 Application (ENUM)", RFC 3761, April 2004. 187 [3] International Telecommunications Union-T, "The International 188 Public Telecommunication Number Plan", Recommendation E.164", 189 May 1997. 191 Authors' Addresses 193 Steven Lind 194 AT&T Labs 195 180 Park Ave 196 Florham Park, NJ 07932-0971 197 USA 199 Email: slind@att.com 201 Penn Pfautz 202 AT&T 203 200 S. Laurel Ave 204 Middletown, NJ 07748 205 USA 207 Email: ppfautz@att.com 209 Intellectual Property Statement 211 The IETF takes no position regarding the validity or scope of any 212 Intellectual Property Rights or other rights that might be claimed to 213 pertain to the implementation or use of the technology described in 214 this document or the extent to which any license under such rights 215 might or might not be available; nor does it represent that it has 216 made any independent effort to identify any such rights. Information 217 on the procedures with respect to rights in RFC documents can be 218 found in BCP 78 and BCP 79. 220 Copies of IPR disclosures made to the IETF Secretariat and any 221 assurances of licenses to be made available, or the result of an 222 attempt made to obtain a general license or permission for the use of 223 such proprietary rights by implementers or users of this 224 specification can be obtained from the IETF on-line IPR repository at 225 http://www.ietf.org/ipr. 227 The IETF invites any interested party to bring to its attention any 228 copyrights, patents or patent applications, or other proprietary 229 rights that may cover technology that may be required to implement 230 this standard. Please address the information to the IETF at 231 ietf-ipr@ietf.org. 233 Disclaimer of Validity 235 This document and the information contained herein are provided on an 236 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 237 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 238 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 239 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 240 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 241 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 243 Copyright Statement 245 Copyright (C) The Internet Society (2005). This document is subject 246 to the rights, licenses and restrictions contained in BCP 78, and 247 except as set forth therein, the authors retain all their rights. 249 Acknowledgment 251 Funding for the RFC Editor function is currently provided by the 252 Internet Society.