idnits 2.17.1 draft-ietf-enum-pstn-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 519. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 525. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (August 2006) is 6462 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) == Unused Reference: '9' is defined on line 455, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 466, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 478, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3761 (ref. '1') (Obsoleted by RFC 6116, RFC 6117) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 3401 (ref. '5') == Outdated reference: A later version (-11) exists of draft-ietf-iptel-tel-np-10 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM Working Group J. Livingood 3 Internet-Draft Comcast Cable Communications 4 Expires: February 7, 2007 R. Shockey 5 NeuStar 6 August 2006 8 IANA Registration for an Enumservice 9 Containing PSTN Signaling Information 10 draft-ietf-enum-pstn-05 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 4, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document registers the Enumservice type "pstn" and subtype "tel" 43 using the URI scheme 'tel', as well as the subtype " sip" using the 44 URI scheme 'sip' as per the IANA registration process defined in the 45 ENUM specification, RFC 3761. This Enumservice is used to facilitate 46 the routing of telephone calls in those countries where Number 47 Portability exists. 49 Table of Contents 51 1. Terminology....................................................2 52 2. Introduction...................................................2 53 3. Distribution of Data...........................................4 54 4. ENUM Service Registration for PSTN.............................4 55 4.1 ENUM Service Registration for PSTN with Subtype "tel"......4 56 4.2 ENUM Service Registration for PSTN with Subtype "sip"......5 57 5. Examples.......................................................6 58 5.1 Example of a Ported Number, Using a 'tel' URI Scheme.......6 59 5.2 Example of a Ported Number, Using a 'sip' URI Scheme.......6 60 5.3 Example of a Non-Ported Number, Using a 'tel' URI Scheme...6 61 5.4 Example of a Non-Ported Number, Using a 'sip' URI Scheme...6 62 5.5 Example Using a Regular Expression.........................7 63 6. Implementation Recommendations.................................7 64 6.1 Call Processing When Multiple Records Are Returned.........7 65 6.2 NAPTR Configuration issues.................................7 66 7. Example of E2U+pstn in Call Processing.........................8 67 7.1 Dialed Number Not Available On-Net.........................8 68 7.2 Dialed Number Available On-Net and on the PSTN.............8 69 8. Security Considerations........................................8 70 9. IANA Considerations............................................9 71 10. Acknowledgements..............................................9 72 11. References...................................................10 73 11.1 Normative References.....................................10 74 11.2 Informative References...................................10 75 Authors' Addresses...............................................11 76 Intellectual Property and Copyright Statements...................11 78 1. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in BCP 14, RFC-2119 [1]. 84 2. Introduction 86 ENUM (E.164 Number Mapping, RFC 3761 [1]) is a technology that 87 transforms E.164 numbers (The International Public Telecommunication 88 Numbering Plan, ITU-T Recommendation E.164 [2]) into domain names and 89 then uses DNS (Domain Name System, RFC 1034 [3]) delegation through 90 NS records and NAPTR records (Dynamic Delegation Discovery System 91 (DDDS) Part Three: The Domain Name System (DNS) Database, RFC 3403 92 [4]) to look up what services are available for a specific domain 93 name. 95 This document registers Enumservices according to the guidelines 96 given in RFC 3761 [1] to be used for provisioning in the services 97 field of a NAPTR [4] resource record to indicate the types of 98 functionality associated with an end point and/or telephone number. 99 The registration is defined within the DDDS (Dynamic Delegation 100 Discovery System [4][5][6][7][8]) hierarchy, for use with the "E2U" 101 DDDS Application defined in RFC 3761. 103 Number Portability allows telephone subscribers to keep their 104 telephone numbers when they change service provider, move to a new 105 location, or change the subscribed services [15]. In many countries, 106 such as the United States and Canada, the functions of naming and 107 addressing on the Public Switched Telephone Network (PSTN) have been 108 abstracted. In the case of a ported number, the dialed number is not 109 directly routable on the PSTN and must be translated into a routing 110 number for call completion. Other numbers, which are not ported, and 111 which can be routed directly on the PSTN based on the dialed number, 112 are typically assigned to carriers and other entities in large blocks 113 or pools. Number Portability and other numbering information is 114 distributed in a variety of methods and formats around the world. 116 The Enumservices described here could enable service providers to 117 place ported, pooled, and blocks of numbers and their associated PSTN 118 contact information, into externally available or highly locally 119 cached ENUM databases. This, in turn, could enable such parties to 120 consolidate all telephone number lookups in their networks into a 121 single ENUM lookup, thereby simplifying call routing and network 122 operations, which would then result in either an on-net, or IP-based 123 response, or off-net, PSTN-based response. 125 The following Enumservice is registered with this document: "pstn" to 126 indicate PSTN routing data, including number portability data, non- 127 ported telephone number data (individually or in number blocks), and 128 other PSTN-oriented data that is associated with E.164 telephone 129 numbers. The purpose of this Enumservice is to provide routing 130 information for telephone numbers which do not designate an endpoint 131 resident on the public Internet or a private/peered Internet Protocol 132 (IP) network. Thus, these are numbers which are only routable via 133 the traditional PSTN, even if the call originates from an IP network. 134 The URIs returned in this service may use the TEL URI parameters 135 defined in draft-ietf-iptel-tel-np-10 [10], and implementations must 136 be prepared to accept them. 138 The service parameters defined in RFC 3761 indicate that a "type" and 139 a "subtype" may be specified. Within this set of specifications, the 140 convention is assumed that the "type" (being the more generic term) 141 defines the service and the "subtype" defines the URI scheme. 143 When only one URI scheme is associated with a given service, it 144 should be assumed that an additional URI scheme to be used with this 145 service may be added at a later time. Thus, the subtype is needed to 146 identify the specific Enumservice intended. 148 3. Distribution of Data 150 The distribution of number portability data is often highly 151 restricted either by contract or regulation of a National Regulatory 152 Authority (NRA), therefore NAPTR records specified herein may or may 153 not be part of the e164.arpa DNS tree. 155 The authors believe that it is more likely that these records will be 156 distributed on a purely private basis. Distribution of this NAPTR 157 data could be either (a) on a private basis (within a service 158 provider's internal network, or on a private basis between one or 159 more parties using a variety of security mechanisms to prohibit 160 general public access), (b) openly available or, (c) distributed by 161 the relevant number portability organization or other industry 162 organization, but possibly on a national basis and subject to or in 163 accordance with national regulatory policy. 165 If such data was distributed nationally, the national telephone 166 numbering authority, or some other regulatory body or numbering 167 organization, may have jurisdiction. Such a body may choose to 168 restrict distribution of the data in such a way that it may not pass 169 over that country's national borders. 171 4. ENUM Service Registration for PSTN 173 4.1 ENUM Service Registration for PSTN with Subtype "tel" 175 Enumservice Name: "pstn" 177 Enumservice Type: "pstn" 179 Enumservice Subtype: "tel" 181 URI Schemes: 'tel:' 183 Functional Specification: 185 These Enumservices indicate that the remote resource identified can 186 be addressed by the associated URI scheme in order to initiate a 187 telecommunication session, which may include two-way voice or other 188 communications, to the PSTN. These URIs may contain number 189 portability data as specified in draft-ietf-iptel-tel-np-10 [10]. 191 Security Considerations: See Section 9. 193 Intended Usage: COMMON 195 Authors: 197 Jason Livingood (jason_livingood@cable.comcast.com) 198 Richard Shockey (richard.shockey@neustar.biz) 200 Any other information the author deems interesting: 202 A Number Portability Dip Indicator (npdi) should be used in practice 203 (see examples below in Section 5). 205 4.2 ENUM Service Registration for PSTN with Subtype "sip" 207 Enumservice Name: "pstn" 209 Enumservice Type: "pstn" 211 Enumservice Subtypes: "sip" 213 URI Schemes: 'sip:' 215 Functional Specification: 217 These Enumservices indicate that the remote resource identified can 218 be addressed by the associated URI scheme in order to initiate a 219 telecommunication session, which may include two-way voice or other 220 communications, to the PSTN. 222 Security Considerations: See Section 9. 224 Intended Usage: COMMON 226 Authors: 228 Jason Livingood (jason_livingood@cable.comcast.com) 229 Richard Shockey (richard.shockey@neustar.biz) 231 Any other information the author deems interesting: 233 A Number Portability Dip Indicator (npdi) should be used in practice 234 (see examples below in Section 5). 236 5. Examples 238 The following sub-sections document several examples for illustrative 239 purposes. These examples shall in no way limit the various forms 240 that this Enumservice may take. 242 5.1 Example of a Ported Number, Using a 'tel' URI Scheme 244 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 245 NAPTR 10 100 "u" "E2U+pstn:tel" 246 "!^.*$!tel:+1-215-555-0123;npdi;rn=+1-215-555-0199!". 248 In this example, a Routing Number (rn) and a Number Portability Dip 249 Indicator (npdi) are used as shown in draft-ietf-iptel-tel-np-10 250 [10]. The 'npdi' field is included in order to prevent subsequent 251 lookups in legacy-style PSTN databases. 253 5.2 Example of a Ported Number, Using a 'sip' URI Scheme 255 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 256 NAPTR 10 100 "u" "E2U+pstn:sip" 257 "!^.*$!sip:+1-215-555-0123;npdi;rn=+1-215-555-0199 258 @gw.example.com;user=phone!". 260 In this example, a Routing Number (rn) and a Number Portability Dip 261 Indicator (npdi) are used as shown in draft-ietf-iptel-tel-np-10 262 [10]. The 'npdi' field is included in order to prevent subsequent 263 lookups in legacy-style PSTN databases. The method of conversion 264 from a tel to a SIP URI is as demonstrated in RFC 3261, Section 265 19.1.6 [11], as well as in , draft-ietf-iptel-tel-np-10 Section 6 266 [10]. 268 5.3 Example of a Non-Ported Number, Using a 'tel' URI Scheme 270 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 271 NAPTR 10 100 "u" "E2U+pstn:tel" 272 "!^.*$!tel:+1-215-555-0123;npdi!". 274 In this example, a Number Portability Dip Indicator (npdi) is used 275 [10]. The 'npdi' field is included in order to prevent subsequent 276 lookups in legacy-style PSTN databases. 278 5.4 Example of a Non-Ported Number, Using a 'sip' URI Scheme 280 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 281 NAPTR 10 100 "u" "E2U+pstn:sip" 282 "!^.*$!sip:+1-215-555-0123;npdi@gw.example.com;user=phone!". 284 In this example, a Number Portability Dip Indicator (npdi) is used 285 [10]. The 'npdi' field is included in order to prevent subsequent 286 lookups in legacy-style PSTN databases. The method of conversion 287 from a tel to a SIP URI is as demonstrated in RFC 3261, Section 288 19.1.6 [11], as well as in , draft-ietf-iptel-tel-np-10 Section 6 289 [10]. 291 5.5 Example Using a Regular Expression 293 $ORIGIN 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 294 NAPTR 10 100 "u" "E2U+pstn:tel" 295 "!(^.*)$!tel:\1;npdi!". 297 In this example, a regular expression replacement function is used to 298 reduce the size of the NAPTR record. The tel URI uses "\1" which 299 would dynamically replace the expression with the TN plus the leading 300 "+", in this case +1-215-555-0123. 302 6. Implementation Recommendations 304 6.1 Call Processing When Multiple Records Are Returned 306 It is likely that that both E2U+sip and E2U+pstn Enumservice type 307 records will be returned for a given query. In this case, this could 308 result in what is essentially an on-net and off-net pstn record. 309 Thus, one record gives the associated address on an IP network, while 310 the other gives the associated address on the PSTN. As with multiple 311 records resulting from a typical ENUM query of the e164.arpa tree, it 312 is up to the application using an ENUM resolver to determine which 313 record(s) to use and which record(s) to ignore. Implementers should 314 take this into consideration and build logic into their applications 315 that can select appropriately from multiple records based on 316 business, network, or other rules. For example, such a resolver 317 could be configured to grant preference to the on-net record, or 318 execute other logic as required by the application. 320 6.2 NAPTR Configuration issues 322 It has been suggested that tel URIs may be easier and more efficient 323 to use in practice than SIP URIs. In addition, the use of tel URIs 324 may result in somewhat smaller NAPTR records which, when considering 325 adding hundreds of millions of these records to the DNS, could have a 326 substantial impact on the processing and storage requirements for 327 service providers or other entities making use of this Enumservice 328 type. 330 Implementers may wish to consider using regular expressions in order 331 to reduce the size of individual NAPTRs. This will have a 332 significant effect on the overall size of the database involved. 333 Using the Section 5.5 example from above, this is 11 bytes per 334 record. 336 7. Example of E2U+pstn in Call Processing 338 This is an example of how a switch, proxy, or other calling 339 application may make use of this Enumservice type during the call 340 initiation process. 342 7.1 Dialed Number Not Available On-Net 343 a) A user, which is connected to a calling application, dials an 344 E.164 telephone number: +1-215-555-0123. 345 b) The calling application uses the dialed number to form a NAPTR 346 record: 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 347 c) The DNS finds an E2U+pstn:tel record and returns a tel URI for 348 processing by the calling application: tel:+1-215-555- 349 0123;npdi. 350 d) The calling application uses routing logic to determine which 351 media gateway is the closest to this number and routes the 352 call appropriately. 354 7.2 Dialed Number Available On-Net and on the PSTN 355 a) A user, which is connected to a calling application, dials an 356 E.164 telephone number: 1-215-555-0123. 357 b) The calling application uses the dialed number to form a NAPTR 358 record: 3.2.1.0.5.5.5.5.1.2.1.e164.arpa. 359 c) The DNS finds both an E2U+pstn record, as well as an E2U+sip 360 record, since this number happens to be on the IP network of a 361 connected network. 362 d) The calling application prioritizes the on-net record first: 363 sip:+1-215-555-0123;npdi@gw.example.com;user=phone. 364 e) The calling application sets up the SIP call to 365 gw.example.com. 366 f) Should the IP call route fail for whatever reason, the calling 367 application may be able to utilize the E2U+pstn record to 368 invoke a fallback route to a media gateway that is connected 369 to the PSTN. 371 8. Security Considerations 373 DNS, as used by ENUM, is a global, distributed database. Should 374 implementers of this specification use e164.arpa or any other 375 publicly available domain as the tree for maintaining PSTN 376 Enumservice data, this information would be visible to anyone 377 anonymously. While this is not qualitatively different from 378 publication in a Telephone Directory, it does open or ease access to 379 such data without any indication that such data has been accessed or 380 by whom it has been accessed. 382 Such data harvesting by third parties is often used to generate lists 383 of targets for unsolicited information. Thus, a third party could 384 use this to generate a list that they can use to make unsolicited 385 "telemarketing" phone calls. Many countries have do-not-call 386 registries or other legal or regulatory mechanisms in place to deal 387 with such abuses. 389 As noted earlier Carriers, service providers, and other users may 390 simply choose not to publish such information in the public e164.arpa 391 tree, but may instead simply publish this in their internal ENUM 392 routing database that is only able to be queried by trusted elements 393 of their network, such as softswitches and SIP proxy servers. They 394 may also choose to publish such information in a carrier-only branch 395 of the E164.ARPA tree, should one be created. 397 Although an E.164 telephone number does not appear to reveal as much 398 identity information about a user as a name in the format 399 sip:username@hostname or email:username@hostname, the information is 400 still publicly available, thus there is still the risk of unwanted 401 communication. 403 An analysis of threats specific to the dependence of ENUM on the DNS 404 and the applicability of DNSSEC [13] to this is provided in RFC 3761 405 [1]. A thorough analysis of threats to the DNS itself is covered in 406 RFC 3833 [14]. 408 9. IANA Considerations 410 This document registers the 'pstn' Enumservice type and the subtype 411 "tel" and "sip" under the Enumservice registry described in the IANA 412 considerations in RFC 3761. Details of this registration are 413 provided in Section 4 of this document. 415 10. Acknowledgements 417 The authors wish to thank Lawrence Conroy, Tom Creighton, Jason 418 Gaedtke, Jaime Jimenez, Chris Kennedy, Alexander Mayrhofer, Doug 419 Ranalli, Jonathan Rosenberg, Bob Walter, and James Yu for their 420 helpful discussions of this topic, and detailed reviews of this 421 document. The authors also wish to thank the IETF's ENUM Working 422 Group for helpful feedback in refining and developing this draft. 424 11. References 426 11.1 Normative References 428 [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 429 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 430 Application (ENUM)", RFC 3761, April 2004. 432 [2] ITU-T, "The International Public Telecommunication Number Plan", 433 Recommendation E.164, May 1997. 435 [3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 436 1034, November 1987. 438 [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 439 Three: The Domain Name System (DNS) Database", RFC 3403, October 440 2002. 442 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 443 One: The Comprehensive DDDS", RFC 3401, October 2002. 445 [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 446 Two: The Algorithm", RFC 3402, October 2002. 448 [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 449 Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 450 2002. 452 [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 453 Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002. 455 [9] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 456 December 2004. 458 [10] Yu, J., "Number Portability Parameters for the "tel" URI", 459 draft-ietf-iptel-tel-np-10, May 2006. 461 [11] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 462 3261, June 2002. 464 11.2 Informative References 466 [12] Bradner, et al., "IANA Registration for Enumservices email, fax, 467 mms, ems and sms", RFC 4355, January 2006. 469 [13] Arends, R. and et al., "Protocol Modifications for the DNS 470 Security Extensions", RFC 4035, March 2005. 472 [14] Atkins, D. and Austein, R., "Threat Analysis of the Domain Name 473 System (DNS)", RFC 3833, August 2004. 475 [15] Foster, M., McGarry, T., and Yu, J., "Number Portability in the 476 GSTN: An Overview", RFC 3482, February 2003. 478 [16] Peterson, J., "enumservice Registration for Session Initiation 479 Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004. 481 Authors' Addresses 483 Jason Livingood 484 Comcast Cable Communications 485 1500 Market Street 486 Philadelphia, PA 19102 487 USA 489 Phone: +1-215-981-7813 490 Email: jason_livingood@cable.comcast.com 492 Richard Shockey 493 NeuStar 494 46000 Center Oak Plaza 495 Sterling, VA 20166 496 USA 498 Phone: +1-571-434-5651 499 Email: richard.shockey@neustar.biz 501 Intellectual Property and Copyright Statements 503 Intellectual Property Statement 505 The IETF takes no position regarding the validity or scope of any 506 Intellectual Property Rights or other rights that might be claimed to 507 pertain to the implementation or use of the technology described in 508 this document or the extent to which any license under such rights 509 might or might not be available; nor does it represent that it has 510 made any independent effort to identify any such rights. Information 511 on the procedures with respect to rights in RFC documents can be 512 found in BCP 78 and BCP 79. 514 Copies of IPR disclosures made to the IETF Secretariat and any 515 assurances of licenses to be made available, or the result of an 516 attempt made to obtain a general license or permission for the use of 517 such proprietary rights by implementers or users of this 518 specification can be obtained from the IETF on-line IPR repository at 519 http://www.ietf.org/ipr. 521 The IETF invites any interested party to bring to its attention any 522 copyrights, patents or patent applications, or other proprietary 523 rights that may cover technology that may be required to implement 524 this standard. Please address the information to the IETF at 525 ietf-ipr@ietf.org. 527 Disclaimer of Validity 529 This document and the information contained herein are provided on an 530 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 531 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 532 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 533 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 534 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 535 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 537 Copyright Statement 539 Copyright (C) The Internet Society (2006). This document is subject 540 to the rights, licenses and restrictions contained in BCP 78, and 541 except as set forth therein, the authors retain all their rights. 543 Acknowledgment 545 Funding for the RFC Editor function is currently provided by the 546 Internet Society.