idnits 2.17.1 draft-ietf-drinks-cons-rqts-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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 495. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 519. 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 (July 7, 2008) is 5769 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) -- Looks like a reference, but probably isn't: '3' on line 232 -- Obsolete informational reference (is this intentional?): RFC 3730 (Obsoleted by RFC 4930) -- Obsolete informational reference (is this intentional?): RFC 3761 (Obsoleted by RFC 6116, RFC 6117) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) == Outdated reference: A later version (-17) exists of draft-ietf-speermint-terminology-15 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Schwartz 3 Internet-Draft XConnect Global Networks 4 Intended status: Standards Track R. Mahy 5 Expires: January 7, 2009 Plantronics 6 A. Duric 7 Telio 8 E. Lewis 9 NeuStar 10 July 7, 2008 12 Consolidated Provisioning Problem Statement 13 draft-ietf-drinks-cons-rqts-00.txt 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. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 7, 2009. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document describes the type of data provisioned among Voice 47 Service Providers and underscores the need for clearly defined 48 structures and interfaces to facilitate this provisioning. This work 49 is in support of the service provider peering as defined by the 50 SPEERMINT WG. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Registry Data . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Index/Key Data . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Resolution Data . . . . . . . . . . . . . . . . . . . . . 5 59 4. Reachability vs. Routing . . . . . . . . . . . . . . . . . . . 6 60 5. Operations on the Registry Data . . . . . . . . . . . . . . . 6 61 6. Other Atrributes . . . . . . . . . . . . . . . . . . . . . . . 7 62 7. Data Encoding . . . . . . . . . . . . . . . . . . . . . . . . 7 63 8. Data Management . . . . . . . . . . . . . . . . . . . . . . . 7 64 9. Data Propegation . . . . . . . . . . . . . . . . . . . . . . . 8 65 10. Querying The Registry . . . . . . . . . . . . . . . . . . . . 8 66 11. Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 12. Existing Technologies . . . . . . . . . . . . . . . . . . . . 8 68 13. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 71 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 16.1. Normative References . . . . . . . . . . . . . . . . . . . 10 73 16.2. Informational References . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 75 Intellectual Property and Copyright Statements . . . . . . . . . . 12 77 1. Introduction 79 VoIP Service Providers (VSPs) engage in peering relationships with 80 other VSPs to create direct IP-to-IP interconnections. These 81 relationships provide network reach, greater technical capabilities 82 and enhanced economic benefit beyond that available with the Public 83 Switched Telephone Network (PSTN), while providing the security 84 benefit perceived to exist in the PSTN. 86 Because the business and operational management of hundreds or 87 thousands of direct peering relationships is difficult, VSPs often 88 enlist the help of peering exchanges to centralize (or assist 89 [I-D.ietf-speermint-terminology] with) the management of the 90 relationships. One of the central functions of these peering 91 exchanges is a registry of identifiers (often implemented as a 92 private ENUM tree) based on telephone numbers. This function is 93 called the peering or numbering registry. VSPs participating in the 94 peering exchange must provision their identifiers into the peering 95 registry to allow other VSPs with access to this registry to query 96 and obtain the correct resolution for a given number. Lack of clear 97 standards for this provisioning step has given rise to many 98 proprietary approaches that are rendering open provisioning 99 cumbersome and error prone. 101 VSP peering is not the only driver for this work, however. It is 102 quite common today for one VSP to receive number resolution data from 103 both authoritative or regulatory sources (e.g. a national telephone 104 number plan administrator) and commercial or private sources. Since 105 eventually all of the information resides locally, the VSP is 106 interested in merging resolution data across potentially different 107 local platforms so as to avoid multiple queries for each call. Today 108 this is virtually impossible to do in an efficient and standard 109 manner due to the proprietary nature of the individual registry 110 components. 112 In addition, many registry network architectures dictate sub 113 registries for overall resilience and performance. The transfer of 114 resolution data to the sub registries is not yet standardized and 115 results in unnecessary hardware/software component lock in. 117 This document attempts to describe the most common data that needs to 118 be exchanged in the cases highlighted above with the ultimate goal 119 being that of identifying the data structures and interfaces required 120 to support the data exchange scenarios specified above. 122 As a final note it is important to stress that while ENUM is not 123 mentioned explicitly in this document so as not to bias the outcome, 124 it is clear that in the minimum all the information present in a 125 NAPTR RR must be captured as the information therein has been well 126 thought out and deviating from this may curtail future growth. 127 Additionally, while E.164 numbering is not mentioned either for the 128 same reason, it is clear that in almost all cases the prefixes that 129 are being exchanged are in the e.164 format. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 Terms used or referred to elsewhere in the document (including in the 138 introduction): 140 DNS - Domain Name System [RFC1034] 142 RR - Resource Record [RFC1034] 144 TXT - DNS Text record [RFC1035] 146 NAPTR - Naming Authority Pointer record [RFC3403] 148 EPP - Extensible Provisioning Protocol [RFC3730] 150 ENUM - E.164 to URI DDDS [RFC3761] 152 URI - Uniform Resource Identifiers [RFC3986] 154 TLS - Transaction Layer Security [RFC4366] 156 3. Registry Data 158 Registry Data consists of both Index or Key data and Resolution data. 160 3.1. Index/Key Data 162 The organization of registry data is based on specific phone numbers 163 or phone number prefixes (which could represent blocks of phone 164 numbers, regions, or theoretically whole countries). For generality, 165 we will use the term prefix to include complete phone numbers as 166 well. Prefixes are the index or key used for all registry 167 manipulation and lookups. Even though some of the numbers 168 represented within these prefixes may not be globally reachable, the 169 prefix itself needs to be globally normalized before it can be 170 entered into a registry. These globally normalized prefixes always 171 begin with a plus (+) and a telephone country code. (Note that 172 prefixes in some countries can contain hexadecimal digits). 174 Since prefixes have variable lengths, a provisioning protocol must be 175 able to enter data for a sub-prefix or super-prefix of an existing 176 record. For example, it must be possible to enter records about 177 "+1202555" and "+12025551234" at the same time. For lookups 178 information about the most specific prefix will be returned. This 179 allows for some measure of aggregation. Also, in order to provide 180 maximal flexibility a provisioning protocol must provide a mechanism 181 for specifying both minimum and maximum number of digits in a prefix. 183 3.2. Resolution Data 185 For each prefix, there is a variety of data that can be exchanged. 186 The most important set of data identifies that a specific VSP is 187 responsible for the prefix and in most cases the VSP provides a SIP 188 URI through which this prefix can be reached. 190 In complex cases, several VSPs may claim some form of responsibility 191 for the same prefix. We can use the term "last hop" VSP to describe 192 the VSP closest to the end-user of a phone number. The provider who 193 was assigned a prefix by the national numbering authority is the 194 "first hop" VSP. The first hop VSP may have no way of knowing if the 195 last hop VSP will include itself in the registry. Therefore it is 196 important that the querier can obtain both records and use the most 197 specific one which contains reachability information. 199 In many cases, commercial registries also contain information used 200 for Local Number Portability. Even if a prefix is not reachable for 201 IP peering, it is useful to provide the "dipped" number and carrier 202 code. This information could be provided as a tel URI with the 203 number portability attributes defined in RFC 4769 [RFC4769]. 204 Likewise it is very useful to know that a prefix is known not to 205 exist anywhere. 207 Like stated in the introduction it is imperative that the minimal set 208 of resolution data contain all the information required for a DNS 209 NAPTR RR. 211 Additionally, as a future proofing mechanism it is recommended that 212 resolution data include a catchall (similar to a DNS TXT RR) for data 213 that is not currently present in any ENUM service definitions. 215 One final note. One of the common "rewrite" rules for the URI in 216 NAPTR RRs for example is of the form "\1@somehost.company.example" 217 where the "\1" refers to the telephone number being processed. This 218 kind of shorthand should be available when processing prefixes in 219 bulk. 221 4. Reachability vs. Routing 223 The goal of the registry is to provide sufficient information to 224 identify a responsible VSP for a prefix. The responsible VSP can 225 provide a SIP URI that can be proxied or redirected as desired by the 226 VSP. It is important to note that the registry is expected to return 227 the same responsibility data for all parties that query it. 229 Routing information is also out of scope of the registry provisioning 230 problem. Once a responsible VSP is contacted, that VSP can use a 231 variety of techniques to route that request. For example, the VSP 232 could use TRIP [3], a private database, or a SIP location server. 233 Since this information is highly dynamic, it is inappropriate to 234 provision in a registry. 236 5. Operations on the Registry Data 238 WBelow is a list of logical operations on the registry data. Please 239 note that as stated above a provisioning protocol MUST apply these 240 operations equally to individual prefixes as well as prefix blocks. 242 Add: Add (responsible VSP) data about a new prefix to the registry. 244 Delete: Remove a prefix from the registry. Semantically it means 245 that the prefix no longer exists anywhere. 247 Port-out: A port-out is similar to a delete, but could be logged 248 differently. The semantics are that the prefix still exists, but 249 that the previous VSP is no longer responsible for it. 251 Port-In: A port-in is similar to an add, but the semantics are that 252 the prefix was previously assigned to a different provider. 254 Transfer: A transfer is a port-out and port-in operation performed 255 atomically. This operation insures that lookups do not fail for the 256 transferred prefix during the transfer. 258 Renumber: A renumber operation occurs when a specific prefix is 259 completely changed, but the data corresponding to the prefix has not 260 changed. This typically happens when a prefix is lengthened. For 261 example, when France moved from an 8-digit to a 10-digit dial plan, 262 the corresponding globally normalized prefix for a Parisian phone 263 number had a 1 inserted between the country code and the old prefix. 264 Renumbering could also accomplish prefix shortening (although this is 265 quite unlikely to occur) or prefix splitting (in the past United 266 States area codes where split when they were exhausted). 268 Modify: A modify operation occurs when some other attribute of a 269 prefix is modified (for example the target URI used for 270 reachability). 272 6. Other Atrributes 274 All the registry records will need to include some kind of validity 275 information. The provisioning protocol can indicate that a record is 276 not valid before one date and time and no longer valid after another 277 date and time. 279 In addition to responsibility data, we have identified the following 280 extra attributes as important or interesting: 282 Regardless of which protocol is used, issues that should be addressed 283 include 285 Number type (unknown, IP, PSTN, both) 287 PSTN carrier code (for numbers with no IP reachability) 289 Fee category (free, landline, mobile, pay) 291 Media types supported (voice, video, message) 293 There MUST be a mechanism for an audit trail as issues of ownership 294 are bound to surface and a clearly defined mechanism for tracking 295 changes to registry data is essential. 297 7. Data Encoding 299 Since data may need to traverse administrative domain boundaries some 300 thought needs to be given to the rendering of the messages in 301 transmission. The encoding mechanism MUST be robust and easy to 302 design and troubleshoot with a strong bias towards an existing and 303 widely recognized standard. 305 8. Data Management 307 Due to the entrenchment of legacy software development processes 308 (e.g. SOAP/XML, WSDL, TLS) it is of utmost importance that whatever 309 emerges from this WG should be easy to implement with existing 310 methodologies. 312 9. Data Propegation 314 The transport layer is strictly point-to-point, with no caching or 315 forwarding. 317 10. Querying The Registry 319 The definition of the registry query mechanism is out of scope for 320 the PEPPERMINT activity. However, it is helpful to know what 321 mechanisms are in popular use to understand the necessary properties 322 for a provisioning interface. At present, there are two well-known 323 methods used by VSPs to query a peering registry. These are ENUM 324 [RFC3761] and SIP [RFC3261]. 326 ENUM is simply a method of using DNS. It allows a VSP to query a 327 registry with a telephone number, an E.164 number in most cases, and 328 retrieve a list of URIs, each with a specific preference order. 330 When SIP is used for the query mechanism, the numbering registry 331 functions as a SIP redirect proxy [RFC3261] . The input to this 332 mechanism is a URI or more importantly the UserInfo part of the URI 333 containing the number to be queried. The response returned by the 334 proxy is either an error code indicating the absence of information 335 about the number queried or a redirect response (3XX) containing 1 336 (or more) Contact Headers representing available routing options. 338 11. Control 340 Since it may be possible to both push and pull data it is imperative 341 that a throttling mechanism exist to control the flow of data 342 exchange at all levels. 344 12. Existing Technologies 346 there has been some consideration to EPP extensions for ENUM 347 [RFC4114], and why it has not been adopted and why a requirements 348 document is now being produced to cover what would seemingly be 349 addressed by that solution. 351 There are two reasons for EPP not being adopted. One is that it 352 isn't compatible with legacy participants. The other reason is that 353 it requires more implementation work. 355 Legacy participants have an existing base of software development 356 built around SOAP/XML and WSDL, and are familiar with TLS. 357 Approaches to ENUM registry interfaces that use these tools will 358 blend more easily into the software products already in use to manage 359 telephone numbers. 361 The use of SOAP permits automatic generation of software to handle 362 the client side of the exchange. Domain name registries had to 363 provide software tool kits to give to registrars to match this 364 functionality. When a change is made to EPP, there will be a lot of 365 software exchanged. 367 From experience with both EPP and SOAP based approaches to registry 368 software, the SOAP based approach is much easier on the software 369 engineering process. The difference between the approaches is not 370 seen in a protocol analysis, but in an analysis of software 371 engineering. 373 13. Security Considerations 375 Security is to be implemented in the applications exchanging data, 376 the requirements here are meant to say that relevant security data 377 will be exchanged in the building of the transport. Specifically, 378 data integrity, authentication and secrecy. (Please note that all 379 three of these can be provided by using TLS, with the certificate 380 handshake being used by the application to complete the security 381 needs). 383 14. IANA Considerations 385 NA 387 15. Acknowledgements 389 Many of the points of information in this document are summarizations 390 of objectives and statements made by individuals on the PEPPERMINT 391 and SPEERMINT mailing lists. We would also like to acknowledge 392 Jeremy Barkan and Otmar Lendl for providing insightful inputs to the 393 original draft. Information on the PEPPERMINT mailing list can be 394 found at http://www.ietf.org/mailman/listinfo/peppermint. 396 16. References 397 16.1. Normative References 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, March 1997. 402 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 403 A., Peterson, J., Sparks, R., Handley, M., and E. 404 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 405 June 2002. 407 16.2. Informational References 409 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 410 STD 13, RFC 1034, November 1987. 412 [RFC1035] Mockapetris, P., "Domain names - implementation and 413 specification", STD 13, RFC 1035, November 1987. 415 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 416 Part Three: The Domain Name System (DNS) Database", 417 RFC 3403, October 2002. 419 [RFC3730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 420 RFC 3730, March 2004. 422 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 423 Resource Identifiers (URI) Dynamic Delegation Discovery 424 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 426 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 427 Resource Identifier (URI): Generic Syntax", STD 66, 428 RFC 3986, January 2005. 430 [RFC4114] Hollenbeck, S., "E.164 Number Mapping for the Extensible 431 Provisioning Protocol (EPP)", RFC 4114, June 2005. 433 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 434 and T. Wright, "Transport Layer Security (TLS) 435 Extensions", RFC 4366, April 2006. 437 [RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an 438 Enumservice Containing Public Switched Telephone Network 439 (PSTN) Signaling Information", RFC 4769, November 2006. 441 [I-D.ietf-speermint-terminology] 442 Malas, D. and D. Mayer, "SPEERMINT Terminology", 443 draft-ietf-speermint-terminology-15.txt, November 2007. 445 Authors' Addresses 447 David Schwartz 448 XConnect Global Networks 449 Malcha Technology Park 450 Building # 1 451 Jerusalem 90961 452 Israel 454 Phone: +972 52 347 4656 455 Email: dschwartz@xconnect.net 456 URI: www.kayote.com 458 Rohan Mahy 459 Plantronics 461 Email: rohan@ekabal.com 462 URI: www.plantronics.com 464 Alan Duric 465 Telio 467 Email: alan.duric@telio.no 468 URI: www.telio.no 470 Edward Lewis 471 NeuStar 472 46000 Center Oak Plaza 473 Building # 1 474 Sterling, VA 20166 475 USA 477 Phone: +1-571-434-5468 478 Email: ed.lewis@neustar.biz 479 URI: www.neustar.biz 481 Full Copyright Statement 483 Copyright (C) The IETF Trust (2008). 485 This document is subject to the rights, licenses and restrictions 486 contained in BCP 78, and except as set forth therein, the authors 487 retain all their rights. 489 This document and the information contained herein are provided on an 490 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 491 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 492 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 493 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 494 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 495 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 497 Intellectual Property 499 The IETF takes no position regarding the validity or scope of any 500 Intellectual Property Rights or other rights that might be claimed to 501 pertain to the implementation or use of the technology described in 502 this document or the extent to which any license under such rights 503 might or might not be available; nor does it represent that it has 504 made any independent effort to identify any such rights. Information 505 on the procedures with respect to rights in RFC documents can be 506 found in BCP 78 and BCP 79. 508 Copies of IPR disclosures made to the IETF Secretariat and any 509 assurances of licenses to be made available, or the result of an 510 attempt made to obtain a general license or permission for the use of 511 such proprietary rights by implementers or users of this 512 specification can be obtained from the IETF on-line IPR repository at 513 http://www.ietf.org/ipr. 515 The IETF invites any interested party to bring to its attention any 516 copyrights, patents or patent applications, or other proprietary 517 rights that may cover technology that may be required to implement 518 this standard. Please address the information to the IETF at 519 ietf-ipr@ietf.org. 521 Acknowledgment 523 Funding for the RFC Editor function is provided by the IETF 524 Administrative Support Activity (IASA).