idnits 2.17.00 (12 Aug 2021) /tmp/idnits58536/draft-tschofenig-geopriv-dhcp-circle-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 345. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 369. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (February 18, 2008) is 5206 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) == Outdated reference: draft-ietf-geopriv-pdif-lo-profile has been published as RFC 5491 ** Obsolete normative reference: RFC 3825 (Obsoleted by RFC 6225) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-19107' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-754-1985' Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Geopriv H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track J. Winterbottom 5 Expires: August 21, 2008 Andrew Corporation 6 February 18, 2008 8 Specifying a Circular Uncertainty Area Using DHCP 9 draft-tschofenig-geopriv-dhcp-circle-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document specifies how a circular area representing the location 43 of device can be returned using DHCP. The document also shows how 44 the data returned from DHCP can be encoded into GML for using in a 45 PIDF-LO in an unambiguous or contentious manner. 47 This document is a contribution to the ongoing discussion on RFC 48 3825; it represents one possible solution to address the discussed 49 issues. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Details and Rationale . . . . . . . . . . . . . . . . . . . . 5 56 3.1. DHCPv4 Option for a Circular Location . . . . . . . . . . 5 57 3.2. DHCPv6 Option for a LIS Address . . . . . . . . . . . . . 6 58 4. Expressing the Circle in GML . . . . . . . . . . . . . . . . . 8 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 62 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 64 Intellectual Property and Copyright Statements . . . . . . . . . . 15 66 1. Introduction 68 Location provided by GPS device and like generally provide location 69 information as a point with a degree of uncertainty. This 70 uncertainty is more often than not expressed as an offset in metres 71 from the central point, with the resulting location being a circle 72 when expressed in 2 dimensions, and a sphere when expressed in 3 73 dimensions. This memo presupposes that locations have been measured, 74 for example using a GPS, ahead of time and have subsequently been 75 stored in a wiremap database. Associations between end-devices and 76 location can be done using DHCP option 82 or other methods where 77 appropriate. 79 This document omits an altitude representation based on the 80 envisioned usage scenario. 82 2. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 3. Details and Rationale 90 The intent of this specification is to provide a location to an end- 91 device so that it can easily represent it as circle in GML in 92 accordance with PIDF-LO Profile [I-D.ietf-geopriv-pdif-lo-profile]. 93 PIDF-LO Profile relies on geoshape [geoshape] requires all 94 coordinates to be specified using WGS-84, consequently the 95 coordinates used in this memo are specified using WGS-84. 97 GML [gml] uses the ISO 19107 [ISO-19107] definition of a point, and 98 quotes this as being "0-dimensional geometric primitive, representing 99 a position. NOTE The boundary of a point is the empty set." At some 100 point however, it becomes necessary to express the coordinates that 101 make up the location in bits and bytes. Since the intent is to use 102 GML as the final representation, the encoding standards and 103 limitations expressed by GML are used. 105 GML is an XML language [xml] for expressing location information, and 106 XML defines mappings between its primative types and standard binary 107 encodings. The GML point is made up of XML (xsd) doubles, and an XML 108 double is expressed as an IEEE 754-1985 [IEEE-754-1985] double- 109 precision floating point number. This means that a latitude or 110 longitude in GML is expressed as a 64 bit binary number, but in 111 accordance with the previous definition is interpretted as being zero 112 dimensional, without area. 114 The binary encodings provided in this memo express latitude and 115 longitude values as 64 bit binary floating-point numbers, as defined 116 in [IEEE-754-1985]. A radius is defined as a positive offset to this 117 in metres, and is expressed as an unsigned 16 bit integer. This 118 allows a circle with a radius in the order of 65.5km to be expressed 119 without difficulty, and for a point with no specified uncertainty to 120 be provided where the radius is set to zero. 122 3.1. DHCPv4 Option for a Circular Location 124 This section defines a DHCP for IPv4 (DHCPv4) option for the point 125 with radius of uncertainty. 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | LOC-CIRCLE | Length | Latitude | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Latitude continued | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Latitude Continued | Longitude | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Longitude continued | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Longitude Continued | Radius | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 DHCPv4 Option 143 LOC-CIRCLE: The IANA assigned option number (TBD). 145 Length: The length of this option octets (18). 147 Latitude: 8 octets representing the the latitude of the central 148 point of a circle, expressed as an [IEEE-754-1985] double. 150 Longitude: 8 octets representing the the longitude of the central 151 point of a circle, expressed as an [IEEE-754-1985] double. 153 Radius: a 16 bit unsigned integer expressing the radius of the 154 circle in metres. 156 3.2. DHCPv6 Option for a LIS Address 158 This section defines a DHCP for IPv6 (DHCPv6) option for the point 159 with radius of uncertainty. The DHCPv6 option for this parameter is 160 similarly formatted to the DHCPv4 option. 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | LOC-CIRCLE | Length | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Latitude | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Latitude continued | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Longitude | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Longitude continued | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Radius | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 DHCPv6 Option 180 LOC-CIRCLE: The IANA assigned option number (TBD). 182 Length: The length of this option in octets (18). 184 Latitude: 8 octets representing the the latitude of the central 185 point of a circle, expressed as an [IEEE-754-1985] double. 187 Longitude: 8 octets representing the the longitude of the central 188 point of a circle, expressed as an [IEEE-754-1985] double. 190 Radius: a 16 bit unsigned integer expressing the radius of the 191 circle in metres. 193 4. Expressing the Circle in GML 195 PIDF-LO Profile [I-D.ietf-geopriv-pdif-lo-profile] describes how a 196 circle is expressed in GML and included in a PIDF-LO [RFC4119]. The 197 latitude and longitude components of this encoding form the central 198 point of the circle. 200 _d^^^^^^^^^b_ 201 .d'' ``b. 202 .p' / `q. 203 .d' Radius-> / `b. 204 .d' / `b. 205 :: / :: 206 :: C :: 207 :: ^ :: 208 `p. | .q' 209 `p. Centre .q' 210 `b. .d' 211 `q.. ..p' 212 ^q.........p^ 214 Figure 3: Circle Representation 216 The XML for the resulting circle is shown in Figure 4 (assuming the 217 centre is represented as 42.5463 -73.2512) and the radius is 5 218 meters. 220 221 227 228 229 230 231 232 233 42.5463 -73.2512 234 235 236 5 237 238 239 240 241 DHCP 242 243 244 245 247 Figure 4: Resulting XML and PIDF-LO 249 5. Security Considerations 251 The security issues for this document are the same as for RFC3825 252 [RFC3825]. 254 6. IANA Considerations 256 There are no specific IANA considerations for this document. 258 7. Acknowledgements 260 The authors contribute this document to the ongoing discussion in the 261 GEOPRIV working group. Still, the authors believe that it would be 262 necessary to investigate the intended deployment use cases more in 263 order to evaluate what additional location shapes are likely to be 264 used and whether there is interest in using DHCP (or lower layer 265 protocols developed by the IEEE or TIA) for conveying location 266 information or whether there is more interest to use these protocols 267 purely to discover a LIS and allow more flexibility with regard to 268 the supported location shapes. 270 8. Normative References 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, March 1997. 275 [I-D.ietf-geopriv-pdif-lo-profile] 276 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 277 PIDF-LO Usage Clarification, Considerations and 278 Recommendations", draft-ietf-geopriv-pdif-lo-profile-10 279 (work in progress), October 2007. 281 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 282 Format", RFC 4119, December 2005. 284 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 285 Configuration Protocol Option for Coordinate-based 286 Location Configuration Information", RFC 3825, July 2004. 288 [geoshape] 289 Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape 290 Application Schema for use by the Internet Engineering 291 Task Force (IETF)", Candidate OpenGIS Implementation 292 Specification 06-142r1, Version: 1.0, April 2007. 294 [ISO-19107] 295 ISO, "Geographic information - Spatial Schema", ISO 296 Standard 19107, First Edition, 5 2003. 298 [gml] Cox, S., Daisey, P., Lake, R., Portele, C., and A. 299 Whiteside, "Geographic information - Geography Markup 300 Language (GML)", OpenGIS 03-105r1, April 2004, 301 . 304 [xml] W3C, "XML Schema Part 2: Datatypes Second Edition", 305 October 2004, . 307 [IEEE-754-1985] 308 IEEE, "754-1985 IEEE Standard for Binary Floating-Point 309 Arithmetic", January 2003. 311 Authors' Addresses 313 Hannes Tschofenig 314 Nokia Siemens Networks 315 Otto-Hahn-Ring 6 316 Munich, Bavaria 81739 317 Germany 319 Phone: +49 89 636 40390 320 Email: Hannes.Tschofenig@nsn.com 321 URI: http://www.tschofenig.com 323 James Winterbottom 324 Andrew Corporation 325 PO Box U40 326 University of Wollongong, NSW 2500 327 AU 329 Email: james.winterbottom@andrew.com 331 Full Copyright Statement 333 Copyright (C) The IETF Trust (2008). 335 This document is subject to the rights, licenses and restrictions 336 contained in BCP 78, and except as set forth therein, the authors 337 retain all their rights. 339 This document and the information contained herein are provided on an 340 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 341 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 342 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 343 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 344 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 345 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 347 Intellectual Property 349 The IETF takes no position regarding the validity or scope of any 350 Intellectual Property Rights or other rights that might be claimed to 351 pertain to the implementation or use of the technology described in 352 this document or the extent to which any license under such rights 353 might or might not be available; nor does it represent that it has 354 made any independent effort to identify any such rights. Information 355 on the procedures with respect to rights in RFC documents can be 356 found in BCP 78 and BCP 79. 358 Copies of IPR disclosures made to the IETF Secretariat and any 359 assurances of licenses to be made available, or the result of an 360 attempt made to obtain a general license or permission for the use of 361 such proprietary rights by implementers or users of this 362 specification can be obtained from the IETF on-line IPR repository at 363 http://www.ietf.org/ipr. 365 The IETF invites any interested party to bring to its attention any 366 copyrights, patents or patent applications, or other proprietary 367 rights that may cover technology that may be required to implement 368 this standard. Please address the information to the IETF at 369 ietf-ipr@ietf.org. 371 Acknowledgment 373 Funding for the RFC Editor function is provided by the IETF 374 Administrative Support Activity (IASA).