idnits 2.17.00 (12 Aug 2021) /tmp/idnits64354/draft-polk-ecrit-dhc-emergency-dialstring-option-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 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 302. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'XXX' is mentioned on line 212, but not defined == Outdated reference: draft-ietf-ecrit-service-urn has been published as RFC 5031 ** Obsolete normative reference: RFC 3825 (Obsoleted by RFC 6225) == Outdated reference: draft-ietf-geopriv-dhcp-civil has been published as RFC 4676 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group James Polk 3 Internet-Draft Cisco Systems 4 Expires: Dec 19th, 2006 Brian Rosen 5 NeuStar 6 June 19th, 2006 8 A Dynamic Host Configuration Protocol Option for the 9 Locally Significant Emergency Calling Dialstring 10 draft-polk-ecrit-dhc-emergency-dialstring-option-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 19th, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document defines a new Dynamic Host Configuration Protocol 44 Option for a client to be able to request its locally significant 45 emergency dialstring from the local infrastructure. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1 Conventions Used in This Document . . . . . . . . . . . . 3 51 2. DHC Emergency Dialstring Option Format . . . . . . . . . . . 3 52 2.1 Rules of Usage of This Option . . . . . . . . . . . . . . 3 53 3. Open Questions Remaining . . . . . . . . . . . . . . . . . . 5 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 5 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 56 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 7.1 Normative References . . . . . . . . . . . . . . . . . 5 59 Author Information . . . . . . . . . . . . . . . . . . . . . 6 60 Intellectual Property and Copyright Statements . . . . . . . 6 62 1. Introduction 64 [ID-SOS] describes a universal emergency call URN to be used to 65 identify a call as an emergency call. This URN is not intended to 66 be dialed, but rather is to be used by the User Agent as an address. 67 The intention is to translate (as with any other dial plan) the 68 existing emergency dialstring to a URI that can be routed over the 69 Internet, or some subset thereof, to an appropriate Public Safety 70 Answering Point (PSAP) for the calling device. 72 In many countries, short codes are used as emergency dialstrings to 73 identify emergency calls. In others, a complete local telephone 74 number is needed. These dialstrings are locally specific, typically 75 by country, and may vary in length. In some countries, a single 76 dialstring is used ('999' is the dialstring for all emergency calls 77 in the United Kingdom). In other countries, there are different 78 dialstrings for different emergency services; '116' is the 79 dialstring for police in Switzerland, '117' is the dialstring for 80 fire. 82 Users are taught, often from a very early age, what the local 83 Dialstring(s) for emergency calls are, and it is not practical to 84 attempt to change the dialstring to a more uniform choice. When 85 using systems that permit roaming, local laws often require that 86 telephony systems recognize the local, or "visited", emergency 87 dialstring. 89 What is needed is a mechanism for a user agent (or other device that 90 can place emergency calls) to learn the local emergency 91 dialstring(s) so that a user agent can recognize an emergency call 92 when that numeric sequence is dialed by the user. This visited 93 emergency dialstring(s) may be displayed to the user on its screen 94 when learned by the device, if the phone has that capability. 96 This document defines a new Dynamic Host Configuration Protocol 97 Option [RFC2131] for a client to be able to request its locally 98 significant emergency dialstring(s) from the local infrastructure. 100 The previous version of this ID was 102 draft-polk-dhc-emergency-dialstring-option-00 104 The chairs of the two affected WGs concluded this topic should be 105 discussed in ECRIT, where the subject matter is closest, while DHC 106 will enforce compliance with DHC format rules. 108 1.1 Conventions Used in This Document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 111 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described 113 in [RFC2119]. 115 2. DHC Emergency Dialstring Option Format 117 The format for this Option is as follows: 119 0 1 2 3 120 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Code XXX | Length | Country Code + 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Service ID | Dialstring Digits + 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Dialstring Digits (cont'd) | | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 Figure 1. The Emergency Dialstring Option Format 131 Code = The IANA Assigned Option number 133 Length = This is a variable length value of the number of 134 bytes in the Option, including this length field. 136 Country Code = The two octet ISO country code. 138 Service Identifier = the one octet indication of type of dialstring 140 Dialstring = This is emergency dialstring digits, one per byte, to 141 a maximum of 16 digits. This is variable in length 142 based on the number of digits in the dialstring. 144 2.1 Rules of Usage of This Option 146 The following are the rules of usage of this DHCP Option: 148 - this option can be part of a message with other options, or it can 149 be the only option in the message. 151 - the maximum number of base10 digits is 16, to correspond with the 152 maximum known size of a dialstring in the circuit world. 154 - the minimum option length is 5 - for when only a country code is 155 sent. 157 - the minimum option length with a single digit emergency dialstring 158 present is 6. 160 - the country code and Service ID fields can be empty (null) in any 161 message, but are not deleted for any reason in this Option 163 - if the length field is 6, and the dialstring field value is 164 0x00000000, this means the base10 digit is '0', and should not be 165 considered an empty field 167 - if there is an emergency dialstring in the option, even if the 168 value is '0', a Service ID field left empty is equivalent to a 169 value of 0x00000000 or the general emergency service type of 170 urn:service:sos (i.e. not police-only, or fire-only). 172 - The maximum hex value for any one byte of dialstring value is 173 0x00001001 175 - A client requesting this option be returned from a server would 176 Accomplish this by sending this option in a DISCOVER, REQUEST or 177 INFORM message with a length field of 5, emulating a NULL 178 dialstring field value. 180 - If a request with a null country code is made to a DHCP server 181 which implements the [RFC3825] or [ID-CIVIC] options, and the 182 server can determine the location it returns or would have 183 returned for those options, then it MUST return the dialstrings 184 for the country for that location. 186 - If a request with a null country code is made to a DHCP server 187 which does not support [RFC3825] or [ID-CIVIC] or the server 188 cannot determine the location it returns or would have returned, 189 but it CAN unambiguously determine which country the requestor is 190 located in (perhaps because it only serves one country, or it can 191 determine based on the request and its knowledge of the network 192 topography and geography that it could only be in one country), 193 then it MUST return the dialstrings for that country. 195 - If a request with a null country code is made to a DHCP server 196 where neither of the above two conditions are met, the DHCP server 197 MUST return dialstrings for all countries the geography of the 198 local network covers. 200 - It is RECOMMENDED this request be in a REQUEST or INFORM message, 201 in which case the message is unicast to the server. 203 3. Open Questions Remaining 205 The following open questions are left to be answered based on 206 feedback during the review of this document: 208 - No open technical questions remain at this time 210 4. IANA Considerations 212 IANA has assigned a DHCP option code of [XXX] for the Emergency 213 Dialstring option defined in this document. 215 5. Security Considerations 217 Where critical decisions might be based on the value of this 218 emergency dialstring option, DHCP authentication in [RFC3118] SHOULD 219 be used to protect the integrity of the DHCP options. 221 Since there is no privacy protection for DHCP messages, an 222 eavesdropper who can monitor the link between the client and 223 destination DHCP server to capture any emergency dialstrings in 224 transit. While learning a publicly known emergency dialstring is 225 not a security risk, having that information altered in transit is a 226 security risk. 228 When implementing a DHC server that will serve clients across an 229 uncontrolled network, one should consider the potential security 230 risks. 232 6. Acknowledgements 234 To Jean-Francois Mule for his support of this effort. 236 7. References 238 7.1 Normative References 240 [ID-SOS] H. Schulzrinne, "A Uniform Resource Name (URN) for 241 Services", draft-ietf-ecrit-service-urn-03, "work in 242 progress", May 2006 244 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 245 March 1997. 247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 248 Requirement Levels", BCP 14, RFC 2119, March 1997. 250 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 251 Configuration Protocol Option for Coordinate-based Location 252 Configuration Information", RFC 3825, July 2004 254 [ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol 255 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 256 Information ", draft-ietf-geopriv-dhcp-civil-09, "work in 257 progress", January 2006 259 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 260 Messages", RFC 3118, June 2001. 262 Author's Address 264 James Polk 265 3913 Treemont Circle 266 Colleyville, Texas 76034 267 USA 269 Phone: +1-817-271-3552 270 Email: jmpolk@cisco.com 272 Brian Rosen 273 470 Conrad Dr. 274 Mars, PA 16046 275 US 277 Phone: +1 724 382 1051 278 Email: br@brianrosen.net 280 Intellectual Property Statement 282 The IETF takes no position regarding the validity or scope of any 283 Intellectual Property Rights or other rights that might be claimed 284 to pertain to the implementation or use of the technology described 285 in this document or the extent to which any license under such 286 rights might or might not be available; nor does it represent that 287 it has made any independent effort to identify any such rights. 288 Information on the procedures with respect to rights in RFC 289 documents can be found in BCP 78 and BCP 79. 291 Copies of IPR disclosures made to the IETF Secretariat and any 292 assurances of licenses to be made available, or the result of an 293 attempt made to obtain a general license or permission for the use 294 of such proprietary rights by implementers or users of this 295 specification can be obtained from the IETF on-line IPR repository 296 at http://www.ietf.org/ipr. 298 The IETF invites any interested party to bring to its attention any 299 copyrights, patents or patent applications, or other proprietary 300 rights that may cover technology that may be required to implement 301 this standard. Please address the information to the IETF at 302 ietf-ipr@ietf.org. 304 Disclaimer of Validity 306 This document and the information contained herein are provided on 307 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 308 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 309 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 310 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 311 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 312 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 314 Copyright Statement 316 Copyright (C) The Internet Society (2006). This document is subject 317 to the rights, licenses and restrictions contained in BCP 78, and 318 except as set forth therein, the authors retain all their rights. 320 Acknowledgment 322 Funding for the RFC Editor function is provided by the IETF 323 Administrative Support Activity (IASA).