idnits 2.17.00 (12 Aug 2021) /tmp/idnits52428/draft-rosen-nena-geopriv-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 185. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 162. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 169. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 175. ** 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 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: 8 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 geopriv B. Rosen 3 Internet-Draft Emergicom 4 Expires: August 19, 2005 N. Abbott 5 Telcordia 6 February 15, 2005 8 NENA Requirements for Extensions to PIDF-LO 9 draft-rosen-nena-geopriv-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. In our efforts to support emergency calls coming over 48 the Internet, we have identified several issues with the present 49 definition of the PIDF-LO object. We present our requirements to 50 address these shortcomings. 52 Table of Contents 54 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 55 2. Additional Requirements . . . . . . . . . . . . . . . . . . . 4 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 57 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 59 Intellectual Property and Copyright Statements . . . . . . . . 7 61 1. Requirements notation 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC2119]. 67 2. Additional Requirements 69 Req-1: When location is forged, responder resources are 70 inappropriately dispatched. The location must be 71 authenticated by its source and verified by the PSAP. This 72 implies a digital signature on the location object. There are 73 implications when location is presented to an entity in a form 74 other than PIDF-LO. For example, if an endpoint learns its 75 location from DHCP, the source of the location must sign it in 76 such a way that it can be transported by DHCP, converted to 77 PIDF-LO, transported by a using protocol, and subsequently 78 have the digital signature validated. 79 Req-2: If there is more than one set of location information is 80 provided in the PIDF-LO, guidelines/policy are needed to 81 assist in selecting the appropriate location information to be 82 used for emergency call routing and dispatch. 83 Req-3: Two community names must be supported (postal and legal). 84 Req-4: The "DateTimeStamp" defined in PIDF-LO is insufficient for our 85 needs. We need to know when the location was determined. 86 That may or not be when the PIDF-LO document was created. 87 Req-5: Confidence and Uncertainty must be expanded. Two single 88 component values are proving to be insufficient. We will 89 bring a proposal to improve the ability to specify these 90 quantities. 91 Req-6: "Placetype" must be expanded (does this really need to go to 92 SIMPLE?) 93 Req-7: If there is more than one set of location information is 94 provided in the PIDF-LO, guidelines/policy are needed to 95 assist in selecting the appropriate location information to be 96 used for emergency call routing and dispatch. 97 Req-8: It is desirable to have fall-back location information that 98 can be used to determine default routing of emergency calls 99 (e.g., if the specific location information is not currently 100 represented in the available routing data base). 101 Req-9: Other information, e.g., associated with the "caller" or the 102 caller's location, may also be useful to the emergency 103 responder, but which is more appropriately maintained by the 104 user, than by a provider of physical, geographical location 105 information. A mechanism to include or refer to such 106 additional information is needed. (This may really need to be 107 considered by SIMPLE?) However, such information may need to 108 build on the privacy mechanisms defined by Geopriv for 109 location information. For example, emergency responders today 110 may have access to information about disabilities of potential 111 callers in a particular location that will assist emergency 112 responders in taking special response measures. Examples of 113 the kind of information that might be helpful include: 115 * Life Support System in use 116 * Oxygen in use 117 * Mobility Impaired 118 * Blind 119 * Hearing Impaired 120 * Teletypwriter 121 * Speech Impaired 122 * Developmentally disabled.. 124 3. Security Considerations 126 None. 128 4. References 130 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 131 Requirement Levels", BCP 14, RFC 2119, March 1997. 133 Authors' Addresses 135 Brian Rosen 136 Emergicom 137 470 Conrad Dr 138 Mars, PA 16046 139 US 141 Phone: +1 724 382 1051 142 Email: br@brianrosen.net 144 Nadine Abbott 145 Telcordia 146 One Telcordia Drive, Room 4B655 147 Piscataway, NJ 08854 148 US 150 Phone: +1-732-699-6109 151 Email: nabbott@telcordia.com 153 Intellectual Property Statement 155 The IETF takes no position regarding the validity or scope of any 156 Intellectual Property Rights or other rights that might be claimed to 157 pertain to the implementation or use of the technology described in 158 this document or the extent to which any license under such rights 159 might or might not be available; nor does it represent that it has 160 made any independent effort to identify any such rights. Information 161 on the procedures with respect to rights in RFC documents can be 162 found in BCP 78 and BCP 79. 164 Copies of IPR disclosures made to the IETF Secretariat and any 165 assurances of licenses to be made available, or the result of an 166 attempt made to obtain a general license or permission for the use of 167 such proprietary rights by implementers or users of this 168 specification can be obtained from the IETF on-line IPR repository at 169 http://www.ietf.org/ipr. 171 The IETF invites any interested party to bring to its attention any 172 copyrights, patents or patent applications, or other proprietary 173 rights that may cover technology that may be required to implement 174 this standard. Please address the information to the IETF at 175 ietf-ipr@ietf.org. 177 Disclaimer of Validity 179 This document and the information contained herein are provided on an 180 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 181 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 182 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 183 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 184 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 185 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 187 Copyright Statement 189 Copyright (C) The Internet Society (2005). This document is subject 190 to the rights, licenses and restrictions contained in BCP 78, and 191 except as set forth therein, the authors retain all their rights. 193 Acknowledgment 195 Funding for the RFC Editor function is currently provided by the 196 Internet Society.