idnits 2.17.00 (12 Aug 2021) /tmp/idnits44990/draft-ietf-dime-app-design-guide-13.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 11, 2012) is 3782 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 244, but not defined == Unused Reference: 'I-D.ietf-dime-diameter-qos' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dime-mip6-split' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'RFC3588' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'RFC4006' is defined on line 647, but no explicit reference was found in the text == Outdated reference: draft-ietf-dime-diameter-qos has been published as RFC 5866 == Outdated reference: draft-ietf-dime-mip6-integrated has been published as RFC 5447 == Outdated reference: draft-ietf-dime-mip6-split has been published as RFC 5778 == Outdated reference: draft-ietf-dime-qos-attributes has been published as RFC 5777 == Outdated reference: draft-ietf-dime-rfc3588bis has been published as RFC 6733 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4006 (Obsoleted by RFC 8506) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintanence and Extensions V. Fajardo 3 (DIME) 4 Internet-Draft H. Tschofenig 5 Intended status: Informational Nokia Siemens Networks 6 Expires: July 14, 2012 L. Morand, Ed. 7 Orange Labs 8 January 11, 2012 10 Diameter Applications Design Guidelines 11 draft-ietf-dime-app-design-guide-13 13 Abstract 15 The Diameter Base protocol provides facilities for protocol 16 extensibility enabling to define new Diameter applications or modify 17 existing applications. This document is a companion document to the 18 Diameter Base protocol that further explains and clarifies the rules 19 to extend the Diameter Base protocol. It is meant as a guidelines 20 document and therefore it does not add, remove or change existing 21 rules. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on July 14, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Adding a new command . . . . . . . . . . . . . . . . . . . . . 8 67 5. Deleting a Command . . . . . . . . . . . . . . . . . . . . . . 9 68 6. Reusing Existing Commands . . . . . . . . . . . . . . . . . . 10 69 6.1. Adding AVPs to a Command . . . . . . . . . . . . . . . . . 10 70 6.2. Deleting AVPs from a Command . . . . . . . . . . . . . . . 11 71 7. Reusing Existing AVPs . . . . . . . . . . . . . . . . . . . . 13 72 8. Rules for new Applications . . . . . . . . . . . . . . . . . . 14 73 8.1. Use of Application-Id in a Message . . . . . . . . . . . . 14 74 8.2. Application Specific Session State Machine . . . . . . . . 15 75 9. End-to-End Applications Capabilities Exchange . . . . . . . . 16 76 10. Diameter Accounting Support . . . . . . . . . . . . . . . . . 17 77 11. Generic Diameter Extensions . . . . . . . . . . . . . . . . . 19 78 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 79 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 80 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 81 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 82 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 83 16.1. Normative References . . . . . . . . . . . . . . . . . . . 25 84 16.2. Informative References . . . . . . . . . . . . . . . . . . 26 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 87 1. Introduction 89 The Diameter Base protocol provides facilities to extend the Diameter 90 Base protocol (see Section 1.3 of [I-D.ietf-dime-rfc3588bis]). In 91 the context of this document, extending Diameter means one of the 92 following: 94 1. A new functionality is being added to an existing Diameter 95 application without defining a new application. 97 2. A new Diameter application is being defined by extending an 98 existing application. 100 3. A completely new application is being defined that has nothing in 101 common with existing applications. 103 4. A new generic functionality is being defined that can be reused 104 across different applications. 106 All of these choices are design decisions that can done by any 107 combination of reusing existing or defining new commands, AVPs or AVP 108 values. Protocol designers do, however, not have total freedom when 109 making their design. A number of rules defined in 110 [I-D.ietf-dime-rfc3588bis] place constraints on when an extension 111 demands a new Diameter Application to be defined or a new Command 112 Code to be registered. The objective of this document is the 113 following: 115 o Clarify updated Diameter extensibility rules in the Diameter Base 116 Protocol. 118 o Clarify usage of certain Diameter functionalitiessi which are not 119 explicitly described in the Diameter Base specification. 121 o Discuss design choices and provide guidelines when defining 122 applications. 124 o Present tradeoffs of design choices. 126 2. Terminology 128 This document reuses the terminology used in 129 [I-D.ietf-dime-rfc3588bis]. 131 3. Overview 133 As it is currently interpreted and practiced, the Diameter Base 134 protocol is a two-layer protocol. The lower layer is mainly 135 responsible for managing connections between neighboring peers and 136 for message routing. The upper layer is where the Diameter 137 applications reside. This model is in line with a Diameter node 138 having an application layer and a peer-to-peer delivery layer. The 139 Diameter Base protocol document completely defines the architecture 140 and behavior of the message delivery layer and then provides the 141 framework for designing Diameter applications on the application 142 layer. This framework includes definitions of application sessions 143 and accounting support (see Section 8 and 9 of 144 [I-D.ietf-dime-rfc3588bis]). The remainder of this document also 145 treats a Diameter node as a single instance of a Diameter message 146 delivery layer and one or more Diameter applications using it. 148 Extending Diameter can mean the reuse of commands, AVPs and AVP 149 values in any combination for the purpose of inheriting the features 150 of an existing Diameter application. This section discusses the 151 rules on how such reuse can be done. 153 When reusing existing applications, the requirements of the new 154 applications are typically not completely unique and hence a lot can 155 be re-used from existing specifications. Therefore, there is a 156 greater likelihood of ambiguity on how much of the existing 157 application can be reused and what would be the implications for both 158 the new and existing application. To broadly categorize, the rules 159 for reusing existing applications can fall into two categories, as 160 listed below. 162 Minor Extension: This, for example, is the case when optional AVPs 163 are being defined. In general, this includes everything that is 164 not covered by the next category. The standardization effort will 165 be fairly small. 167 Major Extension: Such an extension requires the definition of a new 168 Diameter application. The rules outlined in Section 1.2 of 169 [I-D.ietf-dime-rfc3588bis] indicate when an extension requires a a 170 new Command Code to be registered and when new Diameter 171 applications have to be defined. Typically, these types of 172 extensions require a longer and more careful effort depending on 173 the degree of re-use. Therefore, the amount of time and effort to 174 complete the specification should also be considered by the 175 designer. 177 The subsequent sections provide discussions about the specific 178 Diameter Base protocol rules. 180 4. Adding a new command 182 Adding a new command is considered a major extension and requires a 183 new Diameter application to be defined. Adding a new command to an 184 application means either defining a completely new command or 185 importing an existing command from another application whereby the 186 new application inherits some or all of the functionality of the 187 application where the command came from. In the former case, the 188 decision to create an new application is straightforward since this 189 is typically a result of adding a new functionality that does not 190 exist yet. For the latter, the decision will depend on whether 191 importing the command in a new application is more suitable than 192 simply using the existing application as it is in conjunction with 193 any other application. Therefore, a case by case study of each 194 application requirement should be applied. 196 In general, it is difficult to come to a hard guideline, and so a 197 case by case study of each application requirement should be applied. 198 Before adding or importing a command, application designers should 199 consider the following: 201 o Can the new functionality be fulfilled by creating a new 202 application independent from the existing applications? In this 203 case, both old and new application can work independent of, but 204 cooperating with each other. 206 o Can the existing application be reused without major extensions 207 that requires the definition of a new application, e.g. new 208 funtionality introduced by the creation of new optional AVPs. 210 o Care should be taken to avoid a liberal method of importing 211 existing commands that results in a monolithic and hard to manage 212 application which supports many different functionalities. 214 5. Deleting a Command 216 Although this process is not typical, removing a command to an 217 application requires a new Diameter application to be defined. It is 218 unusual to delete an existing command from an application for the 219 sake of deleting it or the functionality it represents. This 220 normally indicates of a flawed design. An exception might be if the 221 intent of the deletion is to create a newer version of the same 222 application which is somehow simpler than the previous version. 224 6. Reusing Existing Commands 226 This section discusses rules in adding and/or deleting AVPs from an 227 existing command of an existing application. The cases described in 228 this section may not necessarily result in the creation of new 229 applications. 231 6.1. Adding AVPs to a Command 233 Based on the rules in [I-D.ietf-dime-rfc3588bis], AVPs that are added 234 to an existing command can be categorized into: 236 o Mandatory to understand AVPs. As defined in 237 [I-D.ietf-dime-rfc3588bis], these are AVPs with the M-bit flag 238 set, which means that a Diameter node receiving are required to 239 understand not only their values but their semantics. Failure to 240 do so will cause an message handling error. This is regardless of 241 whether these AVPs are required or optional as specified by the 242 commands ABNF. 244 o Optional AVPs. [TBD] 246 The rules are strict in the case where the AVPs to be added are 247 mandatory. A mandatory AVP cannot be added to or deleted from an 248 existing command with defining a new Diameter application. 249 [I-D.ietf-dime-rfc3588bis] states that doing so would require the 250 definition of a new application. This falls into the "Major 251 Extensions" category. Despite the clarity of the rule, ambiguity 252 still arises when trying to decide whether a new AVP being added 253 should be mandatory to begin with. The follow are a few common 254 questions that application designers should contemplate when trying 255 to decide: 257 o Is it required for the receiving side to be able to process and 258 understand the AVP and its content (rather than just writing it's 259 content into to a file)? 261 o Do the AVPs change the state machine of the application ? 263 o Would the presence of the new AVPs (or the newly specified value 264 contained in an existing AVP) lead to a different number of 265 roundtrips, effectively changing the state machine of the 266 application? 268 o Would the AVP be used to differentiate between old and new 269 versions of the same application whereby the two versions are not 270 backward compatible? 272 o Will it have duality in meaning, i.e., be used to carry 273 application related information as well as be used to indicate 274 that the message is for a new application? 276 When one of the above questions can be answered with 'yes' then the 277 M-bit has to be set. If application designers are contemplating on 278 the use of optional AVPs instead, then the following are some of the 279 pitfalls that should be avoided: 281 o Use of optional AVPs with intersecting meaning. One AVP has 282 partially the same usage and meaning as another AVP. The presence 283 of both can lead to confusion. 285 o An optional AVPs with dual purpose, i.e. to carry applications 286 data as well as to indicate support for one or more features. 287 This has a tendency to introduce interpretation issues. 289 o Adding one or more optional AVPs and indicating (usually within 290 descriptive text for the command) that at least one of them has to 291 be present in the command. This essentially circumventing the 292 ABNF and is equivalent to adding a mandatory AVPs to the command. 294 These practices generally result in interoperability issues and 295 should be avoided as much as possible. 297 6.2. Deleting AVPs from a Command 299 When deleting an AVP from a Command the following cases need to be 300 differentiated: 302 o An AVP that is indicated as {} in the ABNF in the Command (with or 303 without the M-bit set). In this case the new Command Code and 304 subsequently a new Diameter application has to be specified. 306 o An AVP that is indicated as [] in the ABNF in the Command (with 307 the M-bit set). No new Command Code has to be specified but the 308 definition of a new Diameter application is required. 310 o An AVP that is indicated as [] in the ABNF in the Command (without 311 the M-bit set). In this case the AVP can be deleted without 312 consequences. 314 If possible application designers should attempt the reuse the 315 Command ABNF without modification and simply ignore (but not delete) 316 any optional AVP that will not be used. This is to maintain 317 compatibility with existing applications that will not know about the 318 new functionality as well as maintain the integrity of existing 319 dictionaries. 321 7. Reusing Existing AVPs 323 This section discusses rules in adding, deleting or modifying the 324 specified values of an AVP. 326 When reusing AVPs in a new application, the AVP flag setting, such as 327 the mandatory flag ('M'-bit), has to be re-evaluated for a new 328 Diameter application and, if necessary, even for every Command within 329 the application. In general, for AVPs defined outside of the base 330 protocol, its mandatory characteristics are tied to its role within 331 an application and Command. 333 8. Rules for new Applications 335 The general theme of Diameter extensibility is to reuse commands, 336 AVPs and AVP values as much as possible. However, some of the 337 extensibility rules described in the previous section also apply to 338 scenarios where a designer is trying to define a completely new 339 Diameter application. 341 This section discusses the case where new applications have 342 requirements that cannot be filled by existing applications and would 343 require definition of completely new commands, AVPs and/or AVP 344 values. Typically, there is little ambiguity about the decision to 345 create these types of applications. Some examples are the interfaces 346 defined for the IP Multimedia Subsystem of 3GPP, i.e. Cx/Dx 347 ([TS29.228] and [TS29.229]), Sh ([TS29.328] and [TS29.329]) etc. 349 Application designers should also follow the theme of Diameter 350 extensibility which in this case means to import existing AVPs and 351 AVP values for any newly defined commands. In certain cases where 352 accounting will be used, the models described in Section 10 should 353 also be considered. Though some decisions may be clear, designers 354 should also consider certain aspects of defining a new application. 355 Some of these aspects are described in following sections. 357 8.1. Use of Application-Id in a Message 359 When designing new applications, designers should specify that the 360 application ID carried in all session level messages must be the 361 application ID of the application using those messages. This 362 includes the session level messages defined in base protocol, i.e., 363 RAR/RAA, STR/STA, ASR/ASA and possibly ACR/ACA in the coupled 364 accounting model, see Section 10. Existing specifications may not 365 adhere to this rule for historical or other reasons. However, this 366 scheme should be followed to avoid possible routing problems for 367 these messages. 369 In general, when a new application has been allocated with a new 370 application id and it also reuses existing commands with or without 371 modifications (Sec 4.1), it must use the newly allocated application 372 id in the header and in all relevant application id AVPs (Auth- 373 Application-Id or Acct-Application-Id) present in the commands 374 message body. 376 Additionally, application designs using 377 Vendor-Specific-Application-Id AVP should not use the Vendor-Id AVP 378 to further dissect or differentiate the vendor-specification 379 application id. Diameter routing is not based on the Vendor-Id. As 380 such, the Vendor-ID should not be used as an additional input for 381 routing or delivery of messages. In general, the Vendor-Id AVP is an 382 informational AVP only and kept for backward compatibility reasons. 384 8.2. Application Specific Session State Machine 386 Section 8 of [I-D.ietf-dime-rfc3588bis] provides session state 387 machines for authentication, authorization and accounting (AAA) 388 services. When a new application is being defined that cannot 389 clearly be categorized into any of these services it is recommended 390 that the application itself define its own session state machine. 391 The existing session state machines defined by 392 [I-D.ietf-dime-rfc3588bis] is not intended for general use beyond AAA 393 services, therefore any behavior not covered by that category would 394 not fit well. Support for server initiated request is a clear 395 example where an application specific session state machine would be 396 needed, for example, the Rw interface for ITU-T push model. 398 9. End-to-End Applications Capabilities Exchange 400 It is also possible that applications can use optional AVPs to 401 exchange application specific capabilities and features. These AVPs 402 are exchanged on an end-to-end basis. Examples of this can be found 403 in [I-D.ietf-dime-mip6-integrated] and 404 [I-D.ietf-dime-qos-attributes]. 406 The end-to-end capabilities AVPs can aid in the following cases: 408 o Formalizing the way new functionality is added to existing 409 applications by announcing support for it. 411 o Applications that do not understand these AVP can discard it upon 412 receipt. In such case, senders of the AVP can also safely assume 413 the receiving end-point does not support any functionality carried 414 by the AVP if it is not present in subsequent responses. 416 o Useful in cases where deployment choices are offered and the 417 generic design can be made available for a number of applications. 419 Note that this list is not meant to be comprehensive. 421 10. Diameter Accounting Support 423 Accounting can be treated as an auxiliary application which is used 424 in support of other applications. In most cases, accounting support 425 is required when defining new applications. This document provides 426 two(2) possible models for using accounting: 428 Split Accounting Model 430 In this model, the accounting messages will use the Diameter base 431 accounting application ID (value of 3). The design implication 432 for this is that the accounting is treated as an independent 433 application, especially during Diameter routing. This means that 434 accounting commands emanating from an application may be routed 435 separately from the rest of the other application messages. This 436 may also imply that the messages generally end up in a central 437 accounting server. A split accounting model is a good design 438 choice when: 440 * The application itself will not define its own unique 441 accounting commands. 443 * The overall system architecture permits the use of centralized 444 accounting for one or more Diameter applications. 446 Centralizing accounting may have advantages but there are also 447 drawbacks. The model assumes that the accounting server can 448 somehow differentiate received accounting messages. Since the 449 received accounting messages can be for any application and/or 450 service, the accounting server has to be have a method to uniquely 451 match accounting messages with applications and/or services being 452 accounted for. This may mean defining new AVPs, checking the 453 presence, absence or contents of existing AVPs or checking the 454 contents of the accounting records itself. But in general, there 455 is no clean and generic scheme for sorting these messages. 456 Therefore, the use of this model is recommended only when all 457 received accounting messages can be clearly identified and sorted. 458 For most cases, the use of Coupled Accounting Model is 459 recommended. 461 Coupled Accounting Model 463 In this model, the accounting messages will use the application ID 464 of the application using the accounting service. The design 465 implication for this is that the accounting messages are tightly 466 coupled with the application itself; meaning that accounting 467 messages will be routed like any other application messages. It 468 would then be the responsibility of the application server 469 (application entity receiving the ACR message) to send the 470 accounting records carried by the accounting messages to the 471 proper accounting server. The application server is also 472 responsible for formulating a proper response (ACA). A coupled 473 accounting model is a good design choice when: 475 * The system architecture or deployment will not provide an 476 accounting server that supports Diameter. 478 * The system architecture or deployment requires that the 479 accounting service for the specific application should be 480 handled by the application itself. 482 * The application server is provisioned to use a different 483 protocol to access the accounting server; e.g., via LDAP, SOAP 484 etc. This includes attempting to support older accounting 485 systems that are not Diameter aware. 487 In all cases above, there will generally be no direct Diameter 488 access to the accounting server. 490 These models provide a basis for using accounting messages. 491 Application designers may obviously deviate from these models 492 provided that the factors being addressed here have also been taken 493 into account. Though it is not recommended, examples of other 494 methods might be defining a new set of commands to carry application 495 specific accounting records. 497 11. Generic Diameter Extensions 499 Generic Diameter extensions are AVPs, commands or applications that 500 are designed to support other Diameter applications. They are 501 auxiliary applications meant to improve or enhance the Diameter 502 protocol itself or Diameter applications/functionality. Some 503 examples include the extensions to support auditing and redundancy 504 (see [I-D.calhoun-diameter-res-mgmt]), improvements in duplicate 505 detection scheme (see [I-D.asveren-dime-dupcons]), and piggybacking 506 of QoS attributes (see [I-D.ietf-dime-qos-attributes]). 508 Since generic extensions can cover many aspects of Diameter and 509 Diameter applications, it is not possible to enumerate all the 510 probable scenarios in this document. However, some of the most 511 common considerations are as follows: 513 o Backward compatibility: Dealing with existing applications that do 514 not understand the new extension. Designers also have to make 515 sure that new extensions do not break expected message delivery 516 layer behavior. 518 o Forward compatibility: Making sure that the design will not 519 introduce undue restrictions for future applications. Future 520 applications attempting to support this feature should not have to 521 go through great lengths to implement any new extensions. 523 o Tradeoffs in signaling: Designers may have to choose between the 524 use of optional AVPs piggybacked onto existing commands versus 525 defining new commands and applications. Optional AVPs are simpler 526 to implement and may not need changes to existing applications; 527 However, the drawback is that the timing of sending extension data 528 will be tied to when the application would be sending a message. 529 This has consequences if the application and the extensions have 530 different timing requirements. The use of commands and 531 applications solves this issue but the tradeoff is the additional 532 complexity of defining and deploying a new application. It is 533 left up to the designer to find a good balance among these 534 tradeoffs based on the requirements of the extension. 536 In practice, it is often the case that the generic extensions use 537 optional AVPs because it's simple and not intrusive to the 538 application that would carry it. Peers that do not support the 539 generic extensions need not understand nor recognize these optional 540 AVPs. However, it is recommended that the authors of the extension 541 specify the context or usage of the optional AVPs. As an example, in 542 the case that the AVP can be used only by a specific set of 543 applications then the specification must enumerate these applications 544 and the scenarios when the optional AVPs will be used. In the case 545 where the optional AVPs can be carried by any application, it is 546 should be sufficient to specify such a use case and perhaps provide 547 specific examples of applications using them. 549 In most cases, these optional AVPs piggybacked by applications would 550 be defined as a Grouped AVP and it would encapsulate all the 551 functionality of the generic extension. In practice, it is not 552 uncommon that the Grouped AVP will encapsulate an existing AVP that 553 has previously been defined as mandatory ('M'-bit set) e.g., 3GPP IMS 554 Cx / Dx interfaces ([TS29.228] and [TS29.229]). 556 12. IANA Considerations 558 This document does not require actions by IANA. 560 13. Security Considerations 562 This document does provides guidelines and considerations for 563 extending Diameter and Diameter applications. It does not define nor 564 address security related protocols or schemes. 566 14. Contributors 568 The content of this document was influenced by a design team created 569 to revisit the Diameter extensibility rules. The team consisting of 570 the members listed below was formed in February 2008 and finished its 571 work in June 2008. 573 o Avi Lior 575 o Glen Zorn 577 o Jari Arkko 579 o Lionel Morand 581 o Mark Jones 583 o Victor Fajardo 585 o Tolga Asveren 587 o Jouni Korhonen 589 o Glenn McGregor 591 o Hannes Tschofenig 593 o Dave Frascone 595 We would like to thank Tolga Asveren, Glenn McGregor, and John 596 Loughney for their contributions as co-authors to earlier versions of 597 this document. 599 15. Acknowledgments 601 We greatly appreciate the insight provided by Diameter implementers 602 who have highlighted the issues and concerns being addressed by this 603 document. 605 16. References 607 16.1. Normative References 609 [I-D.ietf-dime-diameter-qos] 610 Sun, D., McCann, P., Tschofenig, H., ZOU), T., Doria, A., 611 and G. Zorn, "Diameter Quality of Service Application", 612 draft-ietf-dime-diameter-qos-15 (work in progress), 613 March 2010. 615 [I-D.ietf-dime-mip6-integrated] 616 Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., 617 and K. Chowdhury, "Diameter Mobile IPv6: Support for 618 Network Access Server to Diameter Server Interaction", 619 draft-ietf-dime-mip6-integrated-12 (work in progress), 620 January 2009. 622 [I-D.ietf-dime-mip6-split] 623 Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., 624 and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home 625 Agent to Diameter Server Interaction", 626 draft-ietf-dime-mip6-split-17 (work in progress), 627 April 2009. 629 [I-D.ietf-dime-qos-attributes] 630 Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 631 and A. Lior, "Traffic Classification and Quality of 632 Service Attributes for Diameter", 633 draft-ietf-dime-qos-attributes-15 (work in progress), 634 December 2009. 636 [I-D.ietf-dime-rfc3588bis] 637 Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 638 "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-29 639 (work in progress), August 2011. 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, March 1997. 644 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 645 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 647 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 648 Loughney, "Diameter Credit-Control Application", RFC 4006, 649 August 2005. 651 [TS29.228] 652 3rd Generation Partnership Project, "3GPP TS 29.228; 653 Technical Specification Group Core Network and Terminals; 654 IP Multimedia (IM) Subsystem Cx and Dx Interfaces; 655 Signalling flows and message contents", 656 . 658 [TS29.229] 659 3rd Generation Partnership Project, "3GPP TS 29.229; 660 Technical Specification Group Core Network and Terminals; 661 Cx and Dx interfaces based on the Diameter protocol; 662 Protocol details", 663 . 665 [TS29.328] 666 3rd Generation Partnership Project, "3GPP TS 29.328; 667 Technical Specification Group Core Network and Terminals; 668 IP Multimedia (IM) Subsystem Sh interface; signalling 669 flows and message content", 670 . 672 [TS29.329] 673 3rd Generation Partnership Project, "3GPP TS 29.329; 674 Technical Specification Group Core Network and Terminals; 675 Sh Interface based on the Diameter protocol; Protocol 676 details", 677 . 679 16.2. Informative References 681 [I-D.asveren-dime-dupcons] 682 Asveren, T., "Diameter Duplicate Detection Cons.", 683 draft-asveren-dime-dupcons-00 (work in progress), 684 August 2006. 686 [I-D.calhoun-diameter-res-mgmt] 687 Calhoun, P., "Diameter Resource Management Extensions", 688 draft-calhoun-diameter-res-mgmt-08.txt (work in progress), 689 March 2001. 691 Authors' Addresses 693 Victor Fajardo 695 Email: vf0213@gmail.com 697 Hannes Tschofenig 698 Nokia Siemens Networks 699 Linnoitustie 6 700 Espoo 02600 701 Finland 703 Phone: +358 (50) 4871445 704 Email: Hannes.Tschofenig@gmx.net 705 URI: http://www.tschofenig.priv.at 707 Lionel Morand (editor) 708 Orange Labs 710 Phone: +33 1 4529 6257 711 Email: lionel.morand@orange-ftgroup.com