idnits 2.17.00 (12 Aug 2021) /tmp/idnits6209/draft-ietf-geopriv-dhcp-civil-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 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.) ** There are 12 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 151 has weird spacing: '... CAtype label...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 27, 2003) is 6903 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) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 Internet Draft H. Schulzrinne 4 Columbia U. 5 draft-ietf-geopriv-dhcp-civil-00.txt 6 June 27, 2003 7 Expires: December 2003 9 DHCP Option for Civil Location 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document specifies a Dynamic Host Configuration Protocol option 35 for the civil (country, street and community) location of the client. 37 1 Terminology 39 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 40 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 41 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and 42 indicate requirement levels for compliant implementations. 44 2 Introduction 46 Many end system services can benefit by knowing the approximate 47 location of the end device. In particular, IP telephony devices need 48 to know their location to contact the appropriate emergency response 49 agency and to be found by emergency responders. 51 There are two common ways to identify the location of an object, 52 either through geospatial coordinates or by so-called civil 53 coordinates. Geospatial coordinates indicate longitude, latitude and 54 altitude, while civil coordinates indicate a street address. 56 This is commonly, but not necessearily, closely related to 57 the postal address, used by the local postal service to 58 deliver mail. However, not all postal addresses correspond 59 to street addresses. For example, the author's address is a 60 postal address that does not appear on any street or 61 building sign. Naturally, post office boxes would be 62 unsuitable for the purposes described here. 64 A related draft [8] describes a DHCP [2] option for conveying 65 geospatial information to a device. This draft describes how DHCP can 66 be used to convey the civil location to devices. Both can be used 67 simultaneously, increasing the chance to deliver accurate and timely 68 location information to emergency responders. 70 End systems that obtain location information via the mechanism 71 described here then use other protocol mechanisms to communicate this 72 information to the emergency call center. 74 Civil information is useful since it often provides additional, 75 human-usable information particularly within buildings. Also, 76 compared to geospatial information, it is readily obtained for most 77 occupied structures and can often be interpreted even if incomplete. 79 For example, for many large university or corporate campuses, 80 geocoding information to building and room granularity may not be 81 readily available. 83 Unlike geospatial information, the format for civil information 84 differs from country to country. Thus, this draft establishes an IANA 85 registry for civil location data fields. The initial set of data 86 fields is derived from standards published by the United States 87 National Emergency Numbering Association (NENA) [3]. It is 88 anticipated that other countries can reuse many of the data elements. 90 3 Format of the DHCP Civil Location Option 92 0 1 2 3 93 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 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Code TBD | N | Countrycode | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | What | civil address elements ... 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 Each civil address element has the following format: 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | CAtype | CAlength | CAvalue ... 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 Code TBD: The code for this DHCP option is TBD by IANA. 110 N: The length of this option is variable. 112 Countrycode: The two-letter ISO country code in capital ASCII 113 letter, e.g., DE or US. 115 What: The 'what' element describes which location the DHCP 116 refers to. Currently, three options are defined: the 117 location of the DHCP server (0), the location of the 118 network element believed to be closest to the client (1) or 119 the location of the client (2). Option (2) SHOULD be used, 120 but may not be known. Options (1) and (2) SHOULD NOT be 121 used unless it is known that the DHCP client is in close 122 physical proximity to the server or network element. 124 In some cases, the local wiring plant makes it 125 difficult to ascertain the device location with 126 certainty. In that case, it is still preferable to 127 indicate the DHCP server, Ethernet switch or router, 128 but indicate the uncertainty. This avoids that the 129 emergency responders try to break into the LAN closet. 131 CAtype: A one-octet descriptor of the data civil address value. 133 CAlength: The length, in octets, of the CAvalue, not including 134 the CAlength field itself. Data SHOULD be encoded in 135 uppercase. 137 CAvalue: The civil address value, encoded as UTF-8, and written 138 in uppercase letters where applicable. 140 4 Civil Address Components 142 Since each country has different administrative hierarchies, with 143 often the same (English) names, this specification adopts a simple 144 hierarchical notation that is then instantiated for each country. We 145 assume that five levels are sufficient for sub-national divisions 146 above the street level. 148 All elements are OPTIONAL and can appear in any order. Abbreviations 149 do not need a trailing period. 151 CAtype label description 152 ___________________________________________________________________________ 153 1 A1 national subdivisions (state, region, province, prefecture) 154 2 A2 county, parish, gun (JP), district (IN) 155 3 A3 city, township, shi (JP) 156 4 A4 city division, borough, city district, ward, chou (JP) 157 5 A5 neighborhood, block 158 6 A6 street 160 For specific countries, the administrative sub-divisions are 161 described below. 163 US: The mapping to NENA designations is shown in parentheses. 164 A1=state (STA), using the the two-letter state and 165 possession abbreviations recommended by the United States 166 Postal Service Publication 28 [4], Appendix B; A2=county 167 (CNA); A3=civil community name (city or town) (MCN); 168 A6=street (STN). A4 and A5 are not used. The civil 169 community name (MCN) reflects the political boundaries. 170 These may differ from postal delivery assignments for 171 historical or practical reasons. 173 CA: The mapping to NENA designations is shown in parentheses. 174 A1=province (STA), A2=county (CNA), A3=city or town (MCN). 176 JP: A1=metropolis (To, Fu) or prefecture (Ken, Do); A2=city 177 (Shi) or rural area (Gun); A3=ward (Ku) or village (Mura); 178 A4=town (Chou or Machi); A5=city district (Choume); 179 A6=block (Banchi or Ban). 181 DE: A1=state (Bundesstaat); A2=county (Kreis); A3=city (Stadt, 182 Gemeinde); A6=street (Strasse). 184 Additional CA types appear in many countries and are simply omitted 185 where they are not used: 187 CAtype NENA description examples 188 ___________________________________________________________________________ 189 16 PRD leading street direction N 190 17 POD trailing street suffix SW 191 18 STS street suffix AVE, PLATZ 192 19 HNO house number 123 193 20 HNS house number suffix A, 1/2 194 21 LMK landmark or vanity address SHADELAND CRESCENT APTS 195 22 LOC additional location information APT 17 196 23 NAM name (residence and office occupant) JOE'S BARBERSHOP 197 24 ZIP postal/zip code 10027-1234 198 25 type of place 199 26 privacy 201 The CA types labeled in the second column correspond to items from 202 the NENA "Recommended Formats & Protocols For ALI Data Exchange, ALI 203 Response & GIS Mapping" [3], but are applicable to most countries. 204 The "NENA" column refers to the data dictionary name in Exhibit 18 of 205 [3]. 207 The NAM object is used to aid user location ("Joe Miller" "Alice's 208 Dry Cleaning"). It does not identify the person using a 209 communications device, but rather the person or organization 210 associated with the address. 212 For POD and PRD, in English-speaking countries, the abbreviations N, 213 E, S, W, and NE, NW, SE, SW should be used. 215 STS designates a street suffix. In the United States (US), the 216 abbreviations recommended by the United States Postal Service 217 Publication 28 [4], Appendix C, SHOULD be used. 219 The "type of place" item indicates whether the location is a 'home', 220 be registered with IANA and correspond to the "placetype" element in 221 [5]. 223 The "privacy" object can have the string values 225 public: Others may be able to see or hear the communications. 227 private: Inappropriate individuals are not likely to see or hear 228 the communications. 230 quiet: The location is a place such as a library, restaurant, 231 place-of-worship, or theater that discourages noise, 232 conversation and other distractions. 234 Additional string values can be registered with IANA using the 235 registry established in [5]. 237 The DHCP long-options mechanism described in RFC 3396 [6] MUST be 238 used if the civil address option exceeds the maximum DHCP option size 239 of 255 octets. 241 5 Security Considerations 243 The information in this option may be used for a variety of tasks. In 244 some cases, integrity of the information may be of great importance. 245 In such cases, DHCP authentication in [7] SHOULD be used to protect 246 the integrity of the DHCP options. 248 6 Acknowledgments 250 Rohan Mahy and Stefan Berger provided helpful comments. 252 7 References 254 8 Normative References 256 [1] S. Bradner, "Key words for use in RFCs to indicate requirement 257 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 259 [2] R. E. Droms, "Dynamic host configuration protocol," RFC 2131, 260 Internet Engineering Task Force, Mar. 1997. 262 [3] National Emergency Number Assocation (NE, "NENA recommended 263 formats & protocols for ALI data exchange, ALI response & GIS 264 mapping," Standard NENA-02-010, NENA, Washington, DC, Jan. 2002. 266 [4] U. S. P. Service, "Postal addressing standards," Publication 28, 267 USPS, Washington, DC, Nov. 2000. 269 [5] H. Schulzrinne et al., "RPIDS -- rich presence information data 270 format for presence based on the session initiation protocol (SIP)," 271 internet draft, Internet Engineering Task Force, Feb. 2003. Work in 272 progress. 274 [6] T. Lemon and S. Cheshire, "Encoding long options in the dynamic 275 host configuration protocol (dhcpv4)," RFC 3396, Internet Engineering 276 Task Force, Nov. 2002. 278 [7] R. E. Droms and W. Arbaugh, eds., "Authentication for DHCP 279 messages," RFC 3118, Internet Engineering Task Force, June 2001. 281 9 Informative References 283 [8] J. Polk et al., "DHCP option for geographic location," Internet 284 Draft, Internet Engineering Task Force, Oct. 2002. Work in progress. 286 10 Authors' Addresses 288 Henning Schulzrinne 289 Dept. of Computer Science 290 Columbia University 291 1214 Amsterdam Avenue 292 New York, NY 10027 293 USA 294 electronic mail: schulzrinne@cs.columbia.edu 296 The IETF takes no position regarding the validity or scope of any 297 intellectual property or other rights that might be claimed to 298 pertain to the implementation or use of the technology described in 299 this document or the extent to which any license under such rights 300 might or might not be available; neither does it represent that it 301 has made any effort to identify any such rights. Information on the 302 IETF's procedures with respect to rights in standards-track and 303 standards-related documentation can be found in BCP-11. Copies of 304 claims of rights made available for publication and any assurances of 305 licenses to be made available, or the result of an attempt made to 306 obtain a general license or permission for the use of such 307 proprietary rights by implementors or users of this specification can 308 be obtained from the IETF Secretariat. 310 The IETF invites any interested party to bring to its attention any 311 copyrights, patents or patent applications, or other proprietary 312 rights which may cover technology that may be required to practice 313 this standard. Please address the information to the IETF Executive 314 Director. 316 This document and translations of it may be copied and furnished to 317 others, and derivative works that comment on or otherwise explain it 318 or assist in its implmentation may be prepared, copied, published and 319 distributed, in whole or in part, without restriction of any kind, 320 provided that the above copyright notice and this paragraph are 321 included on all such copies and derivative works. However, this 322 document itself may not be modified in any way, such as by removing 323 the copyright notice or references to the Internet Society or other 324 Internet organizations, except as needed for the purpose of 325 developing Internet standards in which case the procedures for 326 copyrights defined in the Internet Standards process must be 327 followed, or as required to translate it into languages other than 328 English. 330 The limited permissions granted above are perpetual and will not be 331 revoked by the Internet Society or its successors or assigns. 333 This document and the information contained herein is provided on an 334 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 335 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 336 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 337 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 338 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 340 Table of Contents 342 1 Terminology ......................................... 2 343 2 Introduction ........................................ 2 344 3 Format of the DHCP Civil Location Option ............ 3 345 4 Civil Address Components ............................ 4 346 5 Security Considerations ............................. 6 347 6 Acknowledgments ..................................... 6 348 7 References .......................................... 6 349 8 Normative References ................................ 6 350 9 Informative References .............................. 7 351 10 Authors' Addresses .................................. 7