idnits 2.17.1 draft-tschofenig-geopriv-dhcp-circle-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 (March 7, 2009) is 5522 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) ** 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 (~~), 2 warnings (==), 4 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: September 8, 2009 Andrew Corporation 6 March 7, 2009 8 Specifying a Circular Uncertainty Area Using DHCP 9 draft-tschofenig-geopriv-dhcp-circle-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 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 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 8, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document specifies how a circular area representing the location 48 of device can be returned using DHCP. The document also shows how 49 the data returned from DHCP can be encoded into GML for using in a 50 PIDF-LO in an unambiguous or contentious manner. 52 This document is a contribution to the ongoing discussion on RFC 53 3825; it represents one possible solution to address the discussed 54 issues. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Details and Rationale . . . . . . . . . . . . . . . . . . . . 5 61 3.1. DHCPv4 Option for a Circular Location . . . . . . . . . . 5 62 3.2. DHCPv6 Option for a LIS Address . . . . . . . . . . . . . 6 63 4. Expressing the Circle in GML . . . . . . . . . . . . . . . . . 8 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 67 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 70 1. Introduction 72 Location provided by GPS device and like generally provide location 73 information as a point with a degree of uncertainty. This 74 uncertainty is more often than not expressed as an offset in metres 75 from the central point, with the resulting location being a circle 76 when expressed in 2 dimensions, and a sphere when expressed in 3 77 dimensions. This memo presupposes that locations have been measured, 78 for example using a GPS, ahead of time and have subsequently been 79 stored in a wiremap database. Associations between end-devices and 80 location can be done using DHCP option 82 or other methods where 81 appropriate. 83 This document omits an altitude representation based on the 84 envisioned usage scenario. 86 2. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 3. Details and Rationale 94 The intent of this specification is to provide a location to an end- 95 device so that it can easily represent it as circle in GML in 96 accordance with PIDF-LO Profile [I-D.ietf-geopriv-pdif-lo-profile]. 97 PIDF-LO Profile relies on geoshape [geoshape] requires all 98 coordinates to be specified using WGS-84, consequently the 99 coordinates used in this memo are specified using WGS-84. 101 GML [gml] uses the ISO 19107 [ISO-19107] definition of a point, and 102 quotes this as being "0-dimensional geometric primitive, representing 103 a position. NOTE The boundary of a point is the empty set." At some 104 point however, it becomes necessary to express the coordinates that 105 make up the location in bits and bytes. Since the intent is to use 106 GML as the final representation, the encoding standards and 107 limitations expressed by GML are used. 109 GML is an XML language [xml] for expressing location information, and 110 XML defines mappings between its primative types and standard binary 111 encodings. The GML point is made up of XML (xsd) doubles, and an XML 112 double is expressed as an IEEE 754-1985 [IEEE-754-1985] double- 113 precision floating point number. This means that a latitude or 114 longitude in GML is expressed as a 64 bit binary number, but in 115 accordance with the previous definition is interpretted as being zero 116 dimensional, without area. 118 The binary encodings provided in this memo express latitude and 119 longitude values as 64 bit binary floating-point numbers, as defined 120 in [IEEE-754-1985]. A radius is defined as a positive offset to this 121 in metres, and is expressed as an unsigned 16 bit integer. This 122 allows a circle with a radius in the order of 65.5km to be expressed 123 without difficulty, and for a point with no specified uncertainty to 124 be provided where the radius is set to zero. 126 3.1. DHCPv4 Option for a Circular Location 128 This section defines a DHCP for IPv4 (DHCPv4) option for the point 129 with radius of uncertainty. 131 0 1 2 3 132 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | LOC-CIRCLE | Length | Latitude | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Latitude continued | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Latitude Continued | Longitude | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Longitude continued | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Longitude Continued | Radius | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 DHCPv4 Option 147 LOC-CIRCLE: The IANA assigned option number (TBD). 149 Length: The length of this option octets (18). 151 Latitude: 8 octets representing the the latitude of the central 152 point of a circle, expressed as an [IEEE-754-1985] double. 154 Longitude: 8 octets representing the the longitude of the central 155 point of a circle, expressed as an [IEEE-754-1985] double. 157 Radius: a 16 bit unsigned integer expressing the radius of the 158 circle in metres. 160 3.2. DHCPv6 Option for a LIS Address 162 This section defines a DHCP for IPv6 (DHCPv6) option for the point 163 with radius of uncertainty. The DHCPv6 option for this parameter is 164 similarly formatted to the DHCPv4 option. 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | LOC-CIRCLE | Length | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Latitude | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Latitude continued | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Longitude | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Longitude continued | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Radius | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 DHCPv6 Option 184 LOC-CIRCLE: The IANA assigned option number (TBD). 186 Length: The length of this option in octets (18). 188 Latitude: 8 octets representing the the latitude of the central 189 point of a circle, expressed as an [IEEE-754-1985] double. 191 Longitude: 8 octets representing the the longitude of the central 192 point of a circle, expressed as an [IEEE-754-1985] double. 194 Radius: a 16 bit unsigned integer expressing the radius of the 195 circle in metres. 197 4. Expressing the Circle in GML 199 PIDF-LO Profile [I-D.ietf-geopriv-pdif-lo-profile] describes how a 200 circle is expressed in GML and included in a PIDF-LO [RFC4119]. The 201 latitude and longitude components of this encoding form the central 202 point of the circle. 204 _d^^^^^^^^^b_ 205 .d'' ``b. 206 .p' / `q. 207 .d' Radius-> / `b. 208 .d' / `b. 209 :: / :: 210 :: C :: 211 :: ^ :: 212 `p. | .q' 213 `p. Centre .q' 214 `b. .d' 215 `q.. ..p' 216 ^q.........p^ 218 Figure 1: Circle Representation 220 The XML for the resulting circle is shown in Figure 2 (assuming the 221 centre is represented as 42.5463 -73.2512) and the radius is 5 222 meters. 224 225 231 232 233 234 235 236 237 42.5463 -73.2512 238 239 240 5 241 242 243 244 245 DHCP 246 247 248 249 251 Figure 2: Resulting XML and PIDF-LO 253 5. Security Considerations 255 The security issues for this document are the same as for RFC 3825 256 [RFC3825]. 258 6. IANA Considerations 260 There are no specific IANA considerations for this document. 262 7. Acknowledgements 264 The authors contribute this document to the ongoing discussion in the 265 GEOPRIV working group. Still, the authors believe that it would be 266 necessary to investigate the intended deployment use cases more in 267 order to evaluate what additional location shapes are likely to be 268 used and whether there is interest in using DHCP (or lower layer 269 protocols developed by the IEEE or TIA) for conveying location 270 information or whether there is more interest to use these protocols 271 purely to discover a LIS and allow more flexibility with regard to 272 the supported location shapes. 274 8. Normative References 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, March 1997. 279 [I-D.ietf-geopriv-pdif-lo-profile] 280 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 281 PIDF-LO Usage Clarification, Considerations and 282 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 283 (work in progress), November 2008. 285 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 286 Format", RFC 4119, December 2005. 288 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 289 Configuration Protocol Option for Coordinate-based 290 Location Configuration Information", RFC 3825, July 2004. 292 [geoshape] 293 Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape 294 Application Schema for use by the Internet Engineering 295 Task Force (IETF)", Candidate OpenGIS Implementation 296 Specification 06-142r1, Version: 1.0, April 2007. 298 [ISO-19107] 299 ISO, "Geographic information - Spatial Schema", ISO 300 Standard 19107, First Edition, 5 2003. 302 [gml] Cox, S., Daisey, P., Lake, R., Portele, C., and A. 303 Whiteside, "Geographic information - Geography Markup 304 Language (GML)", OpenGIS 03-105r1, April 2004, 305 . 308 [xml] W3C, "XML Schema Part 2: Datatypes Second Edition", 309 October 2004, . 311 [IEEE-754-1985] 312 IEEE, "754-1985 IEEE Standard for Binary Floating-Point 313 Arithmetic", January 2003. 315 Authors' Addresses 317 Hannes Tschofenig 318 Nokia Siemens Networks 319 Linnoitustie 6 320 Espoo 02600 321 Finland 323 Phone: +358 (50) 4871445 324 Email: Hannes.Tschofenig@gmx.net 325 URI: http://www.tschofenig.priv.at 327 James Winterbottom 328 Andrew Corporation 329 PO Box U40 330 University of Wollongong, NSW 2500 331 AU 333 Email: james.winterbottom@andrew.com