Network Working Group F. Baker Internet-Draft Cisco Systems Expires: July 11, 2005 B. Carpenter IBM Corporation January 10, 2005 Structure of an International Emergency Alert System draft-baker-alert-system-00 Status of this Memo 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 become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 11, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The authors propose a way in which people could be warned of an impending event in a geographic region. This is similar to and may use services such as the US Emergency Alert System, but differs in that message distribution is targeted only to the affected locality. Baker & Carpenter Expires July 11, 2005 [Page 1] Internet-Draft International Alert System January 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Facilities the proposal depends on . . . . . . . . . . . . . . 4 2.1 Warning Center . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Distributing alerts to regional centers . . . . . . . . . 5 2.2.1 Authenticated Electronic Mail . . . . . . . . . . . . 5 2.2.2 Polled delivery via the World Wide Web . . . . . . . . 6 2.3 Warning Interpretation Policy . . . . . . . . . . . . . . 6 2.4 Distribution of alert messages to the general population . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4.1 Mobile Telephone Text Message Services . . . . . . . . 7 2.4.2 Broadcast services such as radio or television (regional broadcast) . . . . . . . . . . . . . . . . . 8 2.4.3 Presence-based services (subscription) . . . . . . . . 8 2.4.4 Message-based services (subscription) . . . . . . . . 8 3. Implementing an alert service . . . . . . . . . . . . . . . . 9 4. Call to Action . . . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1 SMTP Specifications (for information) . . . . . . . . . . . 14 8.2 S/MIME specifications (for information) . . . . . . . . . . 14 8.3 PGP Specifications (for information) . . . . . . . . . . . . 15 8.4 Telephony specifications and references (for information) . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 A. I am Alive . . . . . . . . . . . . . . . . . . . . . . . . . . 17 B. Common Alerting Protocol . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Baker & Carpenter Expires July 11, 2005 [Page 2] Internet-Draft International Alert System January 2005 1. Introduction The earthquake near Sumatra and subsequent tsunami throughout the Indian Ocean on 26 December 2004 resulted in a large number of deaths; early estimates suggest six digit figures, with the hardest hit being remote regions of Sumatra. In the aftermath of this event, many countries have sent aid of various kinds, and the Internet community has asked itself whether the Internet might have been used to help. This note proposes a system that could be used to quickly warn people in an identified geographic region of an impending event, such as a tsunami, hurricane or typhoon, or attack. It builds on existing technologies that are presently used for other purposes: given a alert from an appropriate Warning Center, the Internet (using, for example, Internet Mail and S/MIME) could be used to deliver an authenticated message to a set of mobile telephone operators, who in turn could send an SMS broadcast to mobile telephones in affected regions, alert of the event. The same email could trigger public and private organizations to initiate necessary support services such as evacuation orders or provision of shelter and emergency medical response. Such an approach would, of course, not warn everyone - everyone does not carry a mobile telephone, and everyone who does would not necessarily read it. But it would warn a large percentage, which might help. This is similar to and may use services such as the US Emergency Alert System. The Emergency Alert System (EAS) is the national alert system designed primarily to allow the President to address the nation reliably during major national disasters, using media such as television, radio, and potentially mobile telephone in the future. It differs in that message distribution is targeted only to the affected locality, such as the mobile telephone cells in a given city, along a coastline, or along the projected path of a storm, and actively reaches out to its audience rather than depending on them being passively watching at the time. Baker & Carpenter Expires July 11, 2005 [Page 3] Internet-Draft International Alert System January 2005 2. Facilities the proposal depends on The proposal depends on the existence and use of four fundamental types of systems: o An Warning Center, such as the NOAA Pacific Tsunami alert Center (http://www.prh.noaa.gov/ptwc/) or the US Geological Survey Earthquake Hazards Program (http://neic.usgs.gov/neis/bulletin/). o A mailing list of people interested in alerts from the alert center, with internet connectivity and continuous monitoring of such alerts. o An appropriate policy for the interpretation of such alerts. o Mobile telephone text message delivery, whether unicast or cell broadcast, by the indicated operators, possibly other media such as radio or television. Each of these systems exists or could be made to exist. What is necessary is implementation. 2.1 Warning Center Research and Warning Centers exist in some parts of the world for certain kinds of events. Generally speaking, they monitor seismic activity or other appropriate indicators, and issue alerts to interested parties. These alerts consist of web pages posted (such as Figure 1), facsimile messages sent to appropriate parties, and so on. What is necessary to implement an alert system is a prediction of what regions might be affected and approximately when. This may entail development of simulations or other predictive tools at the laboratories, to determine who needs an alert and what the alert should say. Ideally, the alert should be simple, accurate, and clear, such as: "coastal regions of may experience a tsunami of magnitude between the hours of and ". Baker & Carpenter Expires July 11, 2005 [Page 4] Internet-Draft International Alert System January 2005 .................. TSUNAMI INFORMATION BULLETIN .................. ATTENTION: NOTE REVISED MAGNITUDE. THIS MESSAGE IS FOR INFORMATION ONLY. THERE IS NO TSUNAMI WARNING OR WATCH IN EFFECT. AN EARTHQUAKE HAS OCCURRED WITH THESE PRELIMINARY PARAMETERS ORIGIN TIME - 0059Z 26 DEC 2004 COORDINATES - 3.4 NORTH 95.7 EAST LOCATION - OFF W COAST OF NORTHERN SUMATERA MAGNITUDE - 8.5 EVALUATION REVISED MAGNITUDE BASED ON ANALYSIS OF MANTLE WAVES. THIS EARTHQUAKE IS LOCATED OUTSIDE THE PACIFIC. NO DESTRUCTIVE TSUNAMI THREAT EXISTS FOR THE PACIFIC BASIN BASED ON HISTORICAL EARTHQUAKE AND TSUNAMI DATA. THERE IS THE POSSIBILITY OF A TSUNAMI NEAR THE EPICENTER. THIS WILL BE THE ONLY BULLETIN ISSUED FOR THIS EVENT UNLESS ADDITIONAL INFORMATION BECOMES AVAILABLE. THE WEST COAST/ALASKA TSUNAMI WARNING CENTER WILL ISSUE BULLETINS FOR ALASKA - BRITISH COLUMBIA - WASHINGTON - OREGON - CALIFORNIA. ************************************************************** Figure 1: Sample Warning Message 2.2 Distributing alerts to regional centers There are many possible ways to distribute the message to regional authorities. Traditional approaches include FAX, the World Wide Web, and standard electronic mail. 2.2.1 Authenticated Electronic Mail Delivery of such a message via the Internet can be accomplished in a number of ways: mail, instant messaging, or other approaches. For the present purpose, the simplest approach would seem to be the use of the Simple Mail Transfer Protocol (SMTP) [RFC2821]. It requires, in essence, the creation of appropriate mailing lists, perhaps managed by the early Warning Centers themselves, of appropriate contacts in government and service providers. Operationally, if the operators prefer, another service could be used. The great danger in such is that miscreants might send messages that appear similar to the same targets, spoofing the source. Such an event would severely damage the credibility and therefore the utility of such a system. As such, it is critical that an authenticated electronic mail message be used. Proof of authenticity might be provided using facilities such as S/MIME [RFC3850][RFC3851] or PGP [RFC3156]. Baker & Carpenter Expires July 11, 2005 [Page 5] Internet-Draft International Alert System January 2005 2.2.2 Polled delivery via the World Wide Web WWW (http or https) may also be used on a polled basis to deliver alerts. Such a system avoids many of the security issues mentioned regarding electronic mail, but has two unfortunate properties: polling must be sufficiently frequent to ensure timeliness of the delivery of the alert, and the frequency presents a scaling issue. An approach to this might be built using Really Simple Syndication (RSS). This is a lightweight XML format designed for sharing headlines and other Web content. Alert centers might use such a system as a way to publish their alerts (Figure 1) permitting receivers to trigger automated actions when they occur. 2.3 Warning Interpretation Policy The receivers of the alert need to know what to do with it. This necessarily requires human response. However, policies should be on record indicating the appropriate response to likely alerts. An example of such a policy might be: "In the event that a tsunami alert is given of magnitude exceeding , request mobile telephone operators in the region to issue an SMS Broadcast in the cells along the coast containing the text (in the local language) 'a tsunami alert is in effect for this region between the hours of and . For further information, contact <>'. In addition, notify local authorities to evacuate the indicated coastal regions." The contact point should be a telephone number, Web URL, or other appropriate information distribution vehicle. 2.4 Distribution of alert messages to the general population The initial alert from the Warning Center is of necessity to a limited audience: government, NGO, and private-sector service organizations that consider the likely impact of the crisis and when appropriate distribute the alert to the general population. The objective is to issue accurate, practical, understandable, and timely messages to the set of people who may be affected, and to limit distribution to only those. For practical reasons, it is most likely that the initial alert will be distributed in the English language and directed to people who can understand elementary English. Local re-distribution may of course be more appropriate in the most widely understood local language. Relevant standards for character set encoding, generally Baker & Carpenter Expires July 11, 2005 [Page 6] Internet-Draft International Alert System January 2005 unicode-based, should be used. It is suggested that the original, probably English, version should be attached. In any case, simple standard phrases should be used to assist comprehension. The key consideration here is efficiently reaching people using services that they are likely to be using. The most logical services include those that provide some sense of locality and are likely to be in active use. Examples of such services include: Mobile Telephone Text Message Services (cell broadcast) Broadcast services such as radio or television (regional broadcast) Presence-based services (subscription) Message-based services (subscription) 2.4.1 Mobile Telephone Text Message Services The GSM Short Message Service (SMS) provides the ability to send and receive text messages to and from mobile telephones. The text can comprise of words or numbers or an alphanumeric combination. SMS was created as part of the GSM Phase 1 standard. Each short message is up to 160 characters is length when Latin alphabets are used, and 70 characters in length when non-Latin alphabets such as Arabic and Chinese are used. Other mobile telephone services, such as CDMA and proprietary systems, have similar capabilities, and there also exist various paging services that may be useful. For the purposes of this suggestion, these may be treated as equivalent, although the technical aspects differ and interplay between them may require careful consideration. Mobile telephone text messages provide two important characteristics for this type of service: o The use of mobile telephones and pagers is very popular in most parts of the world, and o Unlike the Internet, such a service is inherently aware of locality, as every active mobile telephone is registered in a cell, which has locality. Such a system includes the United States' Emergency Alert System, which is a cell-broadcast-based text message system under Baker & Carpenter Expires July 11, 2005 [Page 7] Internet-Draft International Alert System January 2005 development. 2.4.2 Broadcast services such as radio or television (regional broadcast) Radio and TV broadcast signals can be modified or interrupted for emergency alerts. Such systems include the US Emergency Broadcast System, which is used to advise citizens of issues of national or regional crisis, including the advance of severe storms. These have the advantage that they are often active background noise, and therefore can gain attention and distribute messages quickly. They have the disadvantage that they do not actively solicit attention, however; if the radio and TV are off, or the potential listener is asleep or otherwise engaged, the message may be missed or ignored. 2.4.3 Presence-based services (subscription) Internet services suffer in regard to a system of this type in that the Internet conveys no knowledge of geographic location, only topological location. However, one could imagine a service that enabled a person (or their travel agent) to subscribe an Instant Messaging "handle" for alerts within a specific region, and if the handle happens to be "present" at when an alert is active would deliver the alert to the user. 2.4.4 Message-based services (subscription) Internet services suffer in regard to a system of this type in that the Internet conveys no knowledge of geographic location, only topological location. However, one could imagine a service that enabled a person (or their travel agent) to subscribe an electronic mail address for alerts within a specific region. If an alert is presented for that region, the service would send an authenticated electronic mail message recommending the user monitor the URL of the appropriate Warning Center. Baker & Carpenter Expires July 11, 2005 [Page 8] Internet-Draft International Alert System January 2005 3. Implementing an alert service It should be clear, at this point, how such a service would be implemented, but let us recap. Centers exist that monitor seismic activity and provide information to appropriate response centers. These should be enhanced with appropriate technology to predict the effects on appropriate regions, such as "coastal regions of may experience a tsunami of magnitude approximately hours after an earthquake of magnitude in ." These centers should send a signed electronic mail message to a predetermined set of response centers. This predetermination is very likely based on subscription: if someone wants to be told, they might do well to say so, and there might be a cost involved. This message should state the necessary information in terms of the type of event predicted, the probable magnitude, and the time frame during which it might occur. Having authenticated the message, receivers should notify appropriate public and private parties to provide services as needed, such as opening shelters or preparing to offer emergency medical response, and should request mobile telephone operators to notify subscribers whose telephones are registered in a specified region. The mobile telephone operators should interpret the region as a set of mobile telephone cells. For example, "coastal regions" to them constitute the set of mobile telephone cells nearest the coast. They should then determine what telephones are registered in the indicated cells, and send a specified message to each such telephone. An unfortunate side-effect of such a service is that many people in a region will get an alert of something that might not in fact require any action on their part. A key part of the system would be some indication of where people could go for further information. This might be a URL for a web site, a telephone number where a recorded message might be found, or other information source. Radio and TV alerts should be similarly deployed, and presence-based or message-based services should be similarly triggered. Baker & Carpenter Expires July 11, 2005 [Page 9] Internet-Draft International Alert System January 2005 4. Call to Action There are a variety of calls to action that result here, and some actions that are not required but may be advisable. Alert centers for relevant types of disasters need to exist, and lists of contact points must be negotiated. These are beyond the scope of this note, but they are critical to it. There is no requirement for new Internet standards at this time to deploy a service. However, new standards such as a publish/subscribe mechanism in electronic mail might make the tool easier to use, and better tools for S/MIME or PGP use would assist in the use of the system, especially mail tool implementations that automatically sign and verify emails. There is no requirement for new GSM/3GPP standards for deployment. However, deployment of cell broadcast in regions it is not will make the service easier to deploy. CDMA and Wideband CDMA do not at this point support cell broadcast, but a similar service can be deployed by determining the registration in a cell and sending unicast messages to it. A key issue, though, is that SMS messages are often significantly delayed experiencing delays of several hours, and in some cases days. Messages sent from the same locality are frequently not as delayed, but they too experience some variability in delivery times. For this to be truly useful, delays in message delivery need to be improved. What is required is the organizational interlinking a service such as we have described, and the focus on active alerts rather than passive-or-no alerts. This may be a responsibility shouldered by governments within a region, of employers, or of private entrepreneurs; it will require partnership with mobile telephone services at a minimum. A problem with the prediction and alert related to geologic events is that it is very difficult to tell the exact effect that a geological event will have on the oceans, although the potential effects of large geological events are more reliably predicted. What this implies is that there is plenty of room for the funding of research in prediction. The stringent requirement for surety can be offset with frequent training as evidenced by the U.S. Emergency Alert System. The frequent tests alert the populace to the probability of an event encouraging the populace to obtain further information from the local news services. A simpler well rehearsed system is much more effective than a complex infrequently tested one! Baker & Carpenter Expires July 11, 2005 [Page 10] Internet-Draft International Alert System January 2005 5. IANA Considerations This document makes no request of the IANA. Note to RFC Editor: in the process assigning numbers and building IANA registries prior to publication, this section will have served its purpose. It may therefore be removed upon publication as an RFC. Baker & Carpenter Expires July 11, 2005 [Page 11] Internet-Draft International Alert System January 2005 6. Security Considerations The greatest concern this raises is not for the Internet, but for the public and private services that might implement this procedure. The system could be rendered useless if easily spoofed, as real alerts might then be ignored among spoofed alerts. In addition, inaccurate or spoofed alerts may result in human panic or avoidable loss of property or life. As a direct result, the use of an authenticated delivery service such as authenticated mail is critical - the receiver of a alert must be able to verify that the alert was sent by a trusted source, and the trusted source must be worthy of that trust. At this point, a system of this sort should not be completely automated - it should have a human in the loop at critical points. The reason is that while there is excellent science supporting this sort of activity, it has not been reduced to a science. Not all earthquakes result in tsunamis, and not all storm cells result in cyclones. One wishes to ensure that predictions delivered to the general public have a significant probability of proving accurate. Therefore, public safety personnel trained and authorized to make such decisions should be involved at the point where policy is applied. Consideration should be given to the management of the keys and mailing lists used in such a system. They should be periodically tested, to ensure that they are kept up to date and that the supporting tools work properly. In the US, the phrase "this is a test of the Emergency Broadcast System" is well known to consumers, and the procedure it is part of constitutes such a test. It would also be well for senders and receivers of authenticated messages to use software that automates the signing and verification of messages, as in the heat of the moment these steps may be overlooked. Baker & Carpenter Expires July 11, 2005 [Page 12] Internet-Draft International Alert System January 2005 7. Acknowledgements This document was written using the XML2RFC document development tool, and the XMLMind Editor with Bill Fenner's RFC development plugins. Suggestions were offered by a number of reviewers, including Bob Hinden, Bob Wyman, Dale Barr, Harald Tveit Alvestrand, James Seng, Jonathan Rosenberg, Leslie Daigle, Ned Freed, Paul Hoffman, Rob Austein, Sally Floyd, and Ted Hardie. These were of course helpful and greatly appreciated. Baker & Carpenter Expires July 11, 2005 [Page 13] Internet-Draft International Alert System January 2005 8. References 8.1 SMTP Specifications (for information) [RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999. [RFC2554] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000. [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003. [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types Registration", RFC 3848, July 2004. [RFC3885] Allman, E. and T. Hansen, "SMTP Service Extension for Message Tracking", RFC 3885, September 2004. 8.2 S/MIME specifications (for information) [RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999. [RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785, March 2000. [RFC3114] Nicolls, W., "Implementing Company Classification Policy with the S/MIME Security Label", RFC 3114, May 2002. [RFC3183] Dean, T. and W. Ottaway, "Domain Security Services using S/MIME", RFC 3183, October 2001. [RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004. Baker & Carpenter Expires July 11, 2005 [Page 14] Internet-Draft International Alert System January 2005 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004. 8.3 PGP Specifications (for information) [RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996. [RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996. [RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [RFC3156] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. 8.4 Telephony specifications and references (for information) [ETSI.TS.44.012] European Technology Standards Institute (ETSI), "Short Message Service Cell Broadcast (SMSCB) support on the mobile radio interface", ETSI TS 44.012, 2001. [NDIS] Telecommunications Industry Association, "Effective Disaster alerts. Working Group on Natural Disaster Information Systems", 2000. [TIA-136-630] Telecommunications Industry Association, "Broadcast Teleservice Transport - Broadcast Air Interface Transport Service (BATS)", TIA/EIA TIA/EIA-136-630, 1999. Authors' Addresses Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, California 93117 USA EMail: fred@cisco.com Baker & Carpenter Expires July 11, 2005 [Page 15] Internet-Draft International Alert System January 2005 Brian Carpenter IBM Corporation Sauemerstrasse 4 8803 Rueschlikon Switzerland EMail: brc@zurich.ibm.com Baker & Carpenter Expires July 11, 2005 [Page 16] Internet-Draft International Alert System January 2005 Appendix A. I am Alive In Japan, there is a service intended to help people who have been affected by a disaster to comfort those who are concerned about them; this is called the "I am Alive" service. In essence, it provides a database in which a victim may post a brief note indicating their status and plans, or a concerned party may register concern, and they can be told about each other even though they are temporarily unable to directly communicate. An overview of the service may be found at http://www.isoc.org/inet2000/cdproceedings/8l/8l_3.htm. Similar services may be of value in other places. If such exist, it would be helpful if either the message announcing the alert or a subsequent message after the event indicated how to easily access the service. Baker & Carpenter Expires July 11, 2005 [Page 17] Internet-Draft International Alert System January 2005 Appendix B. Common Alerting Protocol OASIS has developed an XML-based protocol for distributing alerts, called the "Common Alerting Protocol". CAP is getting significant traction in the realms of Homeland Security, Emergency Manager's organizations, etc. Additional information on CAP may be found at: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency. The CAP V1.0 "standard" may be found at: http://www.oasis-open.org/committees/download.php/6334/oasis-200402-c ap-core-1.0.pdf. Baker & Carpenter Expires July 11, 2005 [Page 18] Internet-Draft International Alert System January 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Baker & Carpenter Expires July 11, 2005 [Page 19]