idnits 2.17.1 draft-stastny-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 163. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 140. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 147. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 153. ** 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: ---------------------------------------------------------------------------- == 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 Introduction 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 12, 2005) is 6985 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: 8 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ecrit R. Stastny 3 Internet-Draft OeFEG 4 Expires: August 16, 2005 B. Rosen 5 Emergicom 6 February 12, 2005 8 The basic requirements for emergency services via the Internet 9 draft-stastny-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 16, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 We present a short list of the basic requirements for emergency 45 services via the Internet. 47 Table of Contents 49 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 50 2. MUST Requirements . . . . . . . . . . . . . . . . . . . . . . 4 51 3. SHOULD Requirements . . . . . . . . . . . . . . . . . . . . . 5 52 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 53 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 55 Intellectual Property and Copyright Statements . . . . . . . . 7 57 1. Requirements notation 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in [RFC2119]. 63 2. MUST Requirements 65 M1. From any with the Internet connected device it MUST be possible 66 at any time to contact the ECC responsible for the current 67 location with the most appropriate method for communication for 68 the user and the device. 69 M2. The possibility to make contact to the proper ECC has to be 70 verified and indicated to the user and/or the User Agent. 71 M3. The communication may be established on user request or by 72 external events. 73 M4. To achieve this, the device MUST be able to retrieve its current 74 location from the access provider, from the infrastructure, via 75 GPS, ... or as last resort, from the user itself. 76 M5. The capability to locate the responsible ECC must be available 77 in the public Infrastructure without the additional need for a 78 service provider. 79 M6. For a transient time the device and the UA may use the help of 80 servers (e.g. ESRP) to provide the connectivity to ECC, 81 especially for ECC not yet connected to the Internet. 83 3. SHOULD Requirements 85 S1. Transmission of the current location of the contacting device to 86 the ECC 87 S2. Capability to re-contact the contacting device from the ECC in 88 case of disruption or later query for a tbd period of time. 89 This should also be possible from conventional ECC via temporary 90 (virtual) E.164 numbers 91 S3. Identification of the contacting person or device 92 S4. Safeguards to protect the emergency infrastructure and ECC 93 facilities against malicious attacks, especially to prevent DoS 94 attacks. 95 S5. Provide all possible means of communication, not only speech, 96 but also text (IM), Video, etc., (for disabled persons and 97 better display of the situation) 98 S6. Capabilities to contact ECC by automatic means and for the 99 transfer of additional information (alarm equipment, cars, 100 buses, trucks with dangerous loads, ...) 102 4. Security Considerations 104 None. 106 5. References 108 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 109 Requirement Levels", BCP 14, RFC 2119, March 1997. 111 Authors' Addresses 113 Richard Stastny 114 OeFEG 115 Postbox 147 116 Vienna 1103 117 AU 119 Phone: +43-664-420-4100 120 Email: Richard.Stastny@oefeg.at 122 Brian Rosen 123 Emergicom 124 470 Conrad Dr 125 Mars, PA 16046 126 US 128 Phone: +1 724 382 1051 129 Email: br@brianrosen.net 131 Intellectual Property Statement 133 The IETF takes no position regarding the validity or scope of any 134 Intellectual Property Rights or other rights that might be claimed to 135 pertain to the implementation or use of the technology described in 136 this document or the extent to which any license under such rights 137 might or might not be available; nor does it represent that it has 138 made any independent effort to identify any such rights. Information 139 on the procedures with respect to rights in RFC documents can be 140 found in BCP 78 and BCP 79. 142 Copies of IPR disclosures made to the IETF Secretariat and any 143 assurances of licenses to be made available, or the result of an 144 attempt made to obtain a general license or permission for the use of 145 such proprietary rights by implementers or users of this 146 specification can be obtained from the IETF on-line IPR repository at 147 http://www.ietf.org/ipr. 149 The IETF invites any interested party to bring to its attention any 150 copyrights, patents or patent applications, or other proprietary 151 rights that may cover technology that may be required to implement 152 this standard. Please address the information to the IETF at 153 ietf-ipr@ietf.org. 155 Disclaimer of Validity 157 This document and the information contained herein are provided on an 158 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 159 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 160 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 161 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 162 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 163 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 165 Copyright Statement 167 Copyright (C) The Internet Society (2005). This document is subject 168 to the rights, licenses and restrictions contained in BCP 78, and 169 except as set forth therein, the authors retain all their rights. 171 Acknowledgment 173 Funding for the RFC Editor function is currently provided by the 174 Internet Society.