idnits 2.17.00 (12 Aug 2021) /tmp/idnits46734/draft-rosen-nena-ecrit-requirements-00.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 491. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 191 has weird spacing: '...g paths solut...' == 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 (February 15, 2005) is 6297 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) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ecrit B. Rosen 3 Internet-Draft Emergicom 4 Expires: August 19, 2005 N. Abbott 5 Telcordia 6 February 15, 2005 8 NENA Requirements for Emergency Call processing 9 draft-rosen-nena-ecrit-requirements-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 19, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 The National Emergency Number Association (NENA)'s mission is to 45 foster the technological advancement, availability, and 46 implementation of a universal emergency telephone number system in 47 North America. NENA has an active effort to develop a new 48 architecture for emergency call handling known as "i3" being 49 developed in its Long Term Definition working group. The following 50 requirements are a subset of the requirements of the i3 work which 51 relate to ecrit work. NENA understands the global nature of the 52 Internet, and is eager to work with the IETF to ensure that emergency 53 call processing meets the needs of users in North America. 55 Table of Contents 57 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 58 2. Background on the North American 9-1-1 System . . . . . . . . 4 59 3. Functional Requirements . . . . . . . . . . . . . . . . . . . 7 60 3.1 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.2 Location . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.3 Call Back Address . . . . . . . . . . . . . . . . . . . . 8 63 3.4 Additional Information . . . . . . . . . . . . . . . . . . 8 64 3.5 Validation of Civic Location . . . . . . . . . . . . . . . 8 65 3.6 Routing of Calls . . . . . . . . . . . . . . . . . . . . . 9 66 3.7 Connections to the Emergency Services Network . . . . . . 11 67 3.8 Other . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 71 Intellectual Property and Copyright Statements . . . . . . . . 14 73 1. Requirements notation 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Background on the North American 9-1-1 System 81 The universal emergency number in nearly all of North America is 82 9-1-1. Wireless or wireline callers to 9-1-1 are are routed by the 83 phone system to one of approximately 6,134 Public Safety Answering 84 Points (PSAPs), which are agencies of local government. In North 85 America, there was a very large effort to build what is called the 86 "Enhanced 9-1-1" or E911 system which endeavors to inform the call 87 taker of the location (address) of the caller automatically. 89 Location based routing of emergency calls is handled by a special 90 purpose tandem switch known as a Selective Router (SR). There are 91 several hundred Selective Routers in North America. PSAPs are 92 connected by dedicated trunks to an SR. The SR has a database that 93 is indexed by a key provided in the signaling to determine which PSAP 94 should recieve the call. For wireline callers, the key is the ANI 95 (Automatic Number Identification), typically the calling party 96 number. For wireline callers, the key may be a dynamically assigned 97 number associated with the call. 99 Automatic delivery of location information to the PSAP is 100 accomplished using a database known as the ALI (Automatic Location 101 Identification) which is also indexed by the ANI (for wireline 102 callers) or by the dynamically assigned key for wireless callers. 103 The ALI and contains the location associated with the telephone 104 number of the caller (or determined by the dynamic key for wireless 105 callers). A query to the ALI is made by the PSAP as it answers the 106 call, and the location is displayed to the call taker. To ensure 107 that the location information entered into the ALI conforms to the 108 civic address space known to the PSAP, there is another database 109 called the "Master Street Address Guide" which contains a listing of 110 all known streets and the known address ranges within those streets. 111 When moves adds or changes are ordered for telephone services, the 112 carriers process service orders for entry into the ALI. Before 113 changes are made, the address information is validated by comparing 114 it to the MSAG. If the address matches an entry in the MSAG, it is 115 considered a valid address, and entered into the ALI. 117 Each PSAP has a service area, which do not overlap. Nearly all of 118 North America is served by a PSAP, although there remain isolated 119 areas which do not have 9-1-1 service and must rely on direct calls 120 to police, fire or emergency medical services. The boundaries of the 121 services areas often match the boundaries of political subdivisions 122 such as state, county or municipality, but unfortunately, they do not 123 always have such integral boundaries. For historical, political, and 124 practical reasons, some PSAP boundaries are irregular. In some 125 cases, for example, boundaries are a few townships, several 126 unincorporated areas of a county, and a few streets of another 127 municipality. The boundaries, for civic address purposes, are 128 between specific street addresses. For example, 101 North Main might 129 be served by one PSAP, and 102 North Main may be served by another. 130 As with other areas, sometimes streets are split down the middle, and 131 even numbered houses are in one service area, and odd numbered 132 streets are in another. Although the incidence of irregular 133 boundaries is uncommon, it occurs with sufficient frequency that we 134 must have mechanisms that cope with routing to irregular boundaries. 136 Validation of addresses, in comparison to the current MSAG, is 137 essential for North America. The accuracy of the location is greatly 138 enhanced by verifying that addresses presented to the PSAP during a 139 call are known to the responders - that is, if a responder is 140 dispatched to 101 North Main, there is a very high probability that 141 there is a 101 North Main. Addresses must be validated before they 142 are used. 144 The MSAG, like the ALI, is maintained by a designated local 9-1-1 145 authority, which sometimes has jurisdiction over several PSAPs. This 146 means that there are actually several MSAGs that cover areas 147 corresponding to one or more PSAP service boundaries. This 148 complicates any proposed mechanisms that would maintain global 149 equivalents of the MSAG because the maintenance of the database must 150 devolve to the service boundaries, which, as has been explained, is 151 irregular. An entry in the MSAG for 101 North Main may be the 152 responsibility of one entity, while the entry that covers 102 North 153 Main may be another entity's responsibility. 155 In North America, there is a complication with civic addresses that 156 arises because the Post Office does not necessarily follow the 157 changes that evolve over time with municipal boundaries. 158 Specifically, the "Community Name" for the post office is not 159 necessarily the actual (legal) community name. This has been the 160 subject of discussion in geopriv, and there is now agreement that 161 both a postal community name and a legal community name should be 162 carried in a location objects. Routing of emergency calls is always 163 on the legal community name. 165 In the North American E9-1-1 System, the Selective Router provides 166 default routing arrangements when the specific location information 167 for the caller is not available; this default routing is generally 168 derived based on the local access area from which the call was 169 originated (as identified by a trunk group). 171 In addition, in the North American E9-1-1 System, the Selective 172 Router supports overload routing arrangements (e.g., to an 173 announcement) in congestion conditions, and contingency routing 174 arrangements when a PSAP is not available to answer emergency calls. 176 These contingency routing arrangements (e.g., to an alternate 177 answering point) can be invoked automatically (e.g., on a scheduled 178 basis) or in real-time for the PSAP by a designated authority(ies). 180 The North American E9-1-1 System also provides for congestion control 181 mechanisms that restrict the number of emergency calls that can be 182 offered to a PSAP at any given time. 184 3. Functional Requirements 186 3.1 Signaling 188 3.1-1: Tracking and Tracing Facilities for all calls must be 189 provided. This include all routing entities as well as all 190 signaling entities. 191 3.1-2: Each element in the signaling and routing paths solution 192 shall maintain call detail records that can be accessed by 193 management systems to develop call statistics in real time. 194 3.1-3: The emergency call routing system must harmonize with 195 international specifications to permit local determination of 196 emergency call number (i.e. 9-1-1, 1-1-2). 197 3.1-4: Mechanisms must be provided to route emergency calls in areas 198 not served by E9-1-1 to an appropriate PSTN telephone number. 199 3.1-5: Each element of the signaling and routing paths shall provide 200 congestion controls. 201 3.1-6: It shall be possible to determine the complete call chain of a 202 call, including the identity of each signaling element in the 203 path, and the reason it received the call (Call History). 204 3.1-7: Support must be provided to accept calls from end offices and 205 MSCs via the Public Switched Telephone Network, using SS7, 206 CAMA and ISDN interfaces. 207 3.1-8: Call setup time (dialing of last digit to alerting at the 208 PSAP), under expected peak load shall be less than 2 seconds. 209 If CAMA signaling is in the path, then an additional ? seconds 210 is permitted. 212 3.2 Location 214 3.2-1: Calls using VoIP or subsequent methods are expected to supply 215 location with the call. 216 3.2-2: PSAPs shall accept location as civic and/or geo specified. 217 3.2-3: All representations of location shall include the ability to 218 carry altitude. This requirement does not imply altitude is 219 always used or supplied. 220 3.2-4: The preferred coordinate system for emergency calls is WGS-84. 221 3.2-5: If multiple Location Objects are provided with a call, it 222 should be possible to identify the most accurate, current, 223 appropriate location information to be used for routing 224 emergency calls and dispatching emergency responders. 225 3.2-6: No assumption shall be made that the entity presenting the 226 call to the PSAP has any knowledge of, or control over the 227 provider of location. The location provider may be 228 independent of all other service providers handling the call. 230 3.2-7: PSAPs shall have the ability to requery for a location update. 231 3.2-8: PSAPs shall be able to make use of default location 232 information when measurement based location determination 233 mechanisms fail. Examples include tower/Access Point 234 location, last known fix, etc. 235 3.2-9: PSAPs must be made aware when default location information was 236 used to route a call. 238 3.3 Call Back Address 240 3.3-1: Calls to 9-1-1 shall supply a call back address (URI) with the 241 call 243 3.4 Additional Information 245 3.4-1: In addition to information sent with the call, additional 246 information may be available that is retrieved from internal 247 or external databases using a key to the information included 248 with the call. This key may also include information to 249 identify/address the database. 250 3.4-2: Additional information may be available to the call taker 251 based on the location of the caller. 252 3.4-3: Additional information may be available to the call taker 253 based on the owner of the structure. 254 3.4-4: Additional information may be available to the call taker 255 based on the tenant of the structure. 256 3.4-5: Where a vehicle is involved, additional information may be 257 available. 258 3.4-6: Additional information may be available based on the Address 259 of Record of the caller. In this context, AoR equates to the 260 caller. 261 3.4-7: Consideration should be given to permitting users to have 262 domain independent mechanisms to supply information related to 263 the caller, for example, another datum related to user. 265 3.5 Validation of Civic Location 267 3.5-1: It must be possible to determine, BEFORE an emergency call is 268 placed, if a civic address is "9-1-1 valid". 269 3.5-2: A ô9-1-1 Valid Address Databaseö, which contains all valid 270 street addresses within a defined area, should be used as the 271 basis to determine validity of a civic address. 272 3.5-3: A 9-1-1 valid address is defined as an address with a subset 273 of the fields in the NENA XML address format, which when 274 looked up in the 9-1-1 Address Validation database, yields 275 exactly one record. 277 3.5-4: If it is determined that an address is invalid, an error 278 diagnosis should be supplied if appropriate, as well as a 279 contact URI for resolving errors in the database. 280 3.5-5: The 9-1-1 Valid Address Database undergoes slow changes. 281 This must be taken into account when validating civic 282 addresses. 283 3.5-6: The 9-1-1 Valid Address Database defined serving area 284 boundaries may have the same characteristics as routing Req ? 285 and ? below. 286 3.5-7: Validation information must be secured against unauthorized 287 modification. PSAPs (or perhaps a higher level civic 288 authority such as a county, state/province or national body) 289 must be the only entities permitted to make changes to the 290 database. 291 3.5-8: The fields in the 9-1-1 Address Validation database must be 292 used as they are defined in the relevant NENA standard, 293 including use of the Street suffix, pre and post 294 directionals, etc. Only USPS abbreviations will be permitted 295 in suffixes. No abbreviations are permitted in street names 296 or community names. All fields must be populated as 297 appropriate, including the postal community name, county 298 name, and zipcode. 299 3.5-9: PSAPs must have access to the actual (MSAG) community name. 300 3.5-10: A postal address may be a 9-1-1 valid address if, as stated 301 in requirement ?, a query to the 9-1-1 Address Validation 302 Database with the postal address yields exactly one record. 303 3.5-11: The PSAP must have access to all of contents of the 9-1-1 304 address validation database. 305 3.5-12: The fields in the 9-1-1 Address Validation database must be 306 used as they are defined in the relevant NENA standard, 307 including use of the Street suffix, pre and post 308 directionals, etc. Only USPS abbreviations will be permitted 309 in suffixes. No abbreviations are permitted in street names 310 or community names. All fields must be populated as 311 appropriate, including the postal community name, legal 312 community name, county name, state/province and zipcode. 313 3.5-13: PSAPs must have access to the actual (MSAG) community name. 314 3.5-14: A postal address may be a 9-1-1 valid address if, as stated 315 in requirement ?, a query to the 9-1-1 Address Validation 316 Database with the postal address yields exactly one record. 317 3.5-15: The PSAP must have access to all of the contents of the 9-1-1 318 address validation database. 320 3.6 Routing of Calls 321 3.6-1: Calls must be routed to the correct PSAP based on the 322 location of the caller and the declared service boundary of 323 the PSAP. 324 3.6-2: Routing must be possible on either civic or geo location 325 information. 326 3.6-3: It must be possible to route a call based on either a civic 327 or a geo location without requiring conversion. from one to 328 the other. This requirement does not prohibit an 329 implementation from converting and using the resulting 330 conversion for routing. However, see Req ?. 331 3.6-4: It must be possible for a designated 9-1-1 authority for a 332 PSAP to approve of any geo-coding database used to assist in 333 determining routing of calls to that PSAP. Mechanisms must 334 be provided for the designated 9-1-1 authority for the PSAP 335 to test, and certify a geo-coding database as suitable for 336 routing calls to the PSAP. The PSAP may choose to NOT avail 337 itself of such a mechanism. 338 3.6-5: It must be possible for the designated 9-1-1 authority to 339 supply, maintain, or approve of databases used for civic 340 routing. Mechanisms must be provided for a designated 341 authority for a PSAP to test and certify a civic routing 342 database as suitable for routing calls to that PSAP. 343 3.6-6: It must be possible for the PSAP itself (or a contractor it 344 nominates on its behalf) to provide geocode and reverse 345 geocode data and/or conversion service to be used for routing 346 determination. This implies definition of a standard 347 interchange format for geocode data, and protocols to access 348 it. 349 3.6-7: The PSAP must have a mechanism to declare its serving 350 boundaries (in civic and geo formats) for routing purposes. 351 3.6-8: Boundaries for civic routing must be able to be specific to a 352 street address range, a side of a street (even/odd street 353 addresses), a building within a ôcampusö, or any of the 354 location fields available. 355 3.6-9: It must be possible to use various combined components of the 356 location object for determination of routing. Some areas may 357 only require routing to a country level, others to a 358 state/province, others to a county, or to a municipality, and 359 so on. No assumption should be made on the granularity of 360 routing boundaries or about the combination of components 361 used. 362 3.6-10: Boundaries mechanisms for geo routing must be able to be 363 specific to a natural political boundary, a natural physical 364 boundary (such as a river), or the boundaries listed in Req ? 365 above 367 3.6-11: Routing databases using 9-1-1 Valid Addresses or 368 lat/lon/altitude as keys must both be available to all 369 entities needing to route 9-1-1 calls. 370 3.6-12: Carriers, enterprises and other entities that route emergency 371 calls must be able to route calls from any location to its 372 appropriate PSAP. 373 3.6-13: It must be possible for a given PSAP to decide where its 374 calls should be routed. 375 3.6-14: It is desirable for higher level civic authorities such as a 376 county or state/province to be able to make common routing 377 decisions for all PSAPs within their jurisdiction. For 378 example, a state may wish to have all emergency calls placed 379 within that state directed to a specific URI. This does NOT 380 imply a single answering point; further routing may occur 381 beyond the common URI. 382 3.6-15: Routing as specified in Req ? may change on short notice due 383 to local conditions, traffic, failures, schedule, etc. 384 3.6-16: Information and mechanisms used to determine routing must be 385 extremely reliable and available, which implies redundancy, 386 protocol stability, and resiliency. 387 3.6-17: Routing information must be secured against unauthorized 388 modification. PSAPs (or perhaps a higher level civic 389 authority such as a county, state/province or national body) 390 or their designated representative must be the only entities 391 permitted to change routing information. 392 3.6-18: It must be possible to supply contingency routing 393 information, for example, an alternate URI or an E.164 to be 394 used when normal routing fails. 395 3.6-19: Multiple types of failures may have different contingency 396 routes. 397 3.6-20: It must be possible to provide more than one contingency 398 route for the same type of failure 399 3.6-21: A procedure must be specified to handle ôdefault routeö 400 capability when no location is available or the location 401 information is corrupted. 402 3.6-22: Location available at the time the call is routed may not be 403 accurate. Updates to location may result in a different 404 route and the system must accommodate this. 405 3.6-23: Default routes must be available when location information is 406 not available. 407 3.6-24: Access Infrastructure providers must provide a location 408 object that is as accurate as possible when location 409 measurement or lookup mechanisms fail. 410 3.6-25: Entities routing emergency calls shall retain information 411 used to choose a route for subsequent error resolution. 413 3.6-26: It should be possible to have updates of location (which may 414 occur when measuring devices provider early, but imprecise 415 ôfirst fixö location) which can change routing of calls. 417 3.7 Connections to the Emergency Services Network 419 3.7-1: If there is network connectivity between the emergency caller 420 and the PSAP, and routing information is available, the call 421 should be completed, even if other parts of the network are 422 not reachable. 424 3.8 Other 426 3.8-1: There shall be no single point of failure. 427 3.8-2: Each subsystem in the i3 solution shall be designed such that 428 the system survives major disruption including disaster, 429 deliberate attack, and massive element failure. 430 3.8-3: Special consideration should be given to ôDistributed Denial 431 of Serviceö attacks 432 3.8-4: The solution shall include mechanisms to test each element and 433 complete call chains from caller end device to internal PSAP 434 systems without interfering with real emergency calls. 435 3.8-5: Mechanisms must be provided to provide constant verification 436 of service availability to the PSAP. 437 3.8-6: Mechansism must be provided to provide automatically generated 438 misroute and location error reports. 440 4. Security Considerations 442 None. 444 5. References 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, March 1997. 449 Authors' Addresses 451 Brian Rosen 452 Emergicom 453 470 Conrad Dr 454 Mars, PA 16046 455 US 457 Phone: +1 724 382 1051 458 Email: br@brianrosen.net 460 Nadine Abbott 461 Telcordia 462 One Telcordia Drive, Room 4B655 463 Piscataway, NJ 08854 464 US 466 Phone: +1-732-699-6109 467 Email: nabbott@telcordia.com 469 Intellectual Property Statement 471 The IETF takes no position regarding the validity or scope of any 472 Intellectual Property Rights or other rights that might be claimed to 473 pertain to the implementation or use of the technology described in 474 this document or the extent to which any license under such rights 475 might or might not be available; nor does it represent that it has 476 made any independent effort to identify any such rights. Information 477 on the procedures with respect to rights in RFC documents can be 478 found in BCP 78 and BCP 79. 480 Copies of IPR disclosures made to the IETF Secretariat and any 481 assurances of licenses to be made available, or the result of an 482 attempt made to obtain a general license or permission for the use of 483 such proprietary rights by implementers or users of this 484 specification can be obtained from the IETF on-line IPR repository at 485 http://www.ietf.org/ipr. 487 The IETF invites any interested party to bring to its attention any 488 copyrights, patents or patent applications, or other proprietary 489 rights that may cover technology that may be required to implement 490 this standard. Please address the information to the IETF at 491 ietf-ipr@ietf.org. 493 Disclaimer of Validity 495 This document and the information contained herein are provided on an 496 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 497 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 498 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 499 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 500 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 501 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 503 Copyright Statement 505 Copyright (C) The Internet Society (2005). This document is subject 506 to the rights, licenses and restrictions contained in BCP 78, and 507 except as set forth therein, the authors retain all their rights. 509 Acknowledgment 511 Funding for the RFC Editor function is currently provided by the 512 Internet Society.