idnits 2.17.00 (12 Aug 2021) /tmp/idnits50436/draft-polk-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 292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 282. ** 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 192, 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 ECRIT Working Group James Polk 3 Internet-Draft Cisco Systems 4 Expires: Aug 27th, 2006 Brian Rosen 5 NeuStar 6 Feb 27th, 2006 8 A Dynamic Host Configuration Protocol Option for the 9 Locally Significant Emergency Calling Dialstring 10 draft-polk-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 August 27th, 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 1. Introduction 49 [ID-SOS] describes a universal emergency call URN to be used to 50 identify a call as an emergency call. This URN is not intended to 51 be dialed, but rather is to be used by the User Agent as an address. 52 The intention is to translate (as with any other dial plan) the 53 existing emergency dialstring to the universal URN. 55 In many countries, short codes are used as emergency dialstrings to 56 identify emergency calls. In others, a complete local telephone 57 number is needed. These dialstrings are locally specific, typically 58 by country, and may vary in length. In some countries, a single 59 dialstring is used ('999' is the dialstring for all emergency calls 60 in the United Kingdom). In other countries, there are different 61 dialstrings for different emergency services; '116' is the 62 dialstring for police in Switzerland, '117' is the dialstring for 63 fire. 65 Users are taught, often from a very early age, what the local 66 dialstrings for emergency calls are, and it is not practical to 67 attempt to change the dialstring to a more uniform choice. When 68 using systems that permit roaming, local laws often require that 69 telephony systems recognize the local ("visited") emergency 70 dialstrings. 72 What is needed is a mechanism for a User Agent (or other device that 73 can place emergency calls) to learn the local emergency 74 dialstring(s) so that it can recognize an emergency call when that 75 numeric sequence is dialed by the user. This visited emergency 76 dialstring(s) may be displayed to the user in its screen when 77 learned, if the phone has that capability. 79 This document defines a new Dynamic Host Configuration Protocol 80 Option [RFC2131] for a client to be able to request its locally 81 significant emergency dialstring(s) from the local infrastructure. 83 1.1 Conventions Used in This Document 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 86 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described 88 in [RFC2119]. 90 2. DHC Emergency Dialstring Option Format 92 The format for this Option is as follows: 94 0 1 2 3 95 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 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Code XXX | Length | Country Code + 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Service ID | Dialstring Digits + 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | Dialstring Digits (cont'd) | | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 Figure 1. The Emergency Dialstring Option Format 106 Code = The IANA Assigned Option number 108 Length = This is a variable length value of the number of 109 bytes in the Option, including this length field. 111 Country Code = The two octet ISO country code. 113 Service Identifier = the one octet indication of type of dialstring 115 Dialstring = This is emergency dialstring digits, one per byte, to 116 a maximum of 16 digits. This is variable in length 117 based on the number of digits in the dialstring. 119 2.1 Rules of Usage of This Option 121 The following are the rules of usage of this DHCP Option: 123 - this option can be part of a message with other options, or it can 124 be the only option in the message. 126 - the maximum number of base10 digits is 16, to correspond with the 127 maximum known size of a dialstring in the circuit world. 129 - the minimum option length is 5, 131 - the minimum option length with a single digit emergency dialstring 132 present is 6 134 - the country code and Service ID fields can be empty (null) in any 135 message, but are not deleted for any reason in this Option 137 - if the length field is 6, and the dialstring field value is 138 0x00000000, this means the base10 digit is '0', and should not be 139 considered an empty field 141 - if there is an emergency dialstring in the option, even if the 142 value is '0', a Service ID field left empty is equivalent to a 143 value of 0x00000000 or the general emergency service type of 144 urn:service:sos (i.e. not police only, or fire only). 146 - The maximum hex value for any one byte of dialstring value is 147 0x00001001 149 - A client requesting this option be returned from a server would be 150 accomplished by sending this option in a DISCOVER, REQUEST or 151 INFORM message with a length field of 5, emulating a NULL 152 dialstring field value. 154 - If a request with a null country code is made to a DHCP server 155 which implements the [RFC3825] or [ID-CIVIC] options, and the 156 server can determine the location it returns or would have 157 returned for those options, then it MUST return the dialstrings 158 for the country for that location. 160 - If a request with a null country code is made to a DHCP server 161 which does not support [RFC3825] or [ID-CIVIC] or the server 162 cannot determine the location it returns or would have returned, 163 but it CAN unambiguously determine which country the requestor is 164 located in (perhaps because it only serves one country, or it can 165 determine based on the request and its knowledge of the network 166 topography and geography that it could only be in one country), 167 then it MUST return the dialstrings for that country. 169 - If a request with a null country code is made to a DHCP server 170 where neither of the above two conditions are met, the DHCP server 171 MUST return dialstrings for all countries the geography of the 172 local network covers. 174 - It is RECOMMENDED this request be in a REQUEST or INFORM message, 175 in which case the message is unicast to the server 177 - it is currently not envisioned why a non-empty option would be 178 sent from a client to server. 180 3. Open Questions 182 The following open questions are left to be answered based on 183 feedback during the review of this document: 185 - Using octets for dialable numbers with a maximum range of 16 is a 186 waste of space. It would be possible to use a more compact form 187 of representation, from a long integer to three hex digits per 188 octet. 190 4. IANA Considerations 192 IANA has assigned a DHCP option code of [XXX] for the Emergency 193 Dialstring option defined in this document. 195 5. Security Considerations 197 Where critical decisions might be based on the value of this 198 emergency dialstring option, DHCP authentication in [RFC3118] SHOULD 199 be used to protect the integrity of the DHCP options. 201 Since there is no privacy protection for DHCP messages, an 202 eavesdropper who can monitor the link between the client and 203 destination DHCP server to capture any emergency dialstrings in 204 transit. While learning a publicly known emergency dialstring is 205 not a security risk, having that information altered in transit is a 206 security risk. 208 When implementing a DHC server that will serve clients across an 209 uncontrolled network, one should consider the potential security 210 risks. 212 6. Acknowledgements 214 Your name here... 216 7. References 218 7.1 Normative References 220 [ID-SOS] H. Schulzrinne, "A Uniform Resource Name (URN) for 221 Services", draft-ietf-ecrit-service-urn-00, "work in 222 progress", January 2006 224 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 225 March 1997. 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, March 1997. 230 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 231 Configuration Protocol Option for Coordinate-based Location 232 Configuration Information", RFC 3825, July 2004 234 [ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol 235 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 236 Information ", draft-ietf-geopriv-dhcp-civil-09, "work in 237 progress", January 2006 239 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 240 Messages", RFC 3118, June 2001. 242 Author's Address 244 James M. Polk 245 3913 Treemont Circle 246 Colleyville, Texas 76034 247 USA 249 Phone: +1-817-271-3552 250 Email: jmpolk@cisco.com 252 Brian Rosen 253 470 Conrad Dr. 254 Mars, PA 16046 255 US 257 Phone: +1 724 382 1051 258 Email: br@brianrosen.net 260 Intellectual Property Statement 262 The IETF takes no position regarding the validity or scope of any 263 Intellectual Property Rights or other rights that might be claimed 264 to pertain to the implementation or use of the technology described 265 in this document or the extent to which any license under such 266 rights might or might not be available; nor does it represent that 267 it has made any independent effort to identify any such rights. 268 Information on the procedures with respect to rights in RFC 269 documents can be found in BCP 78 and BCP 79. 271 Copies of IPR disclosures made to the IETF Secretariat and any 272 assurances of licenses to be made available, or the result of an 273 attempt made to obtain a general license or permission for the use 274 of such proprietary rights by implementers or users of this 275 specification can be obtained from the IETF on-line IPR repository 276 at http://www.ietf.org/ipr. 278 The IETF invites any interested party to bring to its attention any 279 copyrights, patents or patent applications, or other proprietary 280 rights that may cover technology that may be required to implement 281 this standard. Please address the information to the IETF at 282 ietf-ipr@ietf.org. 284 Disclaimer of Validity 286 This document and the information contained herein are provided on 287 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 288 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 289 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 290 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 291 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 292 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 294 Copyright Statement 296 Copyright (C) The Internet Society (2006). This document is subject 297 to the rights, licenses and restrictions contained in BCP 78, and 298 except as set forth therein, the authors retain all their rights. 300 Acknowledgment 302 Funding for the RFC Editor function is currently provided by the 303 Internet Society.