idnits 2.17.1 draft-hohno-ecs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. ** There are 4 instances of too long lines in the document, the longest one being 20 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 103: '... It SHOULD make use of the internet...' RFC 2119 keyword, line 112: '... And the internet MUST keep playing an...' RFC 2119 keyword, line 141: '... It SHOULD give more priority to th...' RFC 2119 keyword, line 153: '... information SHOULD be processed im...' RFC 2119 keyword, line 155: '... We MUST proceed with the standardi...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 2001) is 8170 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: '2' is defined on line 197, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Ohno 3 INTERNET-DRAFT R. Atarashi 4 Communications Research Lab., Japan 5 November 2001 7 The Emergency Communications on the internet 8 draft-hohno-ecs-00 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 It will be strongly required to provide internet services even in an 34 emergency since the internet is one of the most important 35 communication infrastructures. Therefore, it is necessary to 36 prepare special communication functoin such as victims' information 37 exchange and the disaster information transmission system. It is 38 also necessary to introduce priority control mechanism for the 39 emergency communication. We need to start discussion about the 40 emergency communication systems on the Internet. 42 1. Introduction 44 The importance of the internet has been increasing even in an 45 emergency situation such as natural disasters and terrible attack by 46 terrorism. On the next generation Internet, it will be strongly 47 required to provide reliable internet services even in an emergency 48 since the internet is one of the most important communication 49 infrastructures. 51 In order to continue developing the new internet service and it 52 standardization, definitions of a number of new functions and 53 consensus for operation are necessary. They are not only in one 54 layer but are also related to many other layers. It is also 55 recommended that a large number of people from many fields such as 56 governments, administrations, carriers, operators, researchers and 57 developers are expected to attend this standardization activity. 59 The following two issues are the purpose of this memo. 61 1. To start discussion about the status of measures for the 62 emergency communications in each organization. 64 2. To start discussion about establishing the cooperation and 65 collaboration system about emergency communications in the world. 67 2. The internet in an emergency 69 In this chapter, we discuss and define some concepts in this memo. 71 2.1 In an emergency 73 In this memo, we define "in an emergency" as the situation that the 74 people and their life may be damaged by unexpected and dangerous 75 situation, such as natural disaster or accident. The special 76 operations are required to recover from the damages. For example, 77 when the big earthquake or flood occurs, many people are damaged, 78 some people may disappear, and rescues activities are required in 79 these circumstances. 81 2.2 The internet infrastructure in an emergency 83 The internet communication is a very good solution for data 84 transmission. Especially text data transmission using the internet 85 has long and sucessful history. Even if the communication quality 86 is insufficient and data transmission is often failed because of the 87 damage by the disaster, information exchange can be achieved because 88 it is possible to transmit small size of divided data over the 89 internet. The topology and routing mechanism of the internet add 90 redundancy to the internet. Therefore, if a part of lines is 91 damaged, transmitted data can bypass the point of failure and reach 92 to the destination. Generally, the natural disaster area severely 93 is restricted, however the communication infrastructure operates 94 normally outside of this area. 96 2.3 The internet services in an emergency 98 When a large-scale natural disaster occurs, disaster victims need to 99 exchange information with other victims or people outside disaster 100 area in a frequent manner. WWW and database services for publish 101 several information about disaster are required. 103 It SHOULD make use of the internet more effectively in an emergency, 104 it is required to make discussions and consensus at the IETF. 106 3. Internet technology in an emergency. 108 Some communication functions are necessary in an emergency stuation. 109 For example, victims' information exchange and the disaster 110 information transmission are necessary in the disaster area. As for 111 the internet, even these scenes play an important part of 112 communication function. And the internet MUST keep playing an 113 important role. 115 In this section, we describe the emergency communication support 116 system that we have being developing and evaluating, and priority 117 control on the emergency communications. And we have been insisting 118 its about the necessity to standardize many functions for the 119 emergency communications on the internet. 121 3.1 The emergency communication support system 123 WIDE(Widely Integrated Distributed Environment) project, a well- 124 known research consortium on the internet technology in Japan, has 125 been developing an emergency communication system called IAA (which 126 is named after "I am alive") since 1995. [1] This system consists of 127 various user interfaces and scalable and robust distributed database 128 system. It has already supported many actual recovery activities in 129 natural disaster in Japan. It provides registration and retrieval of 130 information for victims. 132 Since these systems are expected to prepare each country or each 133 organization, the function of an emergency information exchange is 134 required. The standards for an emergency information exchange model 135 and data exchange protocol for distributed database and usage of 136 metadata (structure data about data, it indicate contents of 137 information) are required. 139 3.2 The priority control on the emergency communications 141 It SHOULD give more priority to the emergency communications than 142 the usual communications. 144 The communication of an emergency is required with higher priority 145 than other communications. The priority control on the emergency 146 communications (voice data and multimedia communication) has been 147 discussed on some documents such as ITU-T E.106 and F.706 148 Recommendation.[3][4] 150 The priority control of the internet is required additional 151 considerations. The introduction of the data management scheme such 152 as using "metadata" may be necessary to indicate that the emergency 153 information SHOULD be processed immediately. 155 We MUST proceed with the standardization of the policy of the 156 priority control in the emergency communication. 158 4. Discussion 160 According to the discussion, we found many standardization 161 activities and consensus were needed across the several layers in 162 order to provide reliable internet services continuously in an 163 emergency. These functions described below are examples that 164 standardizations are required. 166 - Priority control policy 168 - Operation policy 170 - Victims information exchange model 172 - Victims information exchange protocol for distributed databases 174 - Some other mechanisms bridge over several independent emergency 175 communications systems 177 5. Milestones 179 Dec 01 Submit the first Internet-Draft of the emergency communications. 180 Dec 01 Meet at Salt Lake City as BOF to review the first Internet-Draft and discussion. 181 Mar 01 Submit the second Internet-Draft of the emergency communications. 182 Mar 01 Meet at Minneapolis as BOF to review the second Internet-Draft and discussion. 183 Jul 02 Meet at Yokohama to discussion. 185 6. Summary 187 We described necessarily of the emergency communications on the 188 internet and insist about the necessity to standardize many internet 189 functions in an emergency. 191 7. References 193 [1] Nobuhiko TADA, Yukimitsu IZAWA, Masahiko KIMOTO, Taro MARUYAMA, 194 Hiroyuki OHNO, Masaya NAKAYAMA, "IAA System (I Am Alive)": The 195 Experiences of the Internet Disaster Drills", INET'00, 2000, June. 197 [2] IAA system home pages, http://www.crl-iaa.net, 198 http://www.iaa.wide.ad.jp/ 200 [3] ITU-T Recommendation E.106 (2000), International Emergency 201 Preference Scheme (IEPS) 203 [4] ITU-T Recommendation F.706 (2001), International Emergency 204 Multimedia Services (IEMS) 206 8. Author's Address 208 Hiroyuki Ohno 209 Communications Research Laboratory 210 4-2-1 Nukui-kitamachi Koganei 211 Tokyo 184-8795 Japan 212 TEL: +1 81 42 327 5542 213 FAX: +1 81 42 327 7941 214 Email: hohno@ohnolab.org 216 Rei S. Atarashi 217 Communications Research Laboratory 218 4-2-1 Nukui-kitamachi Koganei 219 Tokyo 184-8795 Japan 220 TEL: +1 81 42 327 5542 221 FAX: +1 81 42 327 7941 222 Email: ray@ohnolab.org