idnits 2.17.1 draft-ietf-dime-extended-naptr-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document updates RFC3588, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3588, updated by this document, for RFC5378 checks: 2001-02-09) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 9, 2011) is 4824 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4006 (Obsoleted by RFC 8506) -- Possible downref: Non-RFC (?) normative reference: ref. 'WiMAX' -- Obsolete informational reference (is this intentional?): RFC 2915 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and M. Jones 3 Extensions (DIME) Bridgewater Systems 4 Internet-Draft J. Korhonen 5 Updates: 3588 (if approved) Nokia Siemens Networks 6 Intended status: Standards Track L. Morand 7 Expires: August 13, 2011 Orange Labs 8 February 9, 2011 10 Diameter S-NAPTR Usage 11 draft-ietf-dime-extended-naptr-05 13 Abstract 15 The Diameter base protocol specifies mechanisms whereby a given realm 16 may advertise Diameter nodes and the supported transport protocol. 17 However, these mechanism do not reveal the Diameter applications that 18 each node supports. A peer outside the realm would have to perform a 19 Diameter capability exchange with every node until it discovers one 20 that supports the required application. This document describes an 21 improvement using an extended format for the Straightfoward-NAPTR 22 (S-NAPTR) Application Service Tag that allows for discovery of the 23 supported applications without doing Diameter capability exchange 24 beforehand. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in [RFC2119]. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on August 13, 2011. 55 Copyright Notice 57 Copyright (c) 2011 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the BSD License. 70 This document may contain material from IETF Documents or IETF 71 Contributions published or made publicly available before November 72 10, 2008. The person(s) controlling the copyright in some of this 73 material may not have granted the IETF Trust the right to allow 74 modifications of such material outside the IETF Standards Process. 75 Without obtaining an adequate license from the person(s) controlling 76 the copyright in such materials, this document may not be modified 77 outside the IETF Standards Process, and derivative works of it may 78 not be created outside the IETF Standards Process, except to format 79 it for publication as an RFC or to translate it into languages other 80 than English. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 85 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 3. Extended NAPTR Service Field Format . . . . . . . . . . . . . 4 87 3.1. IETF Standard Track Diameter Applications . . . . . . . . 5 88 3.2. Vendor-specific Diameter Applications . . . . . . . . . . 5 89 4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 6 90 5. Extended NAPTR-based Diameter Peer Discovery . . . . . . . . . 6 91 6. Usage Guidelines . . . . . . . . . . . . . . . . . . . . . . . 7 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 93 7.1. IETF Diameter Application Service Tags . . . . . . . . . . 8 94 7.2. 3GPP Diameter Application Service Tags . . . . . . . . . . 8 95 7.3. WiMAX Forum Diameter Application Service Tags . . . . . . 9 96 7.4. Vendor-Specific Diameter Application Service Tags . . . . 9 97 7.5. Diameter Application Protocol Tags . . . . . . . . . . . . 10 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 99 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 100 10. Editor's Notes . . . . . . . . . . . . . . . . . . . . . . . . 10 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 102 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 103 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 106 1. Introduction 108 The Diameter base protocol [RFC3588] specifies three mechanisms for 109 the Diameter peer discovery. One of these involves the Diameter 110 implementation performing a NAPTR query [RFC3403] for a server in a 111 particular realm. These NAPTR records provide a mapping from a 112 domain, to the SRV record [RFC2782] or A/AAAA record 113 [RFC1035][RFC3596] for contacting a server with the specific 114 transport protocol in the NAPTR services field. 116 The extended NAPTR usage for Diameter peer discovery defined by this 117 document is based on the Straightfoward-NAPTR (S-NAPTR) Dynamic 118 Delegation Discovery System (DDDS) Application defined in [RFC3958]. 119 This document updates the Diameter peer discovery procedure described 120 in Section 11.6 of [RFC3588] and defines S-NAPTR Application Service 121 and Application Protocol Tag values that permit the discovery of 122 Diameter peers that support a specific Diameter application and 123 transport protocol. 125 2. Terminology 127 The Diameter base protocol specification (Section 1.4 of [RFC3588]) 128 and the Straightforward-NAPTR (S-NAPTR) DDDS application (section 2.1 129 in [RFC3958]) define the terminology used in this document. 131 3. Extended NAPTR Service Field Format 133 The NAPTR Service Field format defined by the S-NAPTR DDDS 134 application in [RFC3958] follows this ABNF: 136 service-parms = [ [app-service] *(":" app-protocol)] 137 app-service = experimental-service / iana-registered-service 138 app-protocol = experimental-protocol / iana-registered-protocol 139 experimental-service = "x-" 1*30ALPHANUMSYM 140 experimental-protocol = "x-" 1*30ALPHANUMSYM 141 iana-registered-service = ALPHA *31ALPHANUMSYM 142 iana-registered-protocol = ALPHA *31ALPHANUMSYM 143 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 144 DIGIT = %x30-39 ; 0-9 145 SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." 146 ALPHANUMSYM = ALPHA / DIGIT / SYM 147 ; The app-service and app-protocol tags are limited to 32 148 ; characters and must start with an alphabetic character. 149 ; The service-parms are considered case-insensitive. 151 This specification refines the "iana-registered-service" tag 152 definition for the discovery of Diameter agents supporting a specific 153 Diameter application as defined below. 155 iana-registered-service = aaa-service / ALPHA *31ALPHANUMSYM 156 aaa-service = "aaa+ap" appln-id 157 appln-id = *DIGIT 158 ; Application identifier expressed as a 159 ; decimal integer. 161 This specification also refines the "iana-registered-protocol" tag 162 definition for the discovery of Diameter agents supporting a specific 163 Diameter transport protocol as defined below. 165 iana-registered-protocol = aaa-protocol / ALPHA *31ALPHANUMSYM 166 aaa-protocol = "diameter." aaa-transport 167 aaa-transport = "tcp" / "sctp" / "tls.tcp" 169 The maximum length of the NAPTR service field is 256 octets including 170 one octet length field (see Section 4.1 of RFC 3403 and Section 3.3 171 of [RFC1035]). 173 3.1. IETF Standard Track Diameter Applications 175 A Diameter agent MUST be capable of using the extended S-NAPTR 176 Application Service Tag for dynamic discovery of a Diameter agent 177 supporting Standard Track applications. Therefore, every IETF 178 Standard Track Diameter application MUST be associated with a "aaa- 179 service" tag formatted as defined in this specification and allocated 180 in accordance with the IANA policy (see Section 7). 182 For example, a NAPTR service field value of: 184 'aaa+ap6:diameter.sctp' 186 Means that the Diameter node in the SRV or A/AAAA record supports 187 the Diameter Session Initiation Protocol (SIP) Application ('6') 188 and SCTP as the transport protocol. 190 3.2. Vendor-specific Diameter Applications 192 S-NAPTR Application Service and Application Protocol Tag values can 193 also be used to discover Diameter peers that support a vendor- 194 specific Diameter application. In this case, the vendor-specific 195 Diameter application MUST be associated with a "aaa-service" tag 196 formatted as defined in this specification and allocated in 197 accordance with the IANA policy (see Section 7). 199 For example, a NAPTR service field value of: 201 'aaa+ap16777251:diameter.sctp' 203 Means that the Diameter node in the SRV or A/AAAA record supports 204 the Diameter 3GPP S6a Application ('16777251') and SCTP as the 205 transport protocol. 207 4. Backwards Compatibility 209 DNS administrators SHOULD also provision legacy RFC 3588 style NAPTR 210 records [RFC2915] in order to guarantee backwards compatibility with 211 legacy RFC 3588 compliant Diameter peers. If the DNS administrator 212 provisions both extended S-NAPTR records as defined in this 213 specification and legacy RFC 3588 NAPTR records, then the extended 214 S-NAPTR records MUST have higher priority (e.g. lower order and/or 215 preference values) than legacy NAPTR records. 217 5. Extended NAPTR-based Diameter Peer Discovery 219 The Diameter Peer Discovery principles are described in Section 5.2 220 of [RFC3588]. This specification updates the NAPTR query procedure 221 in the Diameter peer discovery mechanism by allowing the querying 222 node to determine which applications are supported by resolved 223 Diameter peers. 225 The extended format NAPTR records provide a mapping from a domain to 226 the SRV record or A/AAAA record for contacting a server supporting a 227 specific transport protocol and Diameter application. The resource 228 record will contain an empty regular expression and a replacement 229 value, which is the SRV record or the A/AAAA record for that 230 particular transport protocol. If the server supports multiple 231 transport protocols, there will be multiple NAPTR records, each with 232 a different Services Field value and potentially different list of 233 supported Diameter applications. 235 The assumption for this mechanism to work is that the DNS 236 administrator of the queried domain has first provisioned the DNS 237 with extended format NAPTR entries. The steps below replace the 238 NAPTR query procedure steps in Section 5.2 of [RFC3588]. 240 a. The Diameter implementation performs a NAPTR query for a server in 241 a particular realm. The Diameter implementation has to know in 242 advance which realm to look for a Diameter agent in and which 243 Application Identifier it is interested in. For example, the 244 realm could be deduced from the NAI in the User-Name AVP or 245 extracted from the Destination-Realm AVP. 247 b. If the returned NAPTR service fields contain entries formatted as 248 "aaa+apX:Y" where "X" indicates the Application Identifier and "Y" 249 indicates the transport protocol, the target realm supports the 250 extended format for NAPTR-based Diameter peer discovery defined in 251 this document. 253 If "X" contains the required Application Identifier and "Y" 254 matches a supported transport protocol, the Diameter 255 implementation resolves the "replacement" field entry to a 256 target host using the lookup method appropriate for the "flags" 257 field. 259 If "X" does not contain the required Application Identifier or 260 "Y" does not match a supported transport protocol, the Diameter 261 implementation abandons the peer discovery. 263 c. If the returned NAPTR service fields contain entries formatted as 264 "AAA+D2X" where "X" indicates the transport protocol, the target 265 realm supports the NAPTR-based Diameter peer discovery defined in 266 [RFC3588]. 268 If "X" matches a supported transport protocol, the Diameter 269 implementation continues processing the NAPTR as described in 270 [RFC3588] and [RFC2915]. 272 If "X" does not match a supported transport protocol, the 273 Diameter implementation abandons the peer discovery. 275 d. If the target realm does not support NAPTR-based Diameter peer 276 discovery, the client proceeds with the next peer discovery 277 mechanism described in Section 5.2 of [RFC3588]. 279 6. Usage Guidelines 281 Diameter is a peer to peer protocol whereas most of the applications 282 that extend the base protocol behave like client/server applications. 283 The role of the peer is not advertised in the NAPTR tags and not even 284 communicated during Diameter capability negotiation (CER/CEA). For 285 this reason, NAPTR-based Diameter peer discovery for an application 286 defining client/server roles should only be used by a client to 287 discover servers. 289 7. IANA Considerations 290 7.1. IETF Diameter Application Service Tags 292 IANA is requested to reserve a value of "aaa" for Diameter in the 293 S-NAPTR Application Service Tag registry created by [RFC3958]. IANA 294 is also requested to reserve the following S-NAPTR Application 295 Service Tags for existing IETF Diameter applications in the same 296 registry. 298 +------------------+----------------------------+ 299 | Tag | Diameter Application | 300 +------------------+----------------------------+ 301 | aaa+ap1 | NASREQ [RFC3588] | 302 | aaa+ap2 | Mobile IPv4 [RFC4004] | 303 | aaa+ap3 | Base Accounting [RFC3588] | 304 | aaa+ap4 | Credit Control [RFC4006] | 305 | aaa+ap5 | EAP [RFC4072] | 306 | aaa+ap6 | SIP [RFC4740] | 307 | aaa+ap7 | Mobile IPv6 IKE [RFC5778] | 308 | aaa+ap8 | Mobile IPv6 Auth [RFC5778] | 309 | aaa+ap9 | QoS [RFC5866] | 310 | aaa+ap4294967295 | Relay [RFC3588] | 311 +------------------+----------------------------+ 313 Future IETF Diameter applications MUST reserve the S-NAPTR 314 Application Service Tag corresponding to the allocated Diameter 315 Application ID as defined in Section 3. 317 7.2. 3GPP Diameter Application Service Tags 319 IANA is requested to reserve the following S-NAPTR Application 320 Service Tags for existing 3GPP Diameter applications in the S-NAPTR 321 Application Service Tag registry created by [RFC3958]. 323 +----------------+----------------------+ 324 | Tag | Diameter Application | 325 +----------------+----------------------+ 326 | aaa+ap16777250 | 3GPP STa [TS29.273] | 327 | aaa+ap16777251 | 3GPP S6a [TS29.272] | 328 | aaa+ap16777264 | 3GPP SWm [TS29.273] | 329 | aaa+ap16777267 | 3GPP S9 [TS29.215] | 330 +----------------+----------------------+ 332 Future 3GPP Diameter applications can reserve entries in the S-NAPTR 333 Application Service Tag registry created by [RFC3958] which 334 correspond to the allocated Diameter Application IDs as defined in 335 Section 3. 337 7.3. WiMAX Forum Diameter Application Service Tags 339 IANA is requested to reserve the following S-NAPTR Application 340 Service Tags for existing WiMAX Forum Diameter applications in the 341 S-NAPTR Application Service Tag registry created by [RFC3958]. 343 +----------------+--------------------------------------------------+ 344 | Tag | Diameter Application | 345 +----------------+--------------------------------------------------+ 346 | aaa+ap16777281 | WiMAX Network Access Authentication and | 347 | | Authorization Diameter Application (WNAAADA) | 348 | | [WiMAX] | 349 | aaa+ap16777282 | WiMAX Network Accounting Diameter Application | 350 | | (WNADA) [WiMAX] | 351 | aaa+ap16777283 | WiMAX MIP4 Diameter Application (WM4DA) [WiMAX] | 352 | aaa+ap16777284 | WiMAX MIP6 Diameter Application (WM6DA) [WiMAX] | 353 | aaa+ap16777285 | WiMAX DHCP Diameter Application (WDDA) [WiMAX] | 354 | aaa+ap16777286 | WiMAX Location Authentication Authorization | 355 | | Diameter Application (WLAADA) [WiMAX] | 356 | aaa+ap16777287 | WiMAX Policy and Charging Control R3 Policies | 357 | | Diameter Application (WiMAX PCC-R3-P) [WiMAX] | 358 | aaa+ap16777288 | WiMAX Policy and Charging Control R3 Offline | 359 | | Charging Diameter Application (WiMAX PCC-R3-OFC) | 360 | | [WiMAX] | 361 | aaa+ap16777289 | WiMAX Policy and Charging Control R3 Offline | 362 | | Charging Prime Diameter Application (WiMAX | 363 | | PCC-R3-OFC-PRIME) [WiMAX] | 364 | aaa+ap16777290 | WiMAX Policy and Charging Control R3 Online | 365 | | Charging Diameter Application (WiMAX PCC-R3-OC) | 366 | | [WiMAX] | 367 +----------------+--------------------------------------------------+ 369 Future WiMAX Forum Diameter applications can reserve entries in the 370 S-NAPTR Application Service Tag registry created by [RFC3958] which 371 correspond to the allocated Diameter Application IDs as defined in 372 Section 3. 374 7.4. Vendor-Specific Diameter Application Service Tags 376 Vendor-Specific Diameter Application IDs are allocated by IANA 377 according to the "First Come First Served" policy and do not require 378 an IETF specification. However, the S-NAPTR Application Service Tag 379 registry created by [RFC3958] defines a registration policy of 380 "Specification Required" with a further stipulation that the 381 "specification" is an RFC (of any category). If a Vendor-Specific 382 Diameter Application requires the functionality defined in this 383 document, an RFC of any category MUST be published which reserves the 384 S-NAPTR Application Service Tag corresponding to the Vendor-Specific 385 Diameter Application ID as defined in Section 3. 387 7.5. Diameter Application Protocol Tags 389 IANA is requested to reserve the following S-NAPTR Application 390 Protocol Tags for the Diameter transport protocols in the S-NAPTR 391 Application Protocol Tag registry created by [RFC3958]. 393 +------------------+----------+ 394 | Tag | Protocol | 395 +------------------+----------+ 396 | diameter.tcp | TCP | 397 | diameter.sctp | SCTP | 398 | diameter.tls.tcp | TLS/TCP | 399 +------------------+----------+ 401 8. Security Considerations 403 This document specifies an enhancement to RFC 3588 Diameter base 404 protocol defined NAPTR service field format and also modifications to 405 the NAPTR processing logic defined. The enhancements and 406 modifications are based on the S-NAPTR, which is actually a 407 simplification of the NAPTR, and therefore the same security 408 considerations described in RFC 3588 are applicable to this document. 409 No further extensions are required beyond the security mechanisms 410 offered by RFC 3588. However, a malicious host doing S-NAPTR queries 411 learns applications supported by Diameter agents in a certain realm 412 faster, which might help the malicious host to scan potential targets 413 for an attack more efficiently when some applications have known 414 vulnerabilities. 416 9. Acknowledgments 418 We would like to thank Glen Zorn, Avi Lior, Itsuma Tanaka, Lionel 419 Morand and Sebastien Decugis for their comprehensive review comments. 421 10. Editor's Notes 423 This section to be removed prior to publication. 425 This draft updates sections of RFC3588 that are also being updated by 426 RFC3588bis. At the time this draft was started, it was uncertain 427 whether RFC3588bis would be published first. The authors of this 428 draft decided to proceed optimistically assuming this draft would be 429 published first with the understanding that minor updates are 430 required if this is not the case. 432 The application-neutral aspects of Diameter S-NAPTR usage (e.g "aaa: 433 diameter.sctp") were also contributed to RFC3588bis to ensure that it 434 would be functionally complete if it got published first and this 435 draft would come along later to add the application-specific S-NAPTR 436 entries (e.g."aaa+ap5:diameter.sctp"). 438 Depending on the publication order, the S-NAPTR Application Service 439 Tag registry value of "aaa" and the S-NAPTR Application Protocol Tags 440 values ("diameter.tcp"/"diameter.sctp"/"diameter.tls.tcp") will need 441 to be removed either from this draft or RFC3588bis. 443 11. References 445 11.1. Normative References 447 [RFC1035] Mockapetris, P., "Domain names - implementation and 448 specification", STD 13, RFC 1035, November 1987. 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, March 1997. 453 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 454 specifying the location of services (DNS SRV)", RFC 2782, 455 February 2000. 457 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 458 Part Three: The Domain Name System (DNS) Database", 459 RFC 3403, October 2002. 461 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 462 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 464 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 465 "DNS Extensions to Support IP Version 6", RFC 3596, 466 October 2003. 468 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 469 Service Location Using SRV RRs and the Dynamic Delegation 470 Discovery Service (DDDS)", RFC 3958, January 2005. 472 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and 473 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, 474 August 2005. 476 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 478 Loughney, "Diameter Credit-Control Application", RFC 4006, 479 August 2005. 481 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 482 Authentication Protocol (EAP) Application", RFC 4072, 483 August 2005. 485 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., 486 Canales-Valenzuela, C., and K. Tammi, "Diameter Session 487 Initiation Protocol (SIP) Application", RFC 4740, 488 November 2006. 490 [RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., 491 and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home 492 Agent to Diameter Server Interaction", RFC 5778, 493 February 2010. 495 [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., 496 and G. Zorn, "Diameter Quality-of-Service Application", 497 RFC 5866, May 2010. 499 [TS29.215] 500 3rd Generation Partnership Project, "3GPP TS 29.215; 501 Technical Specification Group Core Network and Terminals; 502 Policy and Charging Control (PCC) over S9 reference point; 503 Stage 3 (Release 8)", 504 http://www.3gpp.org/ftp/Specs/html-info/29215.htm. 506 [TS29.272] 507 3rd Generation Partnership Project, "3GPP TS 29.272; 508 Technical Specification Group Core Network and Terminals; 509 Evolved Packet System; Mobility Management Entity (MME) 510 and Serving GPRS Support Node (SGSN) Related Interfaces 511 Based on Diameter Protocol (Release 8)", 512 http://www.3gpp.org/ftp/Specs/html-info/29272.htm. 514 [TS29.273] 515 3rd Generation Partnership Project, "3GPP TS 29.273; 516 Technical Specification Group Core Network and Terminals; 517 Evolved Packet System; 3GPP EPS AAA interfaces (Release 518 8)", http://www.3gpp.org/ftp/Specs/html-info/29273.htm. 520 [WiMAX] WiMAX Forum, "WiMAX Release 1.5", http:// 521 www.wimaxforum.org/resources/documents/technical/T33. 523 11.2. Informative References 525 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 526 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 528 Authors' Addresses 530 Mark Jones 531 Bridgewater Systems 533 Email: mark@azu.ca 535 Jouni Korhonen 536 Nokia Siemens Networks 538 Email: jouni.nospam@gmail.com 540 Lionel Morand 541 Orange Labs 543 Email: lionel.morand@orange-ftgroup.com