idnits 2.17.1 draft-newton-peppermint-problem-statement-00.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 244. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 262. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 268. 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 (January 27, 2007) is 6293 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3761 (ref. '3') (Obsoleted by RFC 6116, RFC 6117) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PEPPERMINT A. Newton 3 Internet-Draft SunRocket 4 Intended status: Informational January 27, 2007 5 Expires: July 31, 2007 7 Provisioning Extensions in Peering Registries for Multimedia 8 Interconnection (PEPPERMINT) Problem Statement 9 draft-newton-peppermint-problem-statement-00.txt 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 July 31, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document contains descriptions of the problems faced by 43 operators and participants of multimedia interconnection (i.e. SIP) 44 peering registries with respect to identity provisioning. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Querying the Registry . . . . . . . . . . . . . . . . . . . . 4 50 3. Registry Provisioning . . . . . . . . . . . . . . . . . . . . 5 51 3.1. Provisioning Data . . . . . . . . . . . . . . . . . . . . 5 52 3.2. Provisioning Protocols . . . . . . . . . . . . . . . . . . 5 53 4. Database Co-location . . . . . . . . . . . . . . . . . . . . . 6 54 5. Internationalization Considerations . . . . . . . . . . . . . 7 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 57 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 58 9. Informative References . . . . . . . . . . . . . . . . . . . . 11 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 60 Intellectual Property and Copyright Statements . . . . . . . . . . 13 62 1. Introduction 64 VoIP Service Providers (VSPs) engage in peering relationships with 65 other VSPs to create direct IP-to-IP interconnections. These 66 relationships provide greater technical capabilities and enhanced 67 economic benefit beyond that available with the Public Switched 68 Telephone Network (PSTN), while providing the security benefit 69 perceived to exist in the PSTN. Because the operational management 70 of hundreds and thousands of direct peering relationship is 71 difficult, VSPs enlist the help of peering exchanges to centralize 72 the management of the relationships (this is often known as indirect 73 peering). 75 One of the central functions of these peering exchanges is a registry 76 of identifiers, usually telephone numbers. This function is often 77 called the peering registry. VSPs participating in the peering 78 exchange must provision their identifiers into the peering registry. 79 Once identifiers are provisioned into the registry, other VSPs may 80 query the registry against those identifiers to find the responsible 81 VSP. 83 To gain as much IP-to-IP coverage, many VSPs have relationships with 84 several peering exchanges. However, the management of just a few 85 peering exchange relationships can be made difficult since there is 86 no widely excepted standard for which to provision identifiers into a 87 peering registry. 89 Additionally, some peering registries allow the co-location of their 90 database inside the network of a participating VSP. This is done to 91 lower the latency on the query of the peering registry. Updates to 92 the co-located database are done via another mechanism. Managing 93 multiple co-located registry databases can also be problematic since 94 there is no standard protocol for the update mechanism. 96 The intended scope of work for the Provisioning Extensions in Peering 97 Registries for Multimedia Interconnections (PEPPERMINT) activity is 98 the creation of standard protocols to solve these two problems. 100 2. Querying the Registry 102 The definition of the registry query mechanism is out of scope for 103 the PEPPERMINT activity. However, it is helpful to know what 104 mechanisms are in popular use to understand the necessary properties 105 for a provisioning interface. 107 At present, there are two well known methods used by VSPs to query a 108 peering registry. These are ENUM [3] and SIP [2]. 110 ENUM is simply a method of using DNS. It allows a VSP to query a 111 registry with a telephone number, an E.164 number in most cases, and 112 retrieve a list of URIs, each with a specific preference order. 114 When SIP is used for the query mechanism, it is often refered to as a 115 SIP redirect proxy. This mechanism is normally used by having the 116 peering registry in the signaling path of the VSP. However, it is 117 possible to use SIP redirection outside of a signaling path as a 118 separate query mechanism. The input to this mechansim is a URI with 119 the result being multiple URIs, each with an optional display name 120 and other parameters (i.e. meta-data). 122 3. Registry Provisioning 124 3.1. Provisioning Data 126 The information being provisioned into peering registries by VSPs is 127 an identifier and data about the identifier. This identifier is the 128 key used by other VSPs to retrieve a SIP [2] Address of Record (AoR). 130 In most cases the identifier is a telephone number or a list of URIs 131 containing the same telephone number. And in most cases where a 132 telephone number is the root of an identifier, the telephone number 133 is an E.164 number. 135 3.2. Provisioning Protocols 137 As stated in Section 1, there is no widely accepted standard for 138 provisioning identifiers into a peering registry. 140 However, the EPP/E.164 [4] standard is used by some, but not many, 141 peering registries. Since RFC 4114 is based upon domain name 142 registry provisioning, it is not seen as appropriate for peering 143 registry provisioning, especially when provisioning number prefixes 144 or number blocks. And though a domain name model works well for ENUM 145 [3] based registries, it is unknown how well it would work for SIP 146 [2] based registries. Finally, RFC 4114 lacks adoption because there 147 is little awareness of it in the VSP and peering exchange 148 communities. 150 Some VSPs and peering registries utilize popular XML based 151 technologies such as SOAP. Though RFC 4114 is also an XML based 152 protocol, it is believed that SOAP eliminates the need for VSPs to 153 write client code. 155 Finally, some peering registries are provisioned using files 156 transfered over FTP [1]. While this lacks meaningful transaction 157 semantics, it is easily accomplished by nearly any VSP. 159 4. Database Co-location 161 Some peering registries co-locate their database of identifiers at 162 the premises of the VSPs. The peering registries then provide 163 updates periodically to the co-located database. 165 With the exception of DNS AXFR and IXFR mechanisms, there are no 166 standard protocols employed for this database synchronization. And 167 the use of DNS zone transfer techniques may be adequate for 168 registries with ENUM [3] interfaces, but it is difficult to adapt for 169 registries with SIP [2] redirect interfaces. 171 Because proprietary protocols are often used, VSPs typically dedicate 172 hardware specifically for the database co-location. VSPs with 173 multiple peering exchange relationships must then manage multiple co- 174 located databases, each on separate hardware. 176 VSPs engaged in routing traffic to the Public Switched Telephone 177 Network (PSTN) typically have additional location and routing 178 databases, widely known as Route Management Systems (RMS) or Least 179 Cost Routing Systems (LCRS). When coupled with one or more peering 180 exchanges, VSPs often need to interject the data from a peering 181 registry into these systems. This is very difficult to do when 182 peering registries use proprietary protocols. 184 5. Internationalization Considerations 186 None at present. 188 6. IANA Considerations 190 Not applicable. 192 7. Security Considerations 194 None at present. 196 8. Acknowledgments 198 Many of the points of information in this document are summarizations 199 of objectives and statements made by individuals on the PEPPERMINT 200 mailing list. Information on the PEPPERMINT mailing list can be 201 found at http://www.ietf.org/mailman/listinfo/peppermint. 203 9. Informative References 205 [1] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, 206 RFC 959, October 1985. 208 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 209 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 210 Session Initiation Protocol", RFC 3261, June 2002. 212 [3] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 213 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 214 Application (ENUM)", RFC 3761, April 2004. 216 [4] Hollenbeck, S., "E.164 Number Mapping for the Extensible 217 Provisioning Protocol (EPP)", RFC 4114, June 2005. 219 Author's Address 221 Andrew Newton 222 SunRocket 223 8045 Leesburg Pike, Suite 300 224 Vienna, VA 22182 225 US 227 Phone: +1 703 636 0852 228 Email: andy@hxr.us 230 Full Copyright Statement 232 Copyright (C) The IETF Trust (2007). 234 This document is subject to the rights, licenses and restrictions 235 contained in BCP 78, and except as set forth therein, the authors 236 retain all their rights. 238 This document and the information contained herein are provided on an 239 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 240 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 241 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 242 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 243 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 244 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 246 Intellectual Property 248 The IETF takes no position regarding the validity or scope of any 249 Intellectual Property Rights or other rights that might be claimed to 250 pertain to the implementation or use of the technology described in 251 this document or the extent to which any license under such rights 252 might or might not be available; nor does it represent that it has 253 made any independent effort to identify any such rights. Information 254 on the procedures with respect to rights in RFC documents can be 255 found in BCP 78 and BCP 79. 257 Copies of IPR disclosures made to the IETF Secretariat and any 258 assurances of licenses to be made available, or the result of an 259 attempt made to obtain a general license or permission for the use of 260 such proprietary rights by implementers or users of this 261 specification can be obtained from the IETF on-line IPR repository at 262 http://www.ietf.org/ipr. 264 The IETF invites any interested party to bring to its attention any 265 copyrights, patents or patent applications, or other proprietary 266 rights that may cover technology that may be required to implement 267 this standard. Please address the information to the IETF at 268 ietf-ipr@ietf.org. 270 Acknowledgment 272 Funding for the RFC Editor function is provided by the IETF 273 Administrative Support Activity (IASA).