idnits 2.17.1 draft-ietf-dime-extended-naptr-04.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 (January 6, 2011) is 4852 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: July 10, 2011 Orange Labs 8 January 6, 2011 10 Diameter Extended NAPTR 11 draft-ietf-dime-extended-naptr-04 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 July 10, 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 101 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 102 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 105 1. Introduction 107 The Diameter base protocol [RFC3588] specifies three mechanisms for 108 the Diameter peer discovery. One of these involves the Diameter 109 implementation performing a NAPTR query [RFC3403] for a server in a 110 particular realm. These NAPTR records provide a mapping from a 111 domain, to the SRV record [RFC2782] or A/AAAA record 112 [RFC1035][RFC3596] for contacting a server with the specific 113 transport protocol in the NAPTR services field. 115 The extended NAPTR usage for Diameter peer discovery defined by this 116 document is based on the Straightfoward-NAPTR (S-NAPTR) Dynamic 117 Delegation Discovery System (DDDS) Application defined in [RFC3958]. 118 This document updates the Diameter peer discovery procedure described 119 in Section 11.6 of [RFC3588] and defines S-NAPTR Application Service 120 and Application Protocol Tag values that permit the discovery of 121 Diameter peers that support a specific Diameter application and 122 transport protocol. 124 2. Terminology 126 The Diameter base protocol specification (Section 1.4 of [RFC3588]) 127 and the Straightforward-NAPTR (S-NAPTR) DDDS application (section 2.1 128 in [RFC3958]) define the terminology used in this document. 130 3. Extended NAPTR Service Field Format 132 The NAPTR Service Field format defined by the S-NAPTR DDDS 133 application in [RFC3958] follows this ABNF: 135 service-parms = [ [app-service] *(":" app-protocol)] 136 app-service = experimental-service / iana-registered-service 137 app-protocol = experimental-protocol / iana-registered-protocol 138 experimental-service = "x-" 1*30ALPHANUMSYM 139 experimental-protocol = "x-" 1*30ALPHANUMSYM 140 iana-registered-service = ALPHA *31ALPHANUMSYM 141 iana-registered-protocol = ALPHA *31ALPHANUMSYM 142 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 143 DIGIT = %x30-39 ; 0-9 144 SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." 145 ALPHANUMSYM = ALPHA / DIGIT / SYM 146 ; The app-service and app-protocol tags are limited to 32 147 ; characters and must start with an alphabetic character. 148 ; The service-parms are considered case-insensitive. 150 This specification refines the "iana-registered-service" tag 151 definition for the discovery of Diameter agents supporting a specific 152 Diameter application as defined below. 154 iana-registered-service = aaa-service / ALPHA *31ALPHANUMSYM 155 aaa-service = "aaa+ap" appln-id 156 appln-id = *DIGIT 157 ; Application identifier expressed as a 158 ; decimal integer. 160 This specification also refines the "iana-registered-protocol" tag 161 definition for the discovery of Diameter agents supporting a specific 162 Diameter transport protocol as defined below. 164 iana-registered-protocol = aaa-protocol / ALPHA *31ALPHANUMSYM 165 aaa-protocol = "diameter." aaa-transport 166 aaa-transport = "tcp" / "sctp" / "tls.tcp" 168 The maximum length of the NAPTR service field is 256 octets including 169 one octet length field (see Section 4.1 of RFC 3403 and Section 3.3 170 of [RFC1035]). 172 3.1. IETF Standard Track Diameter Applications 174 A Diameter agent MUST be capable of using the extended S-NAPTR 175 Application Service Tag for dynamic discovery of a Diameter agent 176 supporting Standard Track applications. Therefore, every IETF 177 Standard Track Diameter application MUST be associated with a "aaa- 178 service" tag formatted as defined in this specification and allocated 179 in accordance with the IANA policy (see Section 7). 181 For example, a NAPTR service field value of: 183 'aaa+ap6:diameter.sctp' 185 Means that the Diameter node in the SRV or A/AAAA record supports 186 the Diameter Session Initiation Protocol (SIP) Application ('6') 187 and SCTP as the transport protocol. 189 3.2. Vendor-specific Diameter Applications 191 S-NAPTR Application Service and Application Protocol Tag values can 192 also be used to discover Diameter peers that support a vendor- 193 specific Diameter application. In this case, the vendor-specific 194 Diameter application MUST be associated with a "aaa-service" tag 195 formatted as defined in this specification and allocated in 196 accordance with the IANA policy (see Section 7). 198 For example, a NAPTR service field value of: 200 'aaa+ap16777251:diameter.sctp' 202 Means that the Diameter node in the SRV or A/AAAA record supports 203 the Diameter 3GPP S6a Application ('16777251') and SCTP as the 204 transport protocol. 206 4. Backwards Compatibility 208 DNS administrators SHOULD also provision legacy RFC 3588 style NAPTR 209 records [RFC2915] in order to guarantee backwards compatibility with 210 legacy RFC 3588 compliant Diameter peers. If the DNS administrator 211 provisions both extended S-NAPTR records as defined in this 212 specification and legacy RFC 3588 NAPTR records, then the extended 213 S-NAPTR records MUST have higher priority (e.g. lower order and/or 214 preference values) than legacy NAPTR records. 216 5. Extended NAPTR-based Diameter Peer Discovery 218 The Diameter Peer Discovery principles are described in Section 5.2 219 of [RFC3588]. This specification updates the NAPTR query procedure 220 in the Diameter peer discovery mechanism by allowing the querying 221 node to determine which applications are supported by resolved 222 Diameter peers. 224 The extended format NAPTR records provide a mapping from a domain to 225 the SRV record or A/AAAA record for contacting a server supporting a 226 specific transport protocol and Diameter application. The resource 227 record will contain an empty regular expression and a replacement 228 value, which is the SRV record or the A/AAAA record for that 229 particular transport protocol. If the server supports multiple 230 transport protocols, there will be multiple NAPTR records, each with 231 a different Services Field value and potentially different list of 232 supported Diameter applications. 234 The assumption for this mechanism to work is that the DNS 235 administrator of the queried domain has first provisioned the DNS 236 with extended format NAPTR entries. The steps below replace the 237 NAPTR query procedure steps in Section 5.2 of [RFC3588]. 239 a. The Diameter implementation performs a NAPTR query for a server in 240 a particular realm. The Diameter implementation has to know in 241 advance which realm to look for a Diameter agent in and which 242 Application Identifier it is interested in. For example, the 243 realm could be deduced from the NAI in the User-Name AVP or 244 extracted from the Destination-Realm AVP. 246 b. If the returned NAPTR service fields contain entries formatted as 247 "aaa+apX:Y" where "X" indicates the Application Identifier and "Y" 248 indicates the transport protocol, the target realm supports the 249 extended format for NAPTR-based Diameter peer discovery defined in 250 this document. 252 If "X" contains the required Application Identifier and "Y" 253 matches a supported transport protocol, the Diameter 254 implementation resolves the "replacement" field entry to a 255 target host using the lookup method appropriate for the "flags" 256 field. 258 If "X" does not contain the required Application Identifier or 259 "Y" does not match a supported transport protocol, the Diameter 260 implementation abandons the peer discovery. 262 c. If the returned NAPTR service fields contain entries formatted as 263 "AAA+D2X" where "X" indicates the transport protocol, the target 264 realm supports the NAPTR-based Diameter peer discovery defined in 265 [RFC3588]. 267 If "X" matches a supported transport protocol, the Diameter 268 implementation continues processing the NAPTR as described in 269 [RFC3588] and [RFC2915]. 271 If "X" does not match a supported transport protocol, the 272 Diameter implementation abandons the peer discovery. 274 d. If the target realm does not support NAPTR-based Diameter peer 275 discovery, the client proceeds with the next peer discovery 276 mechanism described in Section 5.2 of [RFC3588]. 278 6. Usage Guidelines 280 Diameter is a peer to peer protocol whereas most of the applications 281 that extend the base protocol behave like client/server applications. 282 The role of the peer is not advertised in the NAPTR tags and not even 283 communicated during Diameter capability negotiation (CER/CEA). For 284 this reason, NAPTR-based Diameter peer discovery for an application 285 defining client/server roles should only be used by a client to 286 discover servers. 288 7. IANA Considerations 289 7.1. IETF Diameter Application Service Tags 291 IANA is requested to reserve the following S-NAPTR Application 292 Service Tags for existing IETF Diameter applications in the S-NAPTR 293 Application Service Tag registry created by [RFC3958]. 295 +------------------+----------------------------+ 296 | Tag | Diameter Application | 297 +------------------+----------------------------+ 298 | aaa+ap1 | NASREQ [RFC3588] | 299 | aaa+ap2 | Mobile IPv4 [RFC4004] | 300 | aaa+ap3 | Base Accounting [RFC3588] | 301 | aaa+ap4 | Credit Control [RFC4006] | 302 | aaa+ap5 | EAP [RFC4072] | 303 | aaa+ap6 | SIP [RFC4740] | 304 | aaa+ap7 | Mobile IPv6 IKE [RFC5778] | 305 | aaa+ap8 | Mobile IPv6 Auth [RFC5778] | 306 | aaa+ap9 | QoS [RFC5866] | 307 | aaa+ap4294967295 | Relay [RFC3588] | 308 +------------------+----------------------------+ 310 Future IETF Diameter applications MUST reserve the S-NAPTR 311 Application Service Tag corresponding to the allocated Diameter 312 Application ID as defined in Section 3. 314 7.2. 3GPP Diameter Application Service Tags 316 IANA is requested to reserve the following S-NAPTR Application 317 Service Tags for existing 3GPP Diameter applications in the S-NAPTR 318 Application Service Tag registry created by [RFC3958]. 320 +----------------+----------------------+ 321 | Tag | Diameter Application | 322 +----------------+----------------------+ 323 | aaa+ap16777250 | 3GPP STa [TS29.273] | 324 | aaa+ap16777251 | 3GPP S6a [TS29.272] | 325 | aaa+ap16777264 | 3GPP SWm [TS29.273] | 326 | aaa+ap16777267 | 3GPP S9 [TS29.215] | 327 +----------------+----------------------+ 329 Future 3GPP Diameter applications can reserve entries in the S-NAPTR 330 Application Service Tag registry created by [RFC3958] which 331 correspond to the allocated Diameter Application IDs as defined in 332 Section 3. 334 7.3. WiMAX Forum Diameter Application Service Tags 336 IANA is requested to reserve the following S-NAPTR Application 337 Service Tags for existing WiMAX Forum Diameter applications in the 338 S-NAPTR Application Service Tag registry created by [RFC3958]. 340 +----------------+--------------------------------------------------+ 341 | Tag | Diameter Application | 342 +----------------+--------------------------------------------------+ 343 | aaa+ap16777281 | WiMAX Network Access Authentication and | 344 | | Authorization Diameter Application (WNAAADA) | 345 | | [WiMAX] | 346 | aaa+ap16777282 | WiMAX Network Accounting Diameter Application | 347 | | (WNADA) [WiMAX] | 348 | aaa+ap16777283 | WiMAX MIP4 Diameter Application (WM4DA) [WiMAX] | 349 | aaa+ap16777284 | WiMAX MIP6 Diameter Application (WM6DA) [WiMAX] | 350 | aaa+ap16777285 | WiMAX DHCP Diameter Application (WDDA) [WiMAX] | 351 | aaa+ap16777286 | WiMAX Location Authentication Authorization | 352 | | Diameter Application (WLAADA) [WiMAX] | 353 | aaa+ap16777287 | WiMAX Policy and Charging Control R3 Policies | 354 | | Diameter Application (WiMAX PCC-R3-P) [WiMAX] | 355 | aaa+ap16777288 | WiMAX Policy and Charging Control R3 Offline | 356 | | Charging Diameter Application (WiMAX PCC-R3-OFC) | 357 | | [WiMAX] | 358 | aaa+ap16777289 | WiMAX Policy and Charging Control R3 Offline | 359 | | Charging Prime Diameter Application (WiMAX | 360 | | PCC-R3-OFC-PRIME) [WiMAX] | 361 | aaa+ap16777290 | WiMAX Policy and Charging Control R3 Online | 362 | | Charging Diameter Application (WiMAX PCC-R3-OC) | 363 | | [WiMAX] | 364 +----------------+--------------------------------------------------+ 366 Future WiMAX Forum Diameter applications can reserve entries in the 367 S-NAPTR Application Service Tag registry created by [RFC3958] which 368 correspond to the allocated Diameter Application IDs as defined in 369 Section 3. 371 7.4. Vendor-Specific Diameter Application Service Tags 373 Vendor-Specific Diameter Application IDs are allocated by IANA 374 according to the "First Come First Served" policy and do not require 375 an IETF specification. However, the S-NAPTR Application Service Tag 376 registry created by [RFC3958] defines a registration policy of 377 "Specification Required" with a further stipulation that the 378 "specification" is an RFC (of any category). If a Vendor-Specific 379 Diameter Application requires the functionality defined in this 380 document, an RFC of any category MUST be published which reserves the 381 S-NAPTR Application Service Tag corresponding to the Vendor-Specific 382 Diameter Application ID as defined in Section 3. 384 7.5. Diameter Application Protocol Tags 386 IANA is requested to reserve the following S-NAPTR Application 387 Protocol Tags for the Diameter transport protocols in the S-NAPTR 388 Application Protocol Tag registry created by [RFC3958]. 390 +------------------+----------+ 391 | Tag | Protocol | 392 +------------------+----------+ 393 | diameter.tcp | TCP | 394 | diameter.sctp | SCTP | 395 | diameter.tls.tcp | TLS/TCP | 396 +------------------+----------+ 398 8. Security Considerations 400 This document specifies an enhancement to RFC 3588 Diameter base 401 protocol defined NAPTR service field format and also modifications to 402 the NAPTR processing logic defined. The enhancements and 403 modifications are based on the S-NAPTR, which is actually a 404 simplification of the NAPTR, and therefore the same security 405 considerations described in RFC 3588 are applicable to this document. 406 No further extensions are required beyond the security mechanisms 407 offered by RFC 3588. However, a malicious host doing S-NAPTR queries 408 learns applications supported by Diameter agents in a certain realm 409 faster, which might help the malicious host to scan potential targets 410 for an attack more efficiently when some applications have known 411 vulnerabilities. 413 9. Acknowledgments 415 We would like to thank Avi Lior, Itsuma Tanaka and Lionel Morand for 416 their comprehensive review comments. 418 10. References 420 10.1. Normative References 422 [RFC1035] Mockapetris, P., "Domain names - implementation and 423 specification", STD 13, RFC 1035, November 1987. 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, March 1997. 428 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 429 specifying the location of services (DNS SRV)", RFC 2782, 430 February 2000. 432 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 433 Part Three: The Domain Name System (DNS) Database", 434 RFC 3403, October 2002. 436 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 437 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 439 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 440 "DNS Extensions to Support IP Version 6", RFC 3596, 441 October 2003. 443 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 444 Service Location Using SRV RRs and the Dynamic Delegation 445 Discovery Service (DDDS)", RFC 3958, January 2005. 447 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and 448 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, 449 August 2005. 451 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 452 Loughney, "Diameter Credit-Control Application", RFC 4006, 453 August 2005. 455 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 456 Authentication Protocol (EAP) Application", RFC 4072, 457 August 2005. 459 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., 460 Canales-Valenzuela, C., and K. Tammi, "Diameter Session 461 Initiation Protocol (SIP) Application", RFC 4740, 462 November 2006. 464 [RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., 465 and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home 466 Agent to Diameter Server Interaction", RFC 5778, 467 February 2010. 469 [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., 470 and G. Zorn, "Diameter Quality-of-Service Application", 471 RFC 5866, May 2010. 473 [TS29.215] 474 3rd Generation Partnership Project, "3GPP TS 29.215; 475 Technical Specification Group Core Network and Terminals; 476 Policy and Charging Control (PCC) over S9 reference point; 477 Stage 3 (Release 8)", 478 http://www.3gpp.org/ftp/Specs/html-info/29215.htm. 480 [TS29.272] 481 3rd Generation Partnership Project, "3GPP TS 29.272; 482 Technical Specification Group Core Network and Terminals; 483 Evolved Packet System; Mobility Management Entity (MME) 484 and Serving GPRS Support Node (SGSN) Related Interfaces 485 Based on Diameter Protocol (Release 8)", 486 http://www.3gpp.org/ftp/Specs/html-info/29272.htm. 488 [TS29.273] 489 3rd Generation Partnership Project, "3GPP TS 29.273; 490 Technical Specification Group Core Network and Terminals; 491 Evolved Packet System; 3GPP EPS AAA interfaces (Release 492 8)", http://www.3gpp.org/ftp/Specs/html-info/29273.htm. 494 [WiMAX] WiMAX Forum, "WiMAX Release 1.5", http:// 495 www.wimaxforum.org/resources/documents/technical/T33. 497 10.2. Informative References 499 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 500 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 502 Authors' Addresses 504 Mark Jones 505 Bridgewater Systems 507 Email: mark@azu.ca 509 Jouni Korhonen 510 Nokia Siemens Networks 512 Email: jouni.nospam@gmail.com 514 Lionel Morand 515 Orange Labs 517 Email: lionel.morand@orange-ftgroup.com