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