idnits 2.17.1 draft-channabasappa-drinks-usecases-requirements-02.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 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 (February 3, 2009) is 5532 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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 February 3, 2009 5 Expires: August 7, 2009 7 DRINKS Use cases and Protocol Requirements 8 draft-channabasappa-drinks-usecases-requirements-02 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 7, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 This document captures the use cases and associated requirements for 48 interfaces to provision session establishment data into SIP Service 49 Provider components that aid with session routing. Specifically, the 50 current version of this document focuses on the provisioning of one 51 such element, termed the registry. 53 Table of Contents 55 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Use Cases and Requirements . . . . . . . . . . . . . . . . . . 10 58 3.1. Registry Provisioning . . . . . . . . . . . . . . . . . . 10 59 3.1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . 10 60 3.1.2. Requirements . . . . . . . . . . . . . . . . . . . . . 14 61 3.2. Distribution of data into local data repositories . . . . 17 62 3.3. Miscellaneous Use Cases . . . . . . . . . . . . . . . . . 17 63 3.3.1. Indirect Peering to Selected Destinations . . . . . . 17 64 3.3.2. TBD: RN Destinations . . . . . . . . . . . . . . . . . 17 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 21 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 21 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 73 1. Terminology 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 This document reuses terms from [RFC3261] (e.g., SIP) and 80 [I-D.ietf-speermint-terminology] (e.g., LUF, LRF). In addition, this 81 document specifies the following additional terms. 83 Registry: The authoritative source for provisioned session 84 establishment data (SED) and related information. 86 Local Data Repository: The data store component of an addressing 87 server that provides resolution responses. 89 Destination Group: A set of public identities that are grouped 90 together to facilitate session setup and routing. 92 Public Identity: A generic term that refers to a telephone number 93 (TN), an email address, or other identity as deemed appropriate, 94 such as a globally routable URI of a user address (e.g., 95 mailto:john.doe@example.net). 97 Routing Group: a grouping of SED records. 99 SED Record: A SED Record contains much of the session establishment 100 data or a 'redirect' to another registry where the session 101 establishment data can be discovered. SED Records types supported 102 are NAPTRs, CNAME, DNAME, and NS Records. 104 Data Recipient: SP or SSP that receives or consumes SED and related 105 information. 107 Data Recipient Group: A group of Data Recipients that receive the 108 same set (or subset) of SED and related information. 110 2. Overview 112 The SPEERMINT WG specifies Session Establishment Data, or SED, as the 113 data used to route a call to the next hop associated with the called 114 domain's ingress point. More specifically, the SED is the set of 115 parameters that the outgoing signalling path border elements (SBEs) 116 need to complete the call. See [I-D.ietf-speermint-terminology] for 117 more details. 119 The specification of the format and protocols to configure SED is a 120 task taken up by the DRINKS WG. The use cases and requirements that 121 have been proposed in this regard are compiled in this document. 123 SED is typically created by the terminating SSP and consumed by the 124 originating SSP. For scalability reasons SED is rarely exchanged 125 directly between the intended parties. Instead, it is exchanged via 126 intermediate systems - termed Registries within this document. Such 127 registries receive SED via provisioning transactions from other SSPs, 128 and then distribute the received data into Local Data Repositories. 129 These local data repositories are used for call routing by outgoing 130 SBEs. This is depicted in Figure 1. 132 *-------------* 133 1. Provision SED | | 134 -----------------------> | Registry | 135 | | 136 *-------------* 137 / \ 138 / \ 139 / \ 140 / \ 141 / \ 142 / \ 143 / 2.Distribute \ 144 / SED \ 145 V V 146 +----------+ +----------+ 147 |Local Data| |Local Data| 148 |Repository| |Repository| 149 +----------+ +----------+ 151 Figure 1: General Diagram 153 In this version of the document, we primarily address the use cases 154 and requirements for provisioning registries. Future revisions may 155 include data distribution. The resulting provisioning protocol can 156 be used to provision data into a registry, or between registries. 157 This is depicted in Figure 2. 159 . . . . . . . 160 . . . . . . . registry . . . . . . . 161 . . . . . . . . . 162 . . . 163 . . provision . 164 +-----------+ . +-----------+ 165 | | provision +----------+ provision | | 166 | SSP 1 |------------>| Registry |<-----------| SSP 2 | 167 | | +----------+ | | 168 | +-----+ | /\ | +-----+ | 169 | | LDR | <-------------------- ------------------>| LDR | | 170 | +-----+ | distribute distribute | +-----+ | 171 | | | | 172 +-----------+ +-----------+ 173 . . 174 . . . . . . . . . . . . . . . . . . . . . . . . 175 (provision / distribute) 177 Where, LDR = Local Data Repository 179 Figure 2: Functional Overview 181 The following is a summary of the proposed responsibilities for 182 Registries and Local Data Repositories: 184 o Registries are the authoritative source for provisioned session 185 establishment data (SED) and related information. 187 o Local Data Repositories are the data store component of an 188 addressing server that provides resolution responses. 190 o Registries are responsible for distributing SED and related 191 information to the local data repositories. 193 In addition, this document proposes the following aggregation groups 194 with regards to SED (certain use cases also illustrate these groups): 196 o Aggregation of public Identifiers: The initial input "key" to a 197 SED lookup is a public identifier. Since many public identifiers 198 will share similar (or identical) destinations, and hence return 199 similar (or identical) SED, provisioning the same set of SED for 200 millions of public identifiers is inefficient, especially in cases 201 where the SED needs to be modified. Therefore, an aggregation 202 mechanism to "group" public identifiers is proposed. This 203 aggregation is called a "destination group". 205 o Aggregation of SSPs: It is expected that SSPs may want to expose 206 different sets of SED, depending on the receiving SSP. This 207 exposure may not always be unique, in which case an aggregation 208 makes it efficient. Such an aggregation is proposed, and termed 209 "Data Receipient Group". 211 o Aggregation of SED records: Finally, it is anticipated that a 212 complete set of routing data will consist of more than just one 213 SED record. To be able to create and use the same set of SED 214 records multiple times (without creating duplicates) an 215 aggregation mechanism at this level is proposed, and called 216 "routing group". 218 The above aggregations are illustrated in Figure 3. 220 +---------+ +--------------+ 221 | Data | |DATA RECIPIENT| 222 |Recipient|----------->| GROUP | 223 +---------+ +------.-------+ 224 ^ 225 | 226 | 227 +--------------+ +---------+ 228 | ROUTING | ------------->| SED | 229 | GROUP | | Record | 230 +--------------+ +---------+ 231 ^ ^ 232 | | 233 | | 234 +--------------+ | 235 ----->| DESTINATION |<----- | 236 | | GROUP | | | 237 | +--------------+ | | 238 | ^ | | 239 | | | | 240 | | | | 241 | | | | 242 +---------+ +---------+ +---------+ | 243 | RN | | TN | | Public |------- 244 | | | Range | |Identity | 245 +---------+ +---------+ +---------+ 247 Figure 3: Data Model Diagram 249 A description of the relationships follows: 251 - An RN is associated with one or more Destination Groups 253 - A TN Range object is associated with one or more Destination Group 255 - A Public Identity is associated with zero or more Destination 256 Group 258 - A Public Identity is associated with zero or more SED Records 259 - A Destination Group is associated with zero or more Routing 260 Groups. 262 - A Routing Group is associated with zero or more SED Records; 263 NAPTRs and other SED Record Types associated with Routes are not 264 User or TN specific. For example the user portion of a NAPTR 265 regex will be "\1". 267 - An Routing Group is associated with zero or more peering 268 organizations to control visibility/access privs to that Routing 269 Group and the Destination Groups they expose. 271 - A Data Recipient Group is associated with (contains) zero or more 272 Data Recipients to facilitate the allocation of access privileges 273 to Routing Groups. 275 3. Use Cases and Requirements 277 This section presents the use cases and associated requirements. 279 3.1. Registry Provisioning 281 Registry is the authoritative source for session establishment data 282 (SED). The registry needs to be provisioned with this data to 283 perform its function. This data includes: destination groups, 284 routing groups and data recipient groups. It can also include RNs 285 and TN Ranges. The following sub-sections illustrate the use cases 286 and the requirements, respectively. 288 3.1.1. Use Cases 290 USE CASE #1 Near-real-time provisioning: The registry is 291 provisioned with data that is not accompanied by an 292 effective date or time. In such cases, the registry 293 will validate the data and make it effective in near 294 real-time. 296 USE CASE #2 Non-real-time provisioning: The registry is provisioned 297 via an asynchronous provisioning process. For 298 instance, an SSP has commissioned a new registry and 299 wishes to download a very large number of telephone 300 numbers. Rather than stream individual entities, one 301 at a time, the SSP's back-office system prefers to 302 perform the operation as a set of one or more batches 303 (e.g., via an external data file), instead of the near- 304 real-time provisioning interface. 306 USE CASE #3 Deferred provisioning: The registry is provisioned with 307 data that is accompanied by an effective date and time. 308 In scenarios such as this, the registry will validate 309 the data and wait until the effective date and time to 310 make it effective. TBD: What happens if near-real time 311 data overrides data parked for later incorporation? 313 USE CASE #4 Intra-network SED: SSP wishes to provision their intra- 314 network Session Establishment Data (SED) such that it 315 enables current and future network services to identify 316 and route real-time sessions. For example, in the case 317 of VoIP calls it allows one SoftSwitch (calling) to 318 discover another (called). The SSP provisions IP 319 addressing information pertaining to each SoftSwitch, 320 which is provisioned to the registry but only 321 distributed to a specific local data repository. This 322 SED may differ from the SED that is distributed to 323 other local data repositories. 325 USE CASE #5 Destination Groups: An SSP may wish to control the flow 326 of traffic into their network (ingress) based on 327 groupings of Public Identities. Associating each group 328 of Public Identities with a specific set of ingress 329 SBEs or points-of-interconnect. The SSP, for example, 330 sub-divides the country into four regions: North-East, 331 South-East, Mid-West, and West-Coast. For each region 332 they establish points-of-interconnect with peers and 333 provision the associated SED hostnames or IP addresses 334 of the SBEs used for ingress traffic. Against each 335 region they provision the served Public Identities into 336 groups- termed Destination Groups - and associate those 337 destination groups with the appropriate points of 338 ingres. 340 USE CASE #6 Public Identity is taken out of service: A public 341 identity (or a TN range) is taken out of service 342 because it is no longer valid. The Registry receives a 343 delete operation and removes the public identity from 344 its database. This can also trigger delete operations 345 to keep the local data repositories up-to-date. 347 USE CASE #7 Assigning a set of public identities to a different 348 Destination Group: A set of public identities are 349 assigned a different Destination Group which 350 effectively changes their routing information. This 351 may be due to a network re-arrangement, a Signaling 352 path Border Element being split into two, or a need to 353 do maintenance, two carriers merging, or other 354 considerations. This scenario can also include an 355 effective date and time. 357 USE CASE #8 Moving an SSP from one Data Recipient Group to another: 358 An SSP would like to re-assign the Destination Groups 359 it shares with a peer and move the peer SSP from one 360 Data Recipient Group to another. This results in the 361 moved peer seeing a new and different set of routing 362 data. 364 USE CASE #9 Inter-network SED (Direct and Selective Peering): In 365 this case the SSP is the actual carrier-of-record; the 366 entity serving the end-user. The SSP wishes to 367 communicate different SED data to some of its peers 368 that wish to route to its destinations. So the SSP has 369 implemented direct points-of-interconnect with each 370 peer and therefore would like address-resolution to 371 result in different answers depending on which peer is 372 asking. 374 USE CASE #10 Separation of Responsibility: An SSP's operational 375 practices can seperate the responsibility of 376 provisioning the routing information, and the 377 associated identities, to different entities. For 378 example, a network engineer can establish a physical 379 interconnect with a peering SSP's network and provision 380 the associated domain name, host, and IP addressing 381 information. Separately, for each new service 382 subscription, the SSP's back office system provisions 383 the associated public identities. 385 USE CASE #11 Global TN Destinations: The SSP wishes to add or remove 386 one or multiple fully qualified TN destinations in a 387 single provisioning request. 389 USE CASE #12 TN Range Destinations: The SSP wishes to add or remove 390 one or multiple TN Range destinations in a single 391 provisioning request. TN Ranges support number ranges 392 that need not be 'blocks'. In other words the TN range 393 start can be any number and the TN range end can be any 394 number that is greater than the TN range start. 396 USE CASE #13 Non-TN Destinations: An SSP chooses to peer their 397 messaging service with another SSPs picture/video mail 398 service. Allowing a user to send and receive pictures 399 and/or video messages to a mobile user's handset, for 400 example. The important aspect of this use case is that 401 it goes beyond simply mapping TNs to IP addresses/ 402 hostnames that describe points-of-interconnect between 403 peering network SSP's. Rather, for each user the SSP 404 provisions the subscriber's email address (i.e. 405 jane.doe@example.com). This mapping allows the mobile 406 multimedia messaging service center (MMSC) to use the 407 subscriber email address as the lookup key and route 408 messages accordingly. 410 USE CASE #14 Tier 2 Name Server: An SSP maintains a Tier 2 name 411 server that contains the NAPTR records that constitute 412 the terminal step in the LUF. The SSP needs to 413 provision an registry to direct queries for the SSPs 414 numbers to the Tier 2. Usually queries to the registry 415 should return NS records, but, in cases where the Tier 416 2 uses a different domain suffix from that used in the 417 registry, CNAME and NS records may be employed instead. 419 USE CASE #15 Peering Offer/Acceptance: An SSP offers to allow 420 terminations from another SSP by adding that SSP to a 421 Data Recipient Group it controls. This causes 422 notification of the offered SSP. An SSP receiving a 423 peering offer should be able to accept or decline the 424 offer. If the offer is rejected the Registry should 425 not provision corresponding SED to the rejecting SSP. 426 It is expected that this capability will apply mainly 427 in the transit case where non-authoritative parties (in 428 the sense of not being the terminating SSP for an 429 identity) wish to offer the ability to reach the 430 identity and originating SSPs may wish to restrict the 431 routes that are provisioned to their local data 432 repositories. 434 USE CASE #16 Points of Egress: An SSP has a peering relationship 435 with a peer, and when sending messages to that peer's 436 point of interconnection, the originating SSP wishes to 437 use one or more points of egress. These points of 438 egress may vary for an given peer. This capability is 439 supported by allowing an originating SSP to provision 440 SED for identities terminating to other SSPs where the 441 originating SSP is itself the data recipient. The 442 provisioning SSP may make use of multiple data 443 recipient identities if it requires different sets of 444 egress points be used for calls originating from 445 different parts of its network. Routing from egress 446 points to ingress points of the terminating SSP may be 447 accomplished by static routing from the egress points 448 or by the egress points using data provisioned to the 449 Registry by the terminating SSP. 451 3.1.2. Requirements 453 The following data requirements apply: 455 DREQ1: The registry provisioning data model MUST support the 456 following entities: public identities, destination groups, 457 routing groups and data recipient groups. 459 DREQ2: The registry provisioning data model MUST support the 460 grouping and aggregation of public identities within 461 destination groups. 463 DREQ3: The registry provisioning data model SHOULD support the 464 grouping and aggregation of TN Ranges within destination 465 groups. 467 DREQ4: The registry provisioning data model SHOULD support the 468 grouping and aggregation of RNs within destination groups. 470 The following functional requirements apply: 472 FREQ1: The registry provisioning interface MUST support the 473 creation and deletion of: public identities, destination 474 groups, routing groups and data recipient groups. 476 FREQ2: The registry provisioning interface MUST support near-real- 477 time, non-real-time and deferred provisioning operations. 479 FREQ3: The registry provisioning interface MUST support the 480 following types of modifications: 482 - reassignment of one or more public identities from one 483 destination group to another; 485 - reassignment of one data recipient from one destination 486 group to another; 488 - association and disassociation of a "Default Routing 489 Group" with a Data Recipient; and, 491 - identification of a destination group as a "Carrier of 492 Record" (COR) destination group or a "Transit" destination 493 group. 495 FREQ4: When an entity with a different client identifier than that 496 of the carrier of record for a public identity in a 497 destination group adds a new SSP to a destination recipient 498 group associated with that destination group, the registry 499 provisioning interface MUST: a) notify the new SSP of the 500 updated routing information (which constitutes a peering 501 offer) b) not provision the SED to the new SSP's LDR unless 502 the new SSP signals acceptance. 504 FREQ5: The registry provisioning interface MUST separate the 505 provisioning of the routing information from the associated 506 identities. 508 FREQ6: The registry provisioning protocol MUST define a discrete 509 set of response codes for each supported protocol operation. 510 Each response code MUST definitively indicate whether the 511 operation succeeded or failed. If the operation failed, the 512 response code MUST indicate the reason for the failure. 514 FREQ7: The registry provisioning interface MUST allow an SSP to 515 define multiple sub-identities that can be used in data 516 recipient groups 518 FREQ8: The registry provisioning interface MUST define the 519 concurrency rules, locking rules, and race conditions that 520 underlie the implementation of that protocol operation and 521 that result from the coexistence of protocol operations that 522 can operate on multiple objects in a single operation and 523 bulk file operations that may process for an extended period 524 of time. 526 FREQ9: The registry provisioning interface MUST support the ability 527 for a Data Recipient to optionally define a Routing Group as 528 their Default Routing Group, such that if the Data Recipient 529 performs a resolution request and the lookup key being 530 resolved is not found in the Destination Groups visible to 531 that Data Recipient then the SED Records associated with the 532 Default Routing Group shall be returned in the resolution 533 response. 535 FREQ10: The registry provisioning interface MUST support the ability 536 for the owner of a Routing Group to optionally define Source 537 Based Routing Criteria to be associated with their Routing 538 Group(s). The Source Based Routing Criteria will include 539 the ability to specify zero or more of the following in 540 association with a given Routing Group: Resolution Client IP 541 Address(es) or Domain Names, Calling Party URI(s). The 542 result will be that the resolution server would evaluate the 543 characteristics of the Source, compare them against Source 544 Based Routing Criteria associated with the Routing Groups 545 visible to that Data Recipient, and return any SED Records 546 associated with the matching Routing Groups. 548 FREQ11: The registry provisioning interface MUST track, via a client 549 identifier, the entity provisioning each data object (e.g. 550 Destination Group or Routing Group ). This client 551 identifier will identify the entity that is responsible for 552 that data object from a protocol interface perspective. 553 This client identifier SHOULD be tied to the session 554 authentication credentials that the client uses to connect 555 into to the registry. 557 The registry provisioning interface MUST incorporate a data 558 recipient identifier that identifies the organization 559 responsible for each data object from a business 560 perspective. This organization identifier may or may not 561 ultimately refer to the same organization that the client 562 Identifier refers to. The separation of the data recipient 563 identifier from the client identifier will allow for the 564 separation of the two entities, when the need arises. 566 Exactly one client identifier MUST be allowed to provision 567 objects under a given data recipient identifier. But a 568 client identifier MUST be allowed to provision objects under 569 multiple data recipient identifiers. 571 Objects provisioned under one "Protocol Client Identifier" 572 MUST NOT be alterable by a provisioning session established 573 by another "Protocol Client Identifier". 575 3.2. Distribution of data into local data repositories 577 This section targets use cases concerned with the distribution of SED 578 to local data repositories. This is considered out-of-scope for this 579 version of the document. 581 3.3. Miscellaneous Use Cases 583 This section contains additional use cases for consideration. 585 3.3.1. Indirect Peering to Selected Destinations 587 The SSP transit provider wishes to provide transit peering points for 588 a set of destinations. But that set of destinations does not align 589 with the destination groups that already exist. The SSP wishes to 590 establish its own destination groups for the destinations that it 591 provides transit to. 593 3.3.2. TBD: RN Destinations 595 The SSP does not wish to provision individual TNs, but instead, for 596 ease of management, wishes to provision Routing Numbers ((e.g., as in 597 some number portability implementations). Each RN effectively 598 represents a set of individual TNs, and that set of TNs is assumed to 599 change 'automatically' as TNs are ported in and ported out. Note 600 that this approach requires a query to resolve a TN to an RN prior to 601 using the provisioned data to route. 603 4. Security Considerations 605 Session establishment data allows for the routing of SIP sesions 606 within, and between, SIP Service Providers. Access to this data can 607 compromise the routing of sessions and expose a SIP Service Provider 608 to attacks such as service hijacking and denial of service. The data 609 can be compromised by vulnerable functional components and interfaces 610 identified within the use cases. 612 5. IANA Considerations 614 This document does not register any values in IANA registries. 616 6. Acknowledgments 618 This document is a result of various discussions held by the DRINKS 619 requirements design team, which is comprised of the following 620 individuals, in alphabetical order: Deborah A Guyton (Telcordia), 621 Gregory Schumacher (Sprint), Jean-Francois Mule (CableLabs), Kenneth 622 Cartwright (Verisign), Manjul Maharishi (Verisign), Penn Pfautz (AT&T 623 Corp), Ray Bellis (Nominet), the co-chairs (Richard Shockey, Nuestar; 624 and Alexander Mayrhofer, enum.at GmbH), and the editors of this 625 document. 627 7. References 629 7.1. Normative References 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", BCP 14, RFC 2119, March 1997. 634 7.2. Informative References 636 [I-D.ietf-speermint-terminology] 637 Malas, D. and D. Meyer, "SPEERMINT Terminology", 638 draft-ietf-speermint-terminology-17 (work in progress), 639 November 2008. 641 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 642 A., Peterson, J., Sparks, R., Handley, M., and E. 643 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 644 June 2002. 646 Author's Address 648 Sumanth Channabasappa 649 CableLabs 650 858 Coal Creek Circle 651 Louisville, CO 80027 652 USA 654 Email: sumanth@cablelabs.com