idnits 2.17.1 draft-ietf-drinks-usecases-requirements-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (March 13, 2011) is 4793 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRINKS S. Channabasappa, Ed. 3 Internet-Draft CableLabs 4 Intended status: Informational March 13, 2011 5 Expires: September 14, 2011 7 DRINKS Use cases and Protocol Requirements 8 draft-ietf-drinks-usecases-requirements-05 10 Abstract 12 This document captures the use cases and associated requirements for 13 interfaces that provision session establishment data into SIP Service 14 Provider components, to assist with session routing. Specifically, 15 the current version of this document focuses on the provisioning of 16 one such element, termed the registry. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 14, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Registry Use Cases . . . . . . . . . . . . . . . . . . . . . . 9 55 3.1. Category: Provisioning Mechanisms . . . . . . . . . . . . 9 56 3.2. Category: Interconnect Schemes . . . . . . . . . . . . . . 9 57 3.3. Category: SED Exchange and Discovery Models . . . . . . . 11 58 3.4. Category: SED Record Content . . . . . . . . . . . . . . . 12 59 3.5. Category: Separation and Facilitation of Data 60 Management . . . . . . . . . . . . . . . . . . . . . . . . 12 61 3.6. Category: Lookup Keys . . . . . . . . . . . . . . . . . . 13 62 3.7. Category: Misc . . . . . . . . . . . . . . . . . . . . . . 14 63 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16 64 4.1. Provisioning Mechanisms . . . . . . . . . . . . . . . . . 16 65 4.2. Interconnect Schemes . . . . . . . . . . . . . . . . . . . 16 66 4.3. SED Exchange and Discovery Requirements . . . . . . . . . 16 67 4.4. SED Record Content Requirements . . . . . . . . . . . . . 17 68 4.5. Data Management Requirements . . . . . . . . . . . . . . . 17 69 4.6. Lookup Key Requirements . . . . . . . . . . . . . . . . . 18 70 4.7. Misc. Requirements . . . . . . . . . . . . . . . . . . . . 18 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 23 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 79 1. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 This document reuses terms from [RFC3261] (e.g., SIP, SSP), [RFC5486] 86 (e.g., LUF, LRF, SED) and [RFC5067] (carrier-of-record and transit 87 provider). In addition, this document specifies the following 88 additional terms. 90 Registry: The authoritative source for provisioned session 91 establishment data (SED) and related information. A Registry can 92 be part of an SSP as well as an independent entity. 94 Registrar: An entity that provisions and manages data into the 95 registry. An SSP can act as its own registrar or - additionally 96 or alternatively - delegate this function to a third party who 97 acts as its registrar. 99 Local Data Repository: The data store component of an addressing 100 server that provides resolution responses. 102 Public Identifier: A public identifier refers to a telephone number 103 (TN), a SIP address, or other identity as deemed appropriate, such 104 as a globally routable URI of a user address (e.g., 105 sip:john.doe@example.net). 107 TN Range: A numerically contiguous set (or, in the case of an open 108 numbering plan, a prefix) of telephone numbers whose SED can be 109 looked up (resolved). 111 RN: A Routing Number. See [RFC4694] for details 112 Destination Group: An aggregation of a set of public identifiers, 113 TN Ranges, or RNs that share common SED which is exposed to a 114 common set of peers. 116 Data Recipient: An entity with visibility into a specific set of 117 public identifiers, the destination groups that contain these 118 public identifiers, and a route group's SED records. 120 Route Group: An aggregation that contains a related set of SED 121 records, and is associated with a set of destination groups. 122 Route groups facilitate the management of SED records for one or 123 more data recipients. 125 2. Overview 127 The SPEERMINT WG specifies Session Establishment Data, or SED, as the 128 data used to route a call to the next hop associated with the called 129 domain's ingress point. More specifically, the SED is the set of 130 parameters that the outgoing signaling path border elements (SBEs) 131 need to establish a session. See Section 3.3 of [RFC5486] for more 132 details. 134 The specification of the format and protocols to provision SED is a 135 task taken up by the DRINKS WG. This document contains the use cases 136 and requirements that have been proposed in this regard. 138 SED is typically created by the terminating or next-hop SSP and 139 consumed by the originating SSP. To avoid a multitude of bilateral 140 exchanges, SED is often shared via intermediary systems - termed 141 registries within this document. Such registries receive data via 142 provisioning transactions from SSPs, and then distribute the received 143 data into Local Data Repositories. These local data repositories are 144 used for call routing by outgoing SBEs. This is depicted in 145 Figure 1. 147 *-------------* 148 1. Provision SED | | 149 -----------------------> | Registry | 150 | | 151 *-------------* 152 / \ 153 / \ 154 / \ 155 / \ 156 / \ 157 / \ 158 / 2.Distribute \ 159 / SED \ 160 V V 161 +----------+ +----------+ 162 |Local Data| |Local Data| 163 |Repository| |Repository| 164 +----------+ +----------+ 166 Figure 1: General Diagram 168 In this document, we primarily address the use cases and requirements 169 for provisioning registries. Future revisions may include data 170 distribution to local data repositories. The resulting provisioning 171 protocol can be used to provision data into a registry, or between 172 multiple registries operating in parallel. In Figure 2, the case of 173 multiple registries is depicted with dotted lines. 175 . . . . . . . 176 . . . . . . . registry . . . . . . . 177 . . . . . . . . . 178 . . . 179 . . . 180 . . provision . 181 +-----------+ . +-----------+ 182 | | provision +----------+ provision | | 183 | SSP 1 |------------>| Registry |<-----------| SSP 2 | 184 | | +----------+ | | 185 | +-----+ | /\ | +-----+ | 186 | | LDR | <-------------------- ------------------>| LDR | | 187 | +-----+ | distribute distribute | +-----+ | 188 | | | | 189 +-----------+ +-----------+ 190 . . 191 . . . . . . . . . . . . . . . . . . . . . . . . 192 (provision / distribute) 194 Where, LDR = Local Data Repository 196 Figure 2: Functional Overview 198 In addition, this document proposes the following aggregation groups 199 with regards to SED (refer to the use cases in Section 3.5 for the 200 rationale): 202 o Aggregation of public Identifiers into a destination group. 204 o Aggregation of SED records into a Route Group. 206 The data model depicted in Figure 3 shows the various entities, 207 aggregations and the relationships between them. 209 +---------+ +--------------+ +---------+ 210 | Data |0..n 0..n| ROUTE | 1 0..n| SED | 211 |Recepient|------------| GROUP | --------------| Record | 212 +---------+ +--------------+ +---------+ 213 |0..n |0..n 214 | | 215 | | 216 | | 217 |0..n | 218 1 +--------------+ 0..1 | 219 ---------| DESTINATION |--------- | 220 | | GROUP | | | 221 | +--------------+ | | 222 | | | | 223 | 1| | | 224 | | | | 225 | | | | 226 0..n | 0..n | | 0..n | 227 +---------+ +---------+ +----------+ | 228 | RN | | TN | | Public |---- 229 | | | Range | |Identifier| 1 230 +---------+ +---------+ +----------+ 232 Figure 3: Data Model Diagram 234 The relationships are as described below: 236 - A Public Identifier object can be directly related to zero or more 237 SED Record objects, and a SED Record object can be related to 238 exactly one Public Identifier object. 240 - A Destination Group object can contain zero or more TN Range 241 objects, and a TN Range object can be contained in exactly one 242 Destination Group object. 244 - A Destination Group object can contain zero or more Public 245 Identifier objects, and a Public Identifier object can be 246 contained in exactly one Destination Group object. 248 - A Destination Group object can contain zero or more RN objects, 249 and an RN object can be contained in exactly one Destination Group 250 object. 252 - A Route Group object can contain zero or more SED Record objects, 253 and a SED Record object can be contained in exactly one Route 254 Group object. 256 - A Route Group object can be associated with zero or more 257 Destination Group objects, and a Destination Group object can be 258 associated with zero or more Route Group objects. 260 - A Data Recipient object can be associated with zero or more Route 261 Group objects, and a Route Group object can refer to zero or more 262 Data Recipient objects. 264 3. Registry Use Cases 266 This Section documents use cases related to the provisioning of the 267 registry. Any request to provision, modify or delete data is subject 268 to authorization. However, the act of authorization is considered to 269 be out of scope of this document. 271 3.1. Category: Provisioning Mechanisms 273 UC PROV #1 Real-Time Provisioning: Registrars have operational 274 systems that provision public identifiers, in association 275 with their SED. These systems often function in a manner 276 that expect or require that these provisioning activities 277 be completed immediately, as apposed to an out-of-band or 278 batch provisioning scheme that can occur at a later time. 279 This type of provisioning is referred to as real-time, or 280 on-demand provisioning. 282 UC PROV #2 Non-Real-Time Bulk Provisioning: Operational systems that 283 provision public identifiers and associated SED sometimes 284 expect that these provisioning activities be batched up 285 into large sets. These batched requests are then 286 processed using a provisioning mechanism that is out-of- 287 band and occurs at a later time. 289 UC PROV #3 Multi-Request Provisioning: Regardless of whether a 290 provisioning action is performed in real-time or not, 291 SSPs often perform several provisioning actions on 292 several objects in a single request or transaction. This 293 is done for performance and scalability reasons, and for 294 transactional reasons, such that the set of provisioning 295 actions either fail or succeed atomically, as a complete 296 set. 298 3.2. Category: Interconnect Schemes 300 UC INTERCONNECT #1 Inter-SSP SED: SSPs create peering relationships 301 with other SSPs in order to establish 302 interconnects. Establishing these interconnects 303 involves, among other things, communicating and 304 enabling the points of ingress and other SED used 305 to establish sessions to a set of public 306 identifiers. 308 UC INTERCONNECT #2 Direct vs Indirect Peering: Some inter-SSP 309 peering relationships are created to enable the 310 establishment of sessions to the public 311 identifiers for which an SSP is the carrier-of- 312 record. This is referred to as direct peering. 313 Other inter-SSP peering relationships are created 314 to enable the establishment of sessions to public 315 identifiers for which an SSP is a transit 316 provider. This is referred to as indirect 317 peering. Some SSPs take into consideration an 318 SSP's role as a transit or carrier-of-record 319 provider when selecting a route to a public 320 identifier. 322 UC INTERCONNECT #3 Intra-SSP SED: SSPs support the establishment of 323 sessions between their own public identifiers, 324 not just to other SSPs' public identifiers. 325 Enabling this involves, among other things, 326 communicating and enabling intra-SSP signaling 327 points and other SED that can differ from inter- 328 SSP signaling points and SED. 330 UC INTERCONNECT #4 Selective Peering (a.k.a. per peer policies): 331 SSPs create peering relationships with other SSPs 332 in order to establish interconnects. However, 333 SSPs peering relationships often result in 334 different points of ingress or other SED for the 335 same set of public identifiers. Selective 336 peering is done on a Route Group basis. 338 UC INTERCONNECT #5 Provisioning of a delegated hierarchy: An SSP may 339 decide to maintain its own infrastructure to 340 contain the route records that constitute the 341 terminal step in the LUF. In such cases, the SSP 342 will provision registries to direct queries for 343 the SSP's public identifiers to its own 344 infrastructure, rather than provisioning the 345 route records directly. For example, in the case 346 of DNS-based route records, such a delegated 347 hierarchy would make use of NS and CNAME records, 348 while a flat structure would make use of NAPTR 349 resource records. 351 3.3. Category: SED Exchange and Discovery Models 353 UC SED EXCHANGE #1 SED Exchange and Discovery using unified LUF/LRF: 354 When establishing peering relationships some SSPs 355 may wish to communicate or receive SED (e.g., 356 points of ingress) that constitutes the 357 aggregated result of both LUF and LRF. 359 UC SED EXCHANGE #2 SED Exchange and Discovery using LUF's Domain 360 Name: When establishing peering relationships 361 some SSPs may not wish to communicate or receive 362 points of ingress and other SED using a registry. 363 They wish to only communicate or receive domain 364 names (LUF step only), and then independently 365 resolvable those domain names via [RFC3263] to 366 the final points of ingress data (and other SED). 368 UC SED EXCHANGE #3 SED Exchange and Discovery using LUF's 369 Administrative Domain Identifier: When 370 establishing peering relationships some SSPs may 371 not wish to communicate or receive points of 372 ingress and other SED using a registry. They 373 wish to only communicate or receive an 374 administrative domain identifier, which is not 375 necessarily resolvable via DNS. The subsequent 376 process of using that administrative domain 377 identifier to select points of ingress or other 378 SED can be SSP specific and occurs outside the 379 context of this protocol. 381 UC SED EXCHANGE #4 Co-existent SED Exchange and Discovery Models: 382 When supporting multiple peering relationships 383 some SSPs have the need to concurrently support 384 all three of the SED Exchange and Discovery 385 Models described above, for the same set of 386 Public Identifiers. 388 3.4. Category: SED Record Content 390 UC SED RECORD #1 SED Record Content: Establishing interconnects 391 between SSPs involves, among other things, 392 communicating points of ingress, the service types 393 (SIP, SIPS, etc) supported by each point of 394 ingress, and the relative priority of each point of 395 ingress for each service type. 397 UC SED RECORD #2 Time-To-Live (TTL): For performance reasons, 398 querying SSPs sometimes cache SED that had been 399 previously looked up for a given public identity. 400 In order to accomplish this, SSPs sometimes specify 401 the TTL associated with a given SED record. 403 3.5. Category: Separation and Facilitation of Data Management 405 UC DATA #1 Separation of Provisioning Responsibility: An SSP's 406 operational practices often separate the responsibility 407 of provisioning the points of ingress and other SED, from 408 the responsibility of provisioning public identifiers (or 409 TN ranges or RNs). For example, a network engineer can 410 establish a physical interconnect with a peering SSP's 411 network and provision the associated domain name, host, 412 and IP addressing information. Separately, for each new 413 subscriber, the SSP's provisioning systems provision the 414 associated public identifiers. 416 UC DATA #2 Destination Groups: SSPs often provision identical SED 417 for large numbers of public identifiers. For reasons of 418 efficiency, groups of public identifiers that have the 419 same SED can be aggregated. These aggregations are known 420 as destination groups. The SED is then indirectly 421 associated with destination groups rather than with each 422 individual public identity. 424 UC DATA #3 Route Groups: SSPs often provision identical SED for 425 large numbers of public identifiers, and then expose that 426 relationship between a group of SED records and a group 427 of public identifiers to one or more SSPs. This combined 428 grouping of SED records and Destination Groups 429 facilitates management of public identity SED 430 relationships and the list of peers (data recipients) 431 that can lookup those public identifiers and receive that 432 SED. This dual set of SED Records and Destination Groups 433 is termed as a Route Group. 435 3.6. Category: Lookup Keys 437 UC LOOKUP #1 Additions and deletions: SSPs often allocate and de- 438 allocate specific public identifiers to and from end- 439 users. This involves, among other things, activating 440 or deactivating specific public identifiers (or TN 441 ranges or RNs), and directly (or indirectly) 442 associating them with the appropriate points of ingress 443 and other SED. 445 UC LOOKUP #2 Carrier-of-Record vs Transit Lookup Key Provisioning: 446 Some inter-SSP peering relationships are created to 447 enable the establishment of sessions to the lookup keys 448 for which an SSP is the carrier-of-record. Other 449 inter-SSP peering relationships are created to enable 450 the establishment of sessions to lookup keys for which 451 an SSP is a transit provider. Some SSPs take into 452 consideration an SSP's role as a transit or carrier-of- 453 record provider when selecting a route to a public 454 identifier. 456 UC LOOKUP #3 Multiplicity of Identical Lookup Keys: As described in 457 previous use cases, SSPs provision lookup keys and 458 their associated SED for multiple peering SSPs, and as 459 both the carrier-of-record and transit provider. As a 460 result, a given lookup key can reside in multiple 461 destination groups at any given time. 463 UC LOOKUP #4 Lookup Key Destination Group Modification: SSPs often 464 change the SED associated with a given lookup key. 465 This involves, among other things, directly or 466 indirectly associating them with a different point of 467 ingress, different services, and/or different other 468 SED. 470 UC LOOKUP #5 Lookup Key Carrier-Of-Record vs Transit Modification: 471 SSPs may have the need to change their Carrier-Of- 472 Record vs Transit role for lookup keys they previously 473 provisioned. 475 UC LOOKUP #6 Modification of authority: An SSP indicates that it is 476 the carrier-of-record for an existing public identity 477 or TN Range. If the public identity or TN Range was 478 previously associated with a different carrier-of- 479 record then there are multiple possible outcomes, such 480 as: a) the previous carrier-of-record is disassociated, 481 b) the previous carrier-of-record is relegated to 482 transit status, or c) the new carrier-of-record is 483 placed in inactive mode. The choice may be dependent 484 on the deployment scenario, and is out of scope for 485 this document. 487 3.7. Category: Misc 489 UC MISC #1 Number Portability: The SSP wishes to provide, in query 490 response to public identifiers, an associated routing 491 number (RN). This is the case where a set of public 492 identifiers is no longer associated with original SSP but 493 have been ported to a recipient SSP, who provides access 494 to these identifiers via a switch on the SS7 network 495 identified by the RN. 497 UC MISC #2 Data Recipient Offer and Accept: When a peering 498 relationship is established (or invalidated) SSPs 499 provision (or remove) data recipients in the registry. 500 However, a peer may first need to accept it's role (as a 501 data recipient) before such a change is made effective. 502 Alternatively an auto-accept feature can be configured 503 for a given data recipient. 505 UC MISC #3 Open numbering plans: In several countries, an open 506 numbering plan is used, which is where the carrier-of- 507 record is only aware of a portion of the E.164 number 508 (i.e., the prefix). The carrier-of-record may not know 509 the complete number, or the number of digits in the 510 number. The rest of the digits are handled offline 511 (e.g., by a PBX). For example, an SSP can be the 512 carrier-of-record for "+123456789", and is also the 513 carrier-of-record for every possible expansion of that 514 number such as "+12345678901" and "+123456789012", even 515 though the SSP does not know what those expansions could 516 be. This can be described as the carrier-of-record 517 effectively being authoritative for the prefix. 519 4. Requirements 521 This Section lists the requirements based on the use cases in 522 Section 3. Unless explicitly stated as optional, the registry 523 provisioning interface must support these requirements. 525 4.1. Provisioning Mechanisms 527 REQ-PROV-1: Real-time provisioning. 529 REQ-PROV-2: Non-real-time bulk provisioning. 531 REQ-PROV-3: Multi-request provisioning. 533 4.2. Interconnect Schemes 535 REQ-INTERCONNECT-1: Inter-SSP peering. 537 REQ-INTERCONNECT-2: Direct and Indirect peering. 539 REQ-INTERCONNECT-3: Intra-SSP SED. 541 REQ-INTERCONNECT-4: Selective peering. 543 REQ-INTERCONNECT-5: Provisioning of a delegated hierarchy. 545 4.3. SED Exchange and Discovery Requirements 546 REQ-SED-1: SED containing unified LUF and LRF content. 548 REQ-SED-2: SED containing LUF-only data using domain names. 550 REQ-SED-3: SED containing LUF-only data using administrative 551 domains. 553 REQ-SED-4: Support for all the other REQ-SED requirements, 554 concurrently, for the same public identifier. 556 4.4. SED Record Content Requirements 558 REQ-SED-RECORD-1: Ability to provision SED record content. 560 REQ-SED-RECORD-2: (Optional) Communication of an associated TTL for 561 a SED Record. 563 4.5. Data Management Requirements 565 REQ-DATA-MGMT-1: Separation of responsibility for the provisioning 566 the points of ingress and other SED, from the 567 responsibility of provisioning public identifiers. 569 REQ-DATA-MGMT-2: Ability to aggregate a set of public identifiers as 570 destination groups. 572 REQ-DATA-MGMT-3: Ability to create the aggregation termed route 573 group. 575 4.6. Lookup Key Requirements 577 REQ-LOOKUP-1: Provisioning of, and modifications to, the following 578 aggregations: destination group and route groups. 580 REQ-LOOKUP-2: Ability to distinguish an SSP as either the carrier- 581 of-record provider or transit provider. 583 REQ-LOOKUP-3: A given lookup key (e.g., public identity, RN, TN 584 Range) can reside in multiple destination groups at 585 the same time. 587 REQ-LOOKUP-4: Modification of lookup keys by allowing them to be 588 moved to a different destination group via an atomic 589 operation. 591 REQ-LOOKUP-5: SSPs can indicate a change to their role from carrier- 592 of-record provider to transit, or vice-versa. 594 REQ-LOOKUP-6: Support for modification of authority with the 595 conditions described in UC LOOKUP #6. 597 4.7. Misc. Requirements 599 REQ-MISC-1: Number portability support. 601 REQ-MISC-2: Ability for the SSP to be offered a peering 602 relationship, and for the SSP to accept (explicitly or 603 implicitly) or reject such an offer. 605 REQ-MISC-3: Support for open numbering plans. 607 5. Security Considerations 609 Session establishment data allows for the routing of SIP sessions 610 within, and between, SIP Service Providers. Access to this data can 611 compromise the routing of sessions and expose a SIP Service Provider 612 to attacks such as service hijacking and denial of service. The data 613 can be compromised by vulnerable functional components and interfaces 614 identified within the use cases. 616 A provisioning protocol or interface that implements the described 617 use cases MUST therefore provide data confidentiality, and MUST 618 ensure message integrity for the provisioning flow. Authentication 619 and authorization of the provisioning entities are REQUIRED features 620 of the protocol and interfaces. 622 6. IANA Considerations 624 This document does not register any values in IANA registries, nor 625 request the creation of a registry. 627 7. Acknowledgments 629 This document is a result of various discussions held within the 630 DRINKS WG; specifically , in alphabetical order: Alexander Mayrhofer, 631 Deborah A Guyton, Gregory Schumacher, Jean-Francois Mule, Kenneth 632 Cartwright, Manjul Maharishi, Penn Pfautz, Ray Bellis, Richard 633 Shockey, and Syed Ali. 635 This specific version of the document is a result of contributions 636 from the following individuals: Alexander Mayrhofer, Otmar Lendl, 637 Sohel Khan, and Peter Koch. In addition, we also thank Brian Rose 638 and Jon Peterson for suggestions we incorporated. 640 8. References 642 8.1. Normative References 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, March 1997. 647 [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia 648 Interconnect (SPEERMINT) Terminology", RFC 5486, 649 March 2009. 651 8.2. Informative References 653 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 654 A., Peterson, J., Sparks, R., Handley, M., and E. 655 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 656 June 2002. 658 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 659 Protocol (SIP): Locating SIP Servers", RFC 3263, 660 June 2002. 662 [RFC4694] Yu, J., "Number Portability Parameters for the "tel" URI", 663 RFC 4694, October 2006. 665 [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM 666 Requirements", RFC 5067, November 2007. 668 Author's Address 670 Sumanth Channabasappa 671 CableLabs 672 858 Coal Creek Circle 673 Louisville, CO 80027 674 USA 676 Email: sumanth@cablelabs.com