idnits 2.17.1
draft-ietf-geopriv-held-measurements-08.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
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 :
----------------------------------------------------------------------------
-- The document has examples using IPv4 documentation addresses according
to RFC6890, but does not use any IPv6 documentation addresses. Maybe
there should be IPv6 examples, too?
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (June 24, 2013) is 3956 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)
== Missing Reference: '0-5' is mentioned on line 2161, but not defined
== Missing Reference: '0-4' is mentioned on line 2161, but not defined
== Missing Reference: '0-9' is mentioned on line 2161, but not defined
== Missing Reference: '0-1' is mentioned on line 2161, but not defined
-- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.80211'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.8021AB'
** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415)
-- Obsolete informational reference (is this intentional?): RFC 5226
(Obsoleted by RFC 8126)
Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 GEOPRIV M. Thomson
3 Internet-Draft Microsoft
4 Intended status: Standards Track J. Winterbottom
5 Expires: December 26, 2013 Unaffiliated
6 June 24, 2013
8 Using Device-provided Location-Related Measurements in Location
9 Configuration Protocols
10 draft-ietf-geopriv-held-measurements-08
12 Abstract
14 This document describes a protocol for a Device to provide location-
15 related measurement data to a Location Information Server (LIS)
16 within a request for location information. Location-related
17 measurement information are observations concerning properties
18 related to the position of a Device, which could be data about
19 network attachment or about the physical environment. A LIS is able
20 to use the location-related measurement data to improve the accuracy
21 of the location estimate it provides to the Device. A basic set of
22 location-related measurements are defined, including common modes of
23 network attachment as well as assisted Global Navigation Satellite
24 System (GNSS) parameters.
26 Status of This Memo
28 This Internet-Draft is submitted in full conformance with the
29 provisions of BCP 78 and BCP 79.
31 Internet-Drafts are working documents of the Internet Engineering
32 Task Force (IETF). Note that other groups may also distribute
33 working documents as Internet-Drafts. The list of current Internet-
34 Drafts is at http://datatracker.ietf.org/drafts/current/.
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference
39 material or to cite them other than as "work in progress."
41 This Internet-Draft will expire on December 26, 2013.
43 Copyright Notice
45 Copyright (c) 2013 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (http://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the Simplified BSD License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
61 2. Conventions used in this document . . . . . . . . . . . . . . 5
62 3. Location-Related Measurements in LCPs . . . . . . . . . . . . 5
63 4. Location-Related Measurement Data Types . . . . . . . . . . . 7
64 4.1. Measurement Container . . . . . . . . . . . . . . . . . . 7
65 4.1.1. Time of Measurement . . . . . . . . . . . . . . . . . 8
66 4.1.2. Expiry Time on Location-Related Measurement Data . . 8
67 4.2. RMS Error and Number of Samples . . . . . . . . . . . . . 9
68 4.2.1. Time RMS Error . . . . . . . . . . . . . . . . . . . 9
69 4.3. Measurement Request . . . . . . . . . . . . . . . . . . . 10
70 4.4. Identifying Location Provenance . . . . . . . . . . . . . 11
71 5. Location-Related Measurement Data Types . . . . . . . . . . . 13
72 5.1. LLDP Measurements . . . . . . . . . . . . . . . . . . . . 14
73 5.2. DHCP Relay Agent Information Measurements . . . . . . . . 15
74 5.3. 802.11 WLAN Measurements . . . . . . . . . . . . . . . . 15
75 5.3.1. Wifi Measurement Requests . . . . . . . . . . . . . . 19
76 5.4. Cellular Measurements . . . . . . . . . . . . . . . . . . 19
77 5.4.1. Cellular Measurement Requests . . . . . . . . . . . . 22
78 5.5. GNSS Measurements . . . . . . . . . . . . . . . . . . . . 22
79 5.5.1. GNSS System and Signal . . . . . . . . . . . . . . . 24
80 5.5.2. Time . . . . . . . . . . . . . . . . . . . . . . . . 24
81 5.5.3. Per-Satellite Measurement Data . . . . . . . . . . . 24
82 5.5.4. GNSS Measurement Requests . . . . . . . . . . . . . . 25
83 5.6. DSL Measurements . . . . . . . . . . . . . . . . . . . . 25
84 5.6.1. L2TP Measurements . . . . . . . . . . . . . . . . . . 26
85 5.6.2. RADIUS Measurements . . . . . . . . . . . . . . . . . 26
86 5.6.3. Ethernet VLAN Tag Measurements . . . . . . . . . . . 27
87 5.6.4. ATM Virtual Circuit Measurements . . . . . . . . . . 28
88 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28
89 6.1. Measurement Data Privacy Model . . . . . . . . . . . . . 28
90 6.2. LIS Privacy Requirements . . . . . . . . . . . . . . . . 29
91 6.3. Measurement Data and Location URIs . . . . . . . . . . . 29
92 6.4. Third-Party-Provided Measurement Data . . . . . . . . . . 30
93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
94 7.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 30
95 7.1.1. Acquiring Location Information Without Authorization 31
96 7.1.2. Extracting Network Topology Data . . . . . . . . . . 32
97 7.1.3. Exposing Network Topology Data . . . . . . . . . . . 32
98 7.1.4. Lying By Proxy . . . . . . . . . . . . . . . . . . . 32
99 7.1.5. Measurement Replay . . . . . . . . . . . . . . . . . 33
100 7.1.6. Environment Spoofing . . . . . . . . . . . . . . . . 34
101 7.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . 35
102 7.2.1. Measurement Validation . . . . . . . . . . . . . . . 36
103 7.2.1.1. Effectiveness . . . . . . . . . . . . . . . . . . 36
104 7.2.1.2. Limitations (Unique Observer) . . . . . . . . . . 37
105 7.2.2. Location Validation . . . . . . . . . . . . . . . . . 38
106 7.2.2.1. Effectiveness . . . . . . . . . . . . . . . . . . 38
107 7.2.2.2. Limitations . . . . . . . . . . . . . . . . . . . 38
108 7.2.3. Supporting Observations . . . . . . . . . . . . . . . 39
109 7.2.3.1. Effectiveness . . . . . . . . . . . . . . . . . . 39
110 7.2.3.2. Limitations . . . . . . . . . . . . . . . . . . . 40
111 7.2.4. Attribution . . . . . . . . . . . . . . . . . . . . . 40
112 7.2.5. Stateful Correlation of Location Requests . . . . . . 41
113 7.3. An Unauthorized or Compromised LIS . . . . . . . . . . . 42
114 8. Measurement Schemas . . . . . . . . . . . . . . . . . . . . . 42
115 8.1. Measurement Container Schema . . . . . . . . . . . . . . 42
116 8.2. Measurement Source Schema . . . . . . . . . . . . . . . . 44
117 8.3. Base Type Schema . . . . . . . . . . . . . . . . . . . . 45
118 8.4. LLDP Measurement Schema . . . . . . . . . . . . . . . . . 48
119 8.5. DHCP Measurement Schema . . . . . . . . . . . . . . . . . 49
120 8.6. WiFi Measurement Schema . . . . . . . . . . . . . . . . . 50
121 8.7. Cellular Measurement Schema . . . . . . . . . . . . . . . 54
122 8.8. GNSS Measurement Schema . . . . . . . . . . . . . . . . . 56
123 8.9. DSL Measurement Schema . . . . . . . . . . . . . . . . . 58
124 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
125 9.1. IANA Registry for GNSS Types . . . . . . . . . . . . . . 60
126 9.2. URN Sub-Namespace Registration for
127 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc . . . . . . . 61
128 9.3. URN Sub-Namespace Registration for
129 urn:ietf:params:xml:ns:geopriv:lm . . . . . . . . . . . . 62
130 9.4. URN Sub-Namespace Registration for
131 urn:ietf:params:xml:ns:geopriv:lm:basetypes . . . . . . . 63
132 9.5. URN Sub-Namespace Registration for
133 urn:ietf:params:xml:ns:geopriv:lm:lldp . . . . . . . . . 63
134 9.6. URN Sub-Namespace Registration for
135 urn:ietf:params:xml:ns:geopriv:lm:dhcp . . . . . . . . . 64
136 9.7. URN Sub-Namespace Registration for
137 urn:ietf:params:xml:ns:geopriv:lm:wifi . . . . . . . . . 65
138 9.8. URN Sub-Namespace Registration for
139 urn:ietf:params:xml:ns:geopriv:lm:cell . . . . . . . . . 65
140 9.9. URN Sub-Namespace Registration for
141 urn:ietf:params:xml:ns:geopriv:lm:gnss . . . . . . . . . 66
142 9.10. URN Sub-Namespace Registration for
143 urn:ietf:params:xml:ns:geopriv:lm:dsl . . . . . . . . . . 67
145 9.11. XML Schema Registration for Measurement Source Schema . . 67
146 9.12. XML Schema Registration for Measurement Container Schema 68
147 9.13. XML Schema Registration for Base Types Schema . . . . . . 68
148 9.14. XML Schema Registration for LLDP Schema . . . . . . . . . 68
149 9.15. XML Schema Registration for DHCP Schema . . . . . . . . . 68
150 9.16. XML Schema Registration for WiFi Schema . . . . . . . . . 69
151 9.17. XML Schema Registration for Cellular Schema . . . . . . . 69
152 9.18. XML Schema Registration for GNSS Schema . . . . . . . . . 69
153 9.19. XML Schema Registration for DSL Schema . . . . . . . . . 69
154 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70
155 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 70
156 11.1. Normative References . . . . . . . . . . . . . . . . . . 70
157 11.2. Informative References . . . . . . . . . . . . . . . . . 72
158 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73
160 1. Introduction
162 A Location Configuration Protocol (LCP) provides a means for a Device
163 to request information about its physical location from an access
164 network. A location information server (LIS) is the server that
165 provides location information that is available due to the knowledge
166 it has about the network and physical environment.
168 As a part of the access network, the LIS is able to acquire
169 measurement results related to Device location from network elements.
170 The LIS also has access to information about the network topology
171 that can be used to turn measurement data into location information.
172 This information can be further enhanced with information acquired
173 from the Device itself.
175 A Device is able to make observations about its network attachment,
176 or its physical environment. The location-related measurement data
177 might be unavailable to the LIS; alternatively, the LIS might be able
178 to acquire the data, but at a higher cost, in time or an other
179 metric. Providing measurement data gives the LIS more options in
180 determining location, which could improve the quality of the service
181 provided by the LIS. Improvements in accuracy are one potential
182 gain, but improved response times and lower error rates are possible.
184 This document describes a means for a Device to report location-
185 related measurement data to the LIS. Examples based on the HELD
186 [RFC5985] location configuration protocol are provided.
188 2. Conventions used in this document
190 The terms LIS and Device are used in this document in a manner
191 consistent with the usage in [RFC5985].
193 This document also uses the following definitions:
195 Location Measurement: An observation about the physical properties
196 of a particular Device's position in time and space. The result
197 of a location measurement - "location-related measurement data",
198 or simply "measurement data" given sufficient context - can be
199 used to determine the location of a Device. Location-related
200 measurement data does not directly identify a Device, though it
201 could do indirectly. Measurement data can change with time if the
202 location of the Device also changes.
204 Location-related measurement data does not necessarily contain
205 location information directly, but it can be used in combination
206 with contextual knowledge and/or algorithms to derive location
207 information. Examples of location-related measurement data are:
208 radio signal strength or timing measurements, Ethernet switch and
209 port identifiers.
211 Location-related measurement data can be considered sighting
212 information, based on the definition in [RFC3693].
214 Location Estimate: A location estimate is an approximation of where
215 the Device is located. Location estimates are derived from
216 location measurements. Location estimates are subject to
217 uncertainty, which arise from errors in measurement results.
219 GNSS: Global Navigation Satellite System. A satellite-based system
220 that provides positioning and time information. For example, the
221 US Global Positioning System (GPS) or the European Galileo system.
223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
225 document are to be interpreted as described in [RFC2119].
227 3. Location-Related Measurements in LCPs
229 This document defines a standard container for the conveyance of
230 location-related measurement parameters in location configuration
231 protocols. This is an XML container that identifies parameters by
232 type and allows the Device to provide the results of any measurement
233 it is able to perform. A set of measurement schemas are also defined
234 that can be carried in the generic container.
236 A simple example of measurement data conveyance is illustrated by the
237 example message in Figure 1. This shows a HELD location request
238 message with an Ethernet switch and port measurement taken using LLDP
239 [IEEE.8021AB].
241
242 civic
243
245
246 0a01003c
247 c2
248
249
250
252 Figure 1: HELD Location Request with Measurement Data
254 This LIS can ignore measurement data that it does not support or
255 understand. The measurements defined in this document follow this
256 rule: extensions that could result in backward incompatibility MUST
257 be added as new measurement definitions rather than extensions to
258 existing types.
260 Multiple sets of measurement data, either of the same type or from
261 different sources, can be included in the "measurements" element.
262 See Section 4.1.1 for details on repetition of this element.
264 A LIS can choose to use or ignore location-related measurement data
265 in determining location, as long as rules regarding use and retention
266 (Section 6) are respected. The "method" parameter in the Presence
267 Information Data Format - Location Object (PIDF-LO) [RFC4119] SHOULD
268 be adjusted to reflect the method used. A correct "method" can
269 assist location recipients in assessing the quality (both accuracy
270 and integrity) of location information, though there could be reasons
271 to withhold information about the source of data.
273 Measurement data is typically only used to serve the request that it
274 is included in. There may be exceptions, particularly with respect
275 to location URIs. Section 6 provides more information on usage
276 rules.
278 Location-related measurement data need not be provided exclusively by
279 Devices. A third party location requester (for example, see
280 [RFC6155]) can request location information using measurement data,
281 if the requester is able to acquire measurement data and authorized
282 to distribute it. There are specific privacy considerations relating
283 to the use of measurements by third parties, which are discussed in
284 Section 6.4.
286 Location-related measurement data and its use presents a number of
287 privacy and security challenges. These are described in more detail
288 in Section 6 and Section 7.
290 4. Location-Related Measurement Data Types
292 A common container is defined for the expression of location
293 measurement data, as well as a simple means of identifying specific
294 types of measurement data for the purposes of requesting them.
296 The following example shows a measurement container with measurement
297 time and expiration time included. A WiFi measurement is enclosed.
299
302
303
304 00-12-F0-A0-80-EF
305 wlan-home
306
307
308
310 Figure 2: Measurement Example
312 4.1. Measurement Container
314 The "measurements" element is used to encapsulate measurement data
315 that is collected at a certain point in time. It contains time-based
316 attributes that are common to all forms of measurement data, and
317 permits the inclusion of arbitrary measurement data. The elements
318 that are included within the "measurements" element are generically
319 referred to as "measurement elements".
321 This container can be added to a request for location information in
322 any protocol capable of carrying XML, such as a HELD location request
323 [RFC5985].
325 4.1.1. Time of Measurement
327 The "time" attribute records the time that the measurement or
328 observation was made. This time can be different to the time that
329 the measurement information was reported. Time information can be
330 used to populate a timestamp on the location result, or to determine
331 if the measurement information is used.
333 The "time" attribute SHOULD be used to avoid forcing an arbitrary
334 choice of timestamp for relatively static types of measurement (for
335 instance, the DSL measurements in Section 5.6) and for legacy Devices
336 that don't record time information (such as the Home Location
337 Register/Home Subscriber Server for cellular). However, time SHOULD
338 be provided whenever possible.
340 The "time" attribute is attached to the root "measurement" element.
341 Multiple measurements can often be given the same timestamp, even
342 when the measurements were not actually taken at the same time
343 (consider a set of measurements taken sequentially, where the
344 difference in time between observations is not significant).
345 Measurements cannot be grouped if they have different types, or there
346 is a need for independent time values on each measurement. In these
347 instances, multiple measurement sets are necessary.
349 4.1.2. Expiry Time on Location-Related Measurement Data
351 A Device is able to indicate an expiry time in the location
352 measurement using the "expires" attribute. Nominally, this attribute
353 indicates how long information is expected to be valid, but it can
354 also indicate a time limit on the retention and use of the
355 measurement data. A Device can use this attribute to request that
356 the LIS not retain measurement data beyond the indicated time.
358 Note: Movement of the Device might result in the measurement data
359 being invalidated before the expiry time.
361 A Device is advised to set the "expires" attribute to earlier of: the
362 time that measurements are likely to be unusable, and the time that
363 it desires to have measurements discarded by the LIS. A Device that
364 does not desire measurement data to be retained can omit the
365 "expires" attribute. Section 6 describes more specific rules
366 regarding measurement data retention.
368 4.2. RMS Error and Number of Samples
370 Often a measurement is taken more than once. Reporting the average
371 of a number of measurement results mitigates the effects of random
372 errors that occur in the measurement process.
374 Reporting each measurement individually can be the most effective
375 method of reporting multiple measurements. This is achieved by
376 providing multiple measurement elements for different times.
378 The alternative is to aggregate multiple measurements and report a
379 mean value across the set of measurements. Additional information
380 about the distribution of the results can be useful in determining
381 location uncertainty.
383 Two attributes are provided for use on some measurement values:
385 rmsError: The root-mean-squared (RMS) error of the set of
386 measurement values used in calculating the result. RMS error is
387 expressed in the same units as the measurement, unless otherwise
388 stated. If an accurate value for RMS error is not known, this
389 value can be used to indicate an upper bound or estimate for the
390 RMS error.
392 samples: The number of samples that were taken in determining the
393 measurement value. If omitted, this value can be assumed to be
394 large enough that the RMS error is an indication of the standard
395 deviation of the sample set.
397 For some measurement techniques, measurement error is largely
398 dependent on the measurement technique employed. In these cases,
399 measurement error is largely a product of the measurement technique
400 and not the specific circumstances, so RMS error does not need to be
401 actively measured. A fixed value MAY be provided for RMS error where
402 appropriate.
404 The "rmsError" and "samples" elements are added as attributes of
405 specific measurement data types.
407 4.2.1. Time RMS Error
409 Measurement of time can be significant in certain circumstances. The
410 GNSS measurements included in this document are one such case where a
411 small error in time can result in a large error in location. Factors
412 such as clock drift and errors in time synchronization can result in
413 small, but significant, time errors. Including an indication of the
414 quality of time measurements can be helpful.
416 A "timeError" attribute MAY be added to the "measurement" element to
417 indicate the RMS error in time. "timeError" indicates an upper bound
418 on the time RMS error in seconds.
420 The "timeError" attribute does not apply where multiple samples of a
421 measurement are taken over time. If multiple samples are taken, each
422 SHOULD be included in a different "measurement" element.
424 4.3. Measurement Request
426 A measurement request is used by a protocol peer to describe a set of
427 measurement data that it desires. A "measurementRequest" element is
428 defined that can be included in a protocol exchange.
430 For instance, a LIS can use a measurement request in HELD responses.
431 If the LIS is unable to provide location information, but it believes
432 that a particular measurement type would enable it to provide a
433 location, it can include a measurement request in an error response.
435 The "measurement" element of the measurement request identifies the
436 type of measurement that is requested. The "type" attribute of this
437 element indicates the type of measurement, as identified by an XML
438 qualified name. An "samples" attribute MAY be used to indicate how
439 many samples of the identified measurement are requested.
441 The "measurement" element can be repeated to request multiple (or
442 alternative) measurement types.
444 Additional XML content might be defined for a particular measurement
445 type that is used to further refine a request. These elements either
446 constrain what is requested or specify non-mandatory components of
447 the measurement data that are needed. These are defined along with
448 the specific measurement type.
450 In the HELD protocol, the inclusion of a measurement request in an
451 error response with a code of "locationUnknown" indicates that
452 providing measurements would increase the likelihood of a subsequent
453 request being successful.
455 The following example shows a HELD error response that indicates that
456 WiFi measurement data would be useful if a later request were made.
457 Additional elements indicate that received signal strength for an
458 802.11n access point is requested.
460
462 Insufficient measurement data
463
466
467 n
468 wifi:rcpi
469
470
471
473 Figure 3: HELD Error Requesting Measurement Data
475 A measurement request that is included in other HELD messages has
476 undefined semantics and can be safely ignored. Other specifications
477 might define semantics for measurement requests under other
478 conditions.
480 4.4. Identifying Location Provenance
482 An extension is made to the PIDF-LO [RFC4119] that allows a location
483 recipient to identify the source (or sources) of location information
484 and the measurement data that was used to determine that location
485 information.
487 The "source" element is added to the "geopriv" element of the PIDF-
488 LO. This element does not identify specific entities. Instead, it
489 identifies the type of source.
491 The following types of measurement source are identified:
493 lis: Location information is based on measurement data that the LIS
494 or sources that it trusts have acquired. This label MAY be used
495 if measurement data provided by the Device has been completely
496 validated by the LIS.
498 device: A LIS MUST include this value if the location information is
499 based (in whole or part) on measurement data provided by the
500 Device and if the measurement data isn't completely validated.
502 other: Location information is based on measurement data that a
503 third party has provided. This might be an authorized third party
504 that uses identity parameters [RFC6155] or any other entity. The
505 LIS MUST include this, unless the third party is trusted by the
506 LIS to provide measurement data.
508 No assertion is made about the veracity of the measurement data from
509 sources other than the LIS. A combination of tags MAY be included to
510 indicate that measurement data from multiple types of sources was
511 used.
513 For example, the first tuple of the following PIDF-LO indicates that
514 measurement data from a LIS and a device was combined to produce the
515 result, the second tuple was produced by the LIS alone.
517
523
524
525
526
527
528 7.34324 134.47162
529
530 850.24
531
532
533
534
535 OTDOA
536 lis device
537
538
539
540
541
542
543
544
545 7.34379 134.46484
546
547 9000
548
549
550
551
552 Cell
553 lis
554
555
556
557
559 PIDF-LO document with source labels
561 5. Location-Related Measurement Data Types
563 This document defines location-related measurement data types for a
564 range of common network types.
566 All included measurement data definitions allow for arbitrary
567 extension in the corresponding schema. New parameters that are
568 applicable to location determination are added as new XML elements in
569 a unique namespace, not by adding elements to an existing namespace.
571 5.1. LLDP Measurements
573 Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB] messages are sent
574 between adjacent nodes in an IEEE 802 network (e.g. wired Ethernet,
575 WiFi, 802.16). These messages all contain identification information
576 for the sending node, which can be used to determine location
577 information. A Device that receives LLDP messages can report this
578 information as a location-related measurement to the LIS, which is
579 then able to use the measurement data in determining the location of
580 the Device.
582 Note: The LLDP extensions defined in LLDP Media Endpoint Discovery
583 (LLDP-MED) [ANSI-TIA-1057] provide the ability to acquire location
584 information directly from an LLDP endpoint. Where this
585 information is available, it might be unnecessary to use any other
586 form of location configuration.
588 Values are provided as hexadecimal sequences. The Device MUST report
589 the values directly as they were provided by the adjacent node.
590 Attempting to adjust or translate the type of identifier is likely to
591 cause the measurement data to be useless.
593 Where a Device has received LLDP messages from multiple adjacent
594 nodes, it should provide information extracted from those messages by
595 repeating the "lldp" element.
597 An example of an LLDP measurement is shown in Figure 4. This shows
598 an adjacent node (chassis) that is identified by the IP address
599 192.0.2.45 (hexadecimal c000022d) and the port on that node is
600 numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2).
602
604
605 c000022d
606 a2
607
608
610 Figure 4: LLDP Measurement Example
612 IEEE 802 Devices that are able to obtain information about adjacent
613 network switches and their attachment to them by other means MAY use
614 this data type to convey this information.
616 5.2. DHCP Relay Agent Information Measurements
618 The DHCP Relay Agent Information option [RFC3046] provides
619 measurement data about the network attachment of a Device. This
620 measurement data can be included in the "dhcp-rai" element.
622 The elements in the DHCP relay agent information options are opaque
623 data types assigned by the DHCP relay agent. The three items MAY be
624 omitted if unknown: circuit identifier ("circuit", circuit [RFC3046],
625 Interface-Id [RFC3315]), remote identifier ("remote", Remote ID
626 [RFC3046], or remote-id [RFC4649]) and subscriber identifier
627 ("subscriber", subscriber-id [RFC3993], Subscriber-ID [RFC4580]).
628 The DHCPv6 remote-id has an associated enterprise number
629 [IANA.enterprise] as an XML attribute.
631
633
634 192.0.2.158
635 108b
636
637
639 Figure 5: DHCP Relay Agent Information Measurement Example
641 The "giaddr" is specified as a dotted quad IPv4 address or an RFC
642 4291 [RFC4291] IPv6 address, using the forms defined in [RFC3986];
643 IPv6 addresses SHOULD use the form described in [RFC5952]. The
644 enterprise number is specified as a decimal integer. All other
645 information is included verbatim from the DHCP request in hexadecimal
646 format.
648 The "subscriber" element could be considered sensitive. This
649 information MUST NOT be provided to a LIS that is not authorized to
650 receive information about the access network. See Section 7.1.3 for
651 more details.
653 5.3. 802.11 WLAN Measurements
655 In WiFi, or 802.11 [IEEE.80211], networks a Device might be able to
656 provide information about the access point (AP) that it is attached
657 to, or other WiFi points it is able to see. This is provided using
658 the "wifi" element, as shown in Figure 6, which shows a single
659 complete measurement for a single access point.
661
663
664 Intel(r)PRO/Wireless 2200BG
665
666 AB-CD-EF-AB-CD-EF
667 example
668 5
669
670
671 -34.4 150.8
672
673
674 a
675 5
676 2
677 2
678 2.56e-9
679
680 23
681 5
682 -59
683 23
684
685
686 10
687 9
688 -98.5
689 7.5
690
691
692
693
695 Figure 6: 802.11 WLAN Measurement Example
697 A wifi element is made up of one or more access points, and a
698 "nicType" element, which MAY be omitted. Each access point is
699 described using the "ap" element, which is comprised of the following
700 fields:
702 bssid: The basic service set identifier. In an Infrastructure BSS
703 network, the bssid is the 48 bit MAC address of the access point.
705 The "verified" attribute of this element describes whether the
706 device has verified the MAC address or it authenticated the access
707 point or the network operating the access point (for example, a
708 captive portal accessed through the access point has been
709 authenticated). This attributes defaults to a value of "false"
710 when omitted.
712 ssid: The service set identifier (SSID) for the wireless network
713 served by the access point.
715 The SSID is a 32-octet identifier that is commonly represented as
716 a ASCII [ASCII] or UTF-8 [RFC3629] encoded string. To represent
717 octets that cannot be directly included in an XML element,
718 escaping is used. Sequences of octets that do not represent a
719 valid UTF-8 encoding can be escaped using a backslash ('\')
720 followed by two case-insensitive hexadecimal digits representing
721 the value of a single octet.
723 The canonical or value-space form of an SSID is a sequence of up
724 to 32 octets that is produced from the concatenation of UTF-8
725 encoded sequences of unescaped characters and octets derived from
726 escaped components.
728 channel: The channel number (frequency) that the access point
729 operates on.
731 location: The location of the access point, as reported by the
732 access point. This element contains any valid location, using the
733 rules for a "location-info" element, as described in [RFC5491].
735 type: The network type for the network access. This element
736 includes the alphabetic suffix of the 802.11 specification that
737 introduced the radio interface, or PHY; e.g. "a", "b", "g", or
738 "n".
740 band: The frequency band for the radio, in gigahertz (GHz). 802.11
741 [IEEE.80211] specifies PHY layers that use 2.4, 3.7 and 5
742 gigahertz frequency bands.
744 regclass: The operating class (regulatory domain and class in older
745 versions in 802.11), see Annex E of [IEEE.80211]. The "country"
746 attribute optionally includes the applicable two character country
747 identifier (dot11CountryString), which can be followed by an 'O',
748 'I' or 'X'. The element text content includes the value of the
749 regulatory class: an 8-bit integer in decimal form.
751 antenna: The antenna identifier for the antenna that the access
752 point is using to transmit the measured signals.
754 flightTime: Flight time is the difference between the time of
755 departure (TOD) of signal from a transmitting station and time of
756 arrival (TOA) of signal at a receiving station, as defined in
758 [IEEE.80211]. Measurement of this value requires that stations
759 synchronize their clocks. This value can be measured by access
760 point or Device; because the flight time is assumed to be the same
761 in either direction - aside from measurement errors - only a
762 single element is provided. This element permits the use of the
763 "rmsError" and "samples" attributes. RMS error might be derived
764 from the reported RMS error in TOD and TOA.
766 apSignal: Measurement information for the signal transmitted by the
767 access point, as observed by the Device. Some of these values are
768 derived from 802.11v [IEEE.80211] messages exchanged between
769 Device and access point. The contents of this element include:
771 transmit: The transmit power reported by the access point, in
772 dBm.
774 gain: The gain of the access point antenna reported by the access
775 point, in dB.
777 rcpi: The received channel power indicator for the access point
778 signal, as measured by the Device. This value SHOULD be in
779 units of dBm (with RMS error in dB). If power is measured
780 in a different fashion, the "dBm" attribute MUST be set to
781 "false". Signal strength reporting on current hardware uses
782 a range of different mechanisms; therefore, the value of the
783 "nicType" element SHOULD be included if the units are not
784 known to be in dBm and the value reported by the hardware
785 should be included without modification. This element
786 permits the use of the "rmsError" and "samples" attributes.
788 rsni: The received signal to noise indicator in dB. This element
789 permits the use of the "rmsError" and "samples" attributes.
791 deviceSignal: Measurement information for the signal transmitted by
792 the device, as reported by the access point. This element
793 contains the same child elements as the "ap" element, with the
794 access point and Device roles reversed.
796 The only mandatory element in this structure is "bssid".
798 The "nicType" element is used to specify the make and model of the
799 wireless network interface in the Device. Different 802.11 chipsets
800 report measurements in different ways, so knowing the network
801 interface type aids the LIS in determining how to use the provided
802 measurement data. The content of this field is unconstrained and no
803 mechanisms are specified to ensure uniqueness. This field is
804 unlikely to be useful, except under tightly controlled circumstances.
806 5.3.1. Wifi Measurement Requests
808 Two elements are defined for requesting WiFi measurements in a
809 measurement request:
811 type: The "type" element identifies the desired type (or types that
812 are requested).
814 parameter: The "parameter" element identifies measurements that are
815 requested for each measured access point. An element is
816 identified by its qualified name. The "context" parameter can be
817 used to specify if an element is included as a child of the "ap"
818 or "device" elements; omission indicates that it applies to both.
820 Multiple types or parameters can be requested by repeating either
821 element.
823 5.4. Cellular Measurements
825 Cellular Devices are common throughout the world and base station
826 identifiers can provide a good source of coarse location information.
827 Cellular measurements can be provided to a LIS run by the cellular
828 operator, or may be provided to an alternative LIS operator that has
829 access to one of several global cell-id to location mapping
830 databases.
832 A number of advanced location determination methods have been
833 developed for cellular networks. For these methods a range of
834 measurement parameters can be collected by the network, Device, or
835 both in cooperation. This document includes a basic identifier for
836 the wireless transmitter only; future efforts might define additional
837 parameters that enable more accurate methods of location
838 determination.
840 The cellular measurement set allows a Device to report to a LIS any
841 LTE (Figure 7), UMTS (Figure 8), GSM (Figure 9) or CDMA (Figure 10)
842 cells that it is able to observe. Cells are reported using their
843 global identifiers. All 3GPP cells are identified by public land
844 mobile network (PLMN), which is formed of mobile country code (MCC)
845 and mobile network code (MNC); specific fields are added for each
846 network type.
848 Formats for 3GPP cell identifiers are described in [TS.3GPP.23.003].
849 Bit-level formats for CDMA cell identifiers are described in
850 [TIA-2000.5]; decimal representations are used.
852 MCC and MNC are provided as decimal digit sequences; a leading zero
853 in an MCC or MNC is significant. All other values are decimal
854 integers.
856
858
859
860 4652080936424
861
862
863 4650610736789
864
865
866
868 Long term evolution (LTE) cells are identified by a 28-bit cell
869 identifier (eucid).
871 Figure 7: Example LTE Cellular Measurement
873
875
876
877 46520
878 200065000
879
880
881 46506
882 1638332767
883
884
885
887 Universal mobile telephony service (UMTS) cells are identified by 12-
888 or 16-bit radio network controller (rnc) id and a 16-bit cell id
889 (cid).
891 Figure 8: Example UMTS Cellular Measurement
893
895
896
897 46506
898 1638332767
899
901
902
904 Global System for Mobile communication (GSM) cells are identified by
905 a 16-bit location area code (lac) and 16-bit cell id (cid).
907 Figure 9: Example GSM Cellular Measurement
909
911
912
913 15892472312
914
915
916 15892472313
917
918
919
921 Code division multiple access (CDMA) cells are not identified by
922 PLMN, instead these use a 15-bit system id (sid), a 16-bit network id
923 (nid) and a 16-bit base station id (baseid).
925 Figure 10: Example CDMA Cellular Measurement
927 In general, a cellular Device will be attached to the cellular
928 network and so the notion of a serving cell exists. Cellular network
929 also provide overlap between neighbouring sites, so a mobile Device
930 can hear more than one cell. The measurement schema supports sending
931 both the serving cell and any other cells that the mobile might be
932 able to hear. In some cases, the Device could simply be listening to
933 cell information without actually attaching to the network, mobiles
934 without a SIM are an example of this. In this case the Device could
935 report cells it can hear without identifying any particular cell as
936 serving cell. An example of this is shown in Figure 11.
938
940
941
942 46520
943 200065000
944
945
946 46506
947 1638332767
948
950
951
953 Figure 11: Example Observed Cellular Measurement
955 5.4.1. Cellular Measurement Requests
957 Two elements can be used in measurement requests for cellular
958 measurements:
960 type: A label indicating the type of identifier to provide: one of
961 "gsm", "umts", "lte", or "cdma".
963 network: The network portion of the cell identifier. For 3GPP
964 networks, this is the combination of MCC and MNC; for CDMA, this
965 is the network identifier.
967 Multiple identifier types or networks can be identified by repeating
968 either element.
970 5.5. GNSS Measurements
972 A Global Navigation Satellite System (GNSS) uses orbiting satellites
973 to transmit signals. A Device with a GNSS receiver is able to take
974 measurements from the satellite signals. The results of these
975 measurements can be used to determine time and the location of the
976 Device.
978 Determining location and time in autonomous GNSS receivers follows
979 three steps:
981 Signal acquisition: During the signal acquisition stage, the
982 receiver searches for the repeating code that is sent by each GNSS
983 satellite. Successful operation typically requires measurement
984 data for a minimum of 5 satellites. At this stage, measurement
985 data is available to the Device.
987 Navigation message decode: Once the signal has been acquired, the
988 receiver then receives information about the configuration of the
989 satellite constellation. This information is broadcast by each
990 satellite and is modulated with the base signal at a low rate; for
991 instance, GPS sends this information at about 50 bits per second.
993 Calculation: The measurement data is combined with the data on the
994 satellite constellation to determine the location of the receiver
995 and the current time.
997 A Device that uses a GNSS receiver is able to report measurements
998 after the first stage of this process. A LIS can use the results of
999 these measurements to determine a location. In the case where there
1000 are fewer results available than the optimal minimum, the LIS might
1001 be able to use other sources of measurement information and combine
1002 these with the available measurement data to determine a position.
1004 Note: The use of different sets of GNSS _assistance data_ can
1005 reduce the amount of time required for the signal acquisition
1006 stage and obviate the need for the receiver to extract data on the
1007 satellite constellation. Provision of assistance data is outside
1008 the scope of this document.
1010 Figure 12 shows an example of GNSS measurement data. The measurement
1011 shown is for the GPS system and includes measurement data for three
1012 satellites only.
1014
1016
1018
1019 499.9395
1020 0.87595747
1021 45
1022
1023
1024 378.2657
1025 0.56639479
1026 52
1027
1028
1029 -633.0309
1030 0.57016835
1031 48
1032
1033
1034
1036 Figure 12: Example GNSS Measurement
1038 Each "gnss" element represents a single set of GNSS measurement data,
1039 taken at a single point in time. Measurements taken at different
1040 times can be included in different "gnss" elements to enable
1041 iterative refinement of results.
1043 GNSS measurement parameters are described in more detail in the
1044 following sections.
1046 5.5.1. GNSS System and Signal
1048 The GNSS measurement structure is designed to be generic and to apply
1049 to different GNSS types. Different signals within those systems are
1050 also accounted for and can be measured separately.
1052 The GNSS type determines the time system that is used. An indication
1053 of the type of system and signal can ensure that the LIS is able to
1054 correctly use measurements.
1056 Measurements for multiple GNSS types and signals can be included by
1057 repeating the "gnss" element.
1059 This document creates an IANA registry for GNSS types. Two satellite
1060 systems are registered by this document: GPS [GPS.ICD] and Galileo
1061 [Galileo.ICD]. Details for the registry are included in Section 9.1.
1063 5.5.2. Time
1065 Each set of GNSS measurements is taken at a specific point in time.
1066 The "time" attribute is used to indicate the time that the
1067 measurement was acquired, if the receiver knows how the time system
1068 used by the GNSS relates to UTC time.
1070 Alternative to (or in addition to) the measurement time, the
1071 "gnssTime" element MAY be included. The "gnssTime" element includes
1072 a relative time in milliseconds using the time system native to the
1073 satellite system. For the GPS satellite system, the "gnssTime"
1074 element includes the time of week in milliseconds. For the Galileo
1075 system, the "gnssTime" element includes the time of day in
1076 milliseconds.
1078 The accuracy of the time measurement provided is critical in
1079 determining the accuracy of the location information derived from
1080 GNSS measurements. The receiver SHOULD indicate an estimated time
1081 error for any time that is provided. An RMS error can be included
1082 for the "gnssTime" element, with a value in milliseconds.
1084 5.5.3. Per-Satellite Measurement Data
1086 Multiple satellites are included in each set of GNSS measurements
1087 using the "sat" element. Each satellite is identified by a number in
1088 the "num" attribute. The satellite number is consistent with the
1089 identifier used in the given GNSS.
1091 Both the GPS and Galileo systems use satellite numbers between 1 and
1092 64.
1094 The GNSS receiver measures the following parameters for each
1095 satellite:
1097 doppler: The observed Doppler shift of the satellite signal,
1098 measured in meters per second. This is converted from a value in
1099 Hertz by the receiver to allow the measurement to be used without
1100 knowledge of the carrier frequency of the satellite system. This
1101 value permits the use of RMS error attributes, also measured in
1102 meters per second.
1104 codephase: The observed code phase for the satellite signal,
1105 measured in milliseconds. This is converted from the system-
1106 specific value of chips or wavelengths into a system independent
1107 value. Larger values indicate larger distances from satellite to
1108 receiver. This value permits the use of RMS error attributes,
1109 also measured in milliseconds.
1111 cn0: The signal to noise ratio for the satellite signal, measured in
1112 decibel-Hertz (dB-Hz). The expected range is between 20 and 50
1113 dB-Hz.
1115 mp: An estimation of the amount of error that multipath signals
1116 contribute in meters. This parameter MAY be omitted.
1118 cq: An indication of the carrier quality. Two attributes are
1119 included: "continuous" can be either "true" or "false"; direct can
1120 be either "direct" or "inverted". This parameter MAY be omitted.
1122 adr: The accumulated Doppler range, measured in meters. This
1123 parameter MAY be omitted and is not useful unless multiple sets of
1124 GNSS measurements are provided or differential positioning is
1125 being performed.
1127 All values are converted from measures native to the satellite system
1128 to generic measures to ensure consistency of interpretation. Unless
1129 necessary, the schema does not constrain these values.
1131 5.5.4. GNSS Measurement Requests
1133 Measurement requests can include a "gnss" element, which includes the
1134 "system" and "signal" attributes. Multiple elements can be included
1135 to indicate a requests for GNSS measurements from multiple systems or
1136 signals.
1138 5.6. DSL Measurements
1140 Digital Subscriber Line (DSL) networks rely on a range of network
1141 technologies. DSL deployments regularly require cooperation between
1142 multiple organizations. These fall into two broad categories:
1143 infrastructure providers and Internet service providers (ISPs). For
1144 the same end user, an infrastructure and Internet service can be
1145 provided by different entities. Infrastructure providers manage the
1146 bulk of the physical infrastructure including cabling. End users
1147 obtain their service from an ISP, which manages all aspects visible
1148 to the end user including IP address allocation and operation of a
1149 LIS. See [DSL.TR025] and [DSL.TR101] for further information on DSL
1150 network deployments and the parameters that are available.
1152 Exchange of measurement information between these organizations is
1153 necessary for location information to be correctly generated. The
1154 ISP LIS needs to acquire location information from the infrastructure
1155 provider. However, since the infrastructure provider could have no
1156 knowledge of Device identifiers, it can only identify a stream of
1157 data that is sent to the ISP. This is resolved by passing
1158 measurement data relating to the Device to a LIS operated by the
1159 infrastructure provider.
1161 5.6.1. L2TP Measurements
1163 Layer 2 Tunneling Protocol (L2TP) [RFC2661] is a common means of
1164 linking the infrastructure provider and the ISP. The infrastructure
1165 provider LIS requires measurement data that identifies a single L2TP
1166 tunnel, from which it can generate location information. Figure 13
1167 shows an example L2TP measurement.
1169
1171
1172
1173 192.0.2.10
1174 192.0.2.61
1175 528
1176
1177
1178
1180 Figure 13: Example DSL L2TP Measurement
1182 5.6.2. RADIUS Measurements
1183 When authenticating network access, the infrastructure provider might
1184 employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or
1185 Access Node (AN). These messages provide the ISP RADIUS server with
1186 an identifier for the DSLAM or AN, plus the slot and port that the
1187 Device is attached to. These data can be provided as a measurement,
1188 which allows the infrastructure provider LIS to generate location
1189 information.
1191 The format of the AN, slot and port identifiers are not defined in
1192 the RADIUS protocol. Slot and port together identify a circuit on
1193 the AN, analogous to the circuit identifier in [RFC3046]. These
1194 items are provided directly, as they were in the RADIUS message. An
1195 example is shown in Figure 14.
1197
1199
1200 AN-7692
1201 3
1202 06
1203
1204
1206 Figure 14: Example DSL RADIUS Measurement
1208 5.6.3. Ethernet VLAN Tag Measurements
1210 For Ethernet-based DSL access networks, the DSL Access Module (DSLAM)
1211 or Access Node (AN) provide two VLAN tags on packets. A C-TAG is
1212 used to identify the incoming residential circuit, while the S-TAG is
1213 used to identify the DSLAM or AN. The C-TAG and S-TAG together can
1214 be used to identify a single point of network attachment. An example
1215 is shown in Figure 15.
1217
1219
1220 613
1221 1097
1222
1223
1225 Figure 15: Example DSL VLAN Tag Measurement
1227 Alternatively, the C-TAG can be replaced by data on the slot and port
1228 that the Device is attached to. This information might be included
1229 in RADIUS requests that are proxied from the infrastructure provider
1230 to the ISP RADIUS server.
1232 5.6.4. ATM Virtual Circuit Measurements
1234 An ATM virtual circuit can be employed between the ISP and
1235 infrastructure provider. Providing the virtual port ID (VPI) and
1236 virtual circuit ID (VCI) for the virtual circuit gives the
1237 infrastructure provider LIS the ability to identify a single data
1238 stream. A sample measurement is shown in Figure 16.
1240
1242
1243 55
1244 6323
1245
1246
1248 Figure 16: Example DSL ATM Measurement
1250 6. Privacy Considerations
1252 Location-related measurement data can be as privacy sensitive as
1253 location information [RFC6280].
1255 Measurement data is effectively equivalent to location information if
1256 the contextual knowledge necessary to generate one from the other is
1257 readily accessible. Even where contextual knowledge is difficult to
1258 acquire, there can be no assurance that an authorized recipient of
1259 the contextual knowledge is also authorized to receive location
1260 information.
1262 In order to protect the privacy of the subject of location-related
1263 measurement data, measurement data MUST be protected with the same
1264 degree of protection as location information. The confidentiality
1265 and authentication provided by TLS MUST be used in order to convey
1266 measurement data over HELD [RFC5985]. Other protocols MUST provide
1267 comparable guarantees.
1269 6.1. Measurement Data Privacy Model
1271 It is not necessary to distribute measurement data in the same
1272 fashion as location information. Measurement data is less useful to
1273 location recipients than location information. A simple distribution
1274 model is described in this document.
1276 In this simple model, the Device is the only entity that is able to
1277 distribute measurement data. To use an analogy from the GEOPRIV
1278 architecture, the Device - as the Location Generator, or the
1279 Measurement Data Generator - is the sole entity that can act for the
1280 role of both Rule Maker and Location Server.
1282 A Device that provides location-related measurement data, MUST only
1283 do so as explicitly authorized by a Rule Maker. This depends on
1284 having an interface that allows Rule Makers (for instance, users or
1285 administrators) to control where and how measurement data is
1286 provided.
1288 No entity is permitted to redistribute measurement data. The Device
1289 directs other entities in how measurement data is used and retained.
1291 The GEOPRIV model [RFC6280] protects the location of a Target using
1292 direction provided by a Rule Maker. For the purposes of measurement
1293 data distribution, this model relies on the assumptions made in
1294 Section 3 of HELD [RFC5985]. These assumptions effectively declare
1295 the Device to be a proxy for both Target and Rule Maker.
1297 6.2. LIS Privacy Requirements
1299 A LIS MUST NOT reveal location-related measurement data to any other
1300 entity. A LIS MUST NOT reveal location information based on
1301 measurement data to any other entity unless directed to do so by the
1302 Device.
1304 By adding measurement data to a request for location information, the
1305 Device implicitly grants permission for the LIS to generate the
1306 requested location information using the measurement data.
1307 Permission to use this data for any other purpose is not implied.
1309 As long as measurement data is only used in serving the request that
1310 contains it, rules regarding data retention are not necessary. A LIS
1311 MUST discard location-related measurement data after servicing a
1312 request, unless the Device grants permission to use that information
1313 for other purposes.
1315 6.3. Measurement Data and Location URIs
1317 A LIS MAY use measurement data provided by the Device to serve
1318 requests to location URIs, if the Device permits it. A Device
1319 permits this by including measurement data in a request that
1320 explicitly requests a location URI. By requesting a location URI,
1321 the Device grants permission for the LIS to use the measurement data
1322 in serving requests to that location URI. The LIS cannot provide
1323 location recipients with measurement data, as defined in Section 6.1.
1325 Note: In HELD, the "any" type is not an explicit request for a
1326 location URI, though a location URI might be provided.
1328 The usefulness of measurement data that is provided in this fashion
1329 is limited. The measurement data is only valid at the time that it
1330 was acquired by the Device. At the time that a request is made to a
1331 location URI, the Device might have moved, rendering the measurement
1332 data incorrect.
1334 A Device is able to explicitly limit the time that a LIS retains
1335 measurement data by adding an expiry time to the measurement data. A
1336 LIS MUST NOT retain location-related measurement data in memory,
1337 storage or logs beyond the time indicated in the "expires" attribute
1338 (Section 4.1.2). A LIS MUST NOT retain measurement data if the
1339 "expires" attribute is absent.
1341 6.4. Third-Party-Provided Measurement Data
1343 An authorized third-party request for the location of a Device (see
1344 [RFC6155]) can include location-related measurement data. This is
1345 possible where the third-party is able to make observations about the
1346 Device.
1348 A third-party that provides measurement data MUST be authorized to
1349 provide the specific measurement for the identified device. A third-
1350 party MUST either be trusted by the LIS for the purposes of providing
1351 measurement data of the provided type, or the measurement data MUST
1352 be validated (see Section 7.2.1) before being used.
1354 How a third-party authenticates its identity or gains authorization
1355 to use measurement data is not covered by this document.
1357 7. Security Considerations
1359 Use of location-related measurement data has privacy considerations
1360 that are discussed in Section 6.
1362 7.1. Threat Model
1364 The threat model for location-related measurement data concentrates
1365 on the Device providing falsified, stolen or incorrect measurement
1366 data.
1368 A Device that provides location-related measurement data might use
1369 data to:
1371 o acquire the location of another Device, without authorization;
1372 o extract information about network topology; or
1374 o coerce the LIS into providing falsified location information based
1375 on the measurement data.
1377 Location-related measurement data describes the physical environment
1378 or network attachment of a Device. A third party adversary in the
1379 proximity of the Device might be able to alter the physical
1380 environment such that the Device provides measurement data that is
1381 controlled by the third party. This might be used to indirectly
1382 control the location information that is derived from measurement
1383 data.
1385 7.1.1. Acquiring Location Information Without Authorization
1387 Requiring authorization for location requests is an important part of
1388 privacy protections of a location protocol. A location configuration
1389 protocol usually operates under a restricted policy that allows a
1390 requester to obtain their own location. HELD identity extensions
1391 [RFC6155] allows other entities to be authorized, conditional on a
1392 Rule Maker providing sufficient authorization.
1394 The intent of these protections is to ensure that a location
1395 recipient is authorized to acquire location information. Location-
1396 related measurement data could be used by an attacker to circumvent
1397 such authorization checks if the association between measurement data
1398 and Target Device is not validated by a LIS.
1400 A LIS can be coerced into providing location information for a Device
1401 that a location recipient is not authorized to receive. A request
1402 identifies one Device (implicitly or explicitly), but measurement
1403 data is provided for another Device. If the LIS does not check that
1404 the measurement data is for the identified Device, it could
1405 incorrectly authorize the request.
1407 By using unverified measurement data to generate a response, the LIS
1408 provides information about a Device without appropriate
1409 authorization.
1411 The feasibility of this attack depends on the availability of
1412 information that links a Device with measurement data. In some
1413 cases, measurement data that is correlated with a target is readily
1414 available. For instance, LLDP measurements (Section 5.1) are
1415 broadcast to all nodes on the same network segment. An attacker on
1416 that network segment can easily gain measurement data that relates a
1417 Device with measurements.
1419 For some types of measurement data, it's necessary for an attacker to
1420 know the location of the target in order to determine what
1421 measurements to use. This attack is meaningless for types of
1422 measurement data that require that the attacker first know the
1423 location of the target before measurement data can be acquired or
1424 fabricated. GNSS measurements (Section 5.5) share this trait with
1425 many wireless location determination methods.
1427 7.1.2. Extracting Network Topology Data
1429 Allowing requests with measurements might be used to collect
1430 information about network topology.
1432 Network topology can be considered sensitive information by a network
1433 operator for commercial or security reasons. While it is impossible
1434 to completely prevent a Device from acquiring some knowledge of
1435 network topology if a location service is provided, a network
1436 operator might desire to limit how much of this information is made
1437 available.
1439 Mapping a network topology does not require that an attacker be able
1440 to associate measurement data with a particular Device. If a
1441 requester is able to try a number of measurements, it is possible to
1442 acquire information about network topology.
1444 It is not even necessary that the measurements are valid; random
1445 guesses are sufficient, provided that there is no penalty or cost
1446 associated with attempting to use the measurements.
1448 7.1.3. Exposing Network Topology Data
1450 A Device could reveal information about a network to entities outside
1451 of that network if it provides location measurement data to a LIS
1452 that is outside of that network. With the exception of GNSS
1453 measurements, the measurements in this document provide information
1454 about an access network that could reveal topology information to an
1455 unauthorized recipient.
1457 A Device MUST NOT provide information about network topology without
1458 a clear signal that the recipient is authorized. A LIS that is
1459 discovered using DHCP as described in LIS discovery [RFC5986] can be
1460 considered to be authorized to receive information about the access
1461 network.
1463 7.1.4. Lying By Proxy
1464 Location information is a function of its inputs, which includes
1465 measurement data. Thus, falsified measurement data can be used to
1466 alter the location information that is provided by a LIS.
1468 Some types of measurement data are relatively easy to falsify in a
1469 way that causes the resulting location information to be selected
1470 with little or no error. For instance, GNSS measurements are easy to
1471 use for this purpose because all the contextual information necessary
1472 to calculate a position using measurements is broadcast by the
1473 satellites [HARPER].
1475 An attacker that falsifies measurement data gains little if they are
1476 the only recipients of the result. The attacker knows that the
1477 location information is bad. The attacker only gains if the
1478 information can somehow be attributed to the LIS by another location
1479 recipient. By coercing the LIS into providing falsified location
1480 information, any credibility that the LIS might have - that the
1481 attacker does not - is gained by the attacker.
1483 A third-party that is reliant on the integrity of the location
1484 information might base an evaluation of the credibility of the
1485 information on the source of the information. If that third party is
1486 able to attribute location information to the LIS, then an attacker
1487 might gain.
1489 Location information that is provided to the Device without any means
1490 to identify the LIS as its source is not subject to this attack. The
1491 Device is identified as the source of the data when it distributes
1492 the location information to location recipients.
1494 Location information is attributed to the LIS either through the use
1495 of digital signatures or by having the location recipient directly
1496 interact with the LIS. A LIS that digitally signs location
1497 information becomes identifiable as the source of the data.
1498 Similarly, the LIS is identified as a source of data if a location
1499 recipient acquires information directly from a LIS using a location
1500 URI.
1502 7.1.5. Measurement Replay
1503 The value of some measured properties do not change over time for a
1504 single location. For properties of a network, time-invariance is
1505 often directly as a result of the practicalities of operating the
1506 network. Limiting the changes to a network ensures greater
1507 consistency of service. A largely static network also greatly
1508 simplifies the data management tasks involved with providing a
1509 location service. However, time invariant properties allow for
1510 simple replay attacks, where an attacker acquires measurements that
1511 can later be used without being detected as being invalid.
1513 Measurement data is frequently an observation of an time-invariant
1514 property of the environment at the subject location. For
1515 measurements of this nature, nothing in the measurement itself is
1516 sufficient proof that the Device is present at the resulting
1517 location. Measurement data might have been previously acquired and
1518 reused.
1520 For instance, the identity of a radio transmitter, if broadcast by
1521 that transmitter, can be collected and stored. An attacker that
1522 wishes it known that they exist at a particular location, can claim
1523 to observe this transmitter at any time. Nothing inherent in the
1524 claim reveals it to be false.
1526 7.1.6. Environment Spoofing
1528 Some types of measurement data can be altered or influenced by a
1529 third party so that a Device unwittingly provides falsified data. If
1530 it is possible for a third party to alter the measured phenomenon,
1531 then any location information that is derived from this data can be
1532 indirectly influenced.
1534 Altering the environment in this fashion might not require
1535 involvement with either Device or LIS. Measurement that is passive -
1536 where the Device observes a signal or other phenomenon without direct
1537 interaction - are most susceptible to alteration by third parties.
1539 Measurement of radio signal characteristics is especially vulnerable
1540 since an adversary need only be in the general vicinity of the Device
1541 and be able to transmit a signal. For instance, a GNSS spoofer is
1542 able to produce fake signals that claim to be transmitted by any
1543 satellite or set of satellites (see [GPS.SPOOF]).
1545 Measurements that require direct interaction increases the complexity
1546 of the attack. For measurements relating to the communication
1547 medium, a third party cannot avoid direct interaction, they need only
1548 be on the communications path (that is, man in the middle).
1550 Even if the entity that is interacted with is authenticated, this
1551 does not provide any assurance about the integrity of measurement
1552 data. For instance, the Device might authenticate the identity of a
1553 radio transmitter through the use of cryptographic means and obtain
1554 signal strength measurements for that transmitter. Radio signal
1555 strength is trivial for an attacker to increase simply by receiving
1556 and amplifying the raw signal; it is not necessary for the attacker
1557 to be able to understand the signal content.
1559 Note: This particular "attack" is more often completely legitimate.
1560 Radio repeaters are commonplace mechanism used to increase radio
1561 coverage.
1563 Attacks that rely on altering the observed environment of a Device
1564 require countermeasures that affect the measurement process. For
1565 radio signals, countermeasures could include the use of authenticated
1566 signals, or altered receiver design. In general, countermeasures are
1567 highly specific to the individual measurement process. An exhaustive
1568 discussion of these issues is left to the relevant literature for
1569 each measurement technology.
1571 A Device that provides measurement data is assumed to be responsible
1572 for applying appropriate countermeasures against this type of attack.
1574 Where a Device is the sole recipient of location information derived
1575 from measurement data, a LIS might choose to provide location
1576 information without any validation. The responsibility for ensuring
1577 the veracity of the measurement data lies with the Device.
1579 Measurement data that is susceptible to this sort of influence SHOULD
1580 be treated as though it were produced by an untrusted Device for
1581 those cases where a location recipient might attribute the location
1582 information to the LIS. GNSS measurements and radio signal strength
1583 measurements can be affected relatively cheaply, though almost all
1584 other measurement types can be affected with varying costs to an
1585 attacker, with the largest cost often being a requirement for
1586 physical access. To the extent that it is feasible, measurement data
1587 SHOULD be subjected to the same validation as for other types of
1588 attacks that rely on measurement falsification.
1590 Note: Altered measurement data might be provided by a Device that
1591 has no knowledge of the alteration. Thus, an otherwise trusted
1592 Device might still be an unreliable source of measurement data.
1594 7.2. Mitigation
1595 The following measures can be applied to limit or prevent attacks.
1596 The effectiveness of each depends on the type of measurement data and
1597 how that measurement data is acquired.
1599 Two general approaches are identified for dealing with untrusted
1600 measurement data:
1602 1. Require independent validation of measurement data or the
1603 location information that is produced.
1605 2. Identify the types of sources that provided the measurement data
1606 that location information was derived from.
1608 This section goes into more detail on the different forms of
1609 validation in Section 7.2.1, Section 7.2.2, and Section 7.2.3. The
1610 impact of attributing location information to sources is discussed in
1611 more detail in Section 7.2.4.
1613 Any costs in validation are balanced against the degree of integrity
1614 desired from the resulting location information.
1616 7.2.1. Measurement Validation
1618 Detecting that measurement data has been falsified is difficult in
1619 the absence of integrity mechanisms.
1621 Independent confirmation of the veracity of measurement data ensures
1622 that the measurement is accurate and that it applies to the correct
1623 Device. When it's possible to gathering the same measurement data
1624 from a trusted and independent source without undue expense, the LIS
1625 can use the trusted data in place of what the untrusted Device has
1626 sent. In cases where that is impractical, the untrusted data can
1627 provide hints that allow corroboration of the data (see
1628 Section 7.2.1.1).
1630 Measurement information might contain no inherent indication that it
1631 is falsified. On the contrary, it can be difficult to obtain
1632 information that would provide any degree of assurance that the
1633 measurement device is physically at any particular location.
1634 Measurements that are difficult to verify require other forms of
1635 assurance before they can be used.
1637 7.2.1.1. Effectiveness
1639 Measurement validation MUST be used if measurement data for a
1640 particular Device can be easily acquired by unauthorized location
1641 recipients, as described in Section 7.1.1. This prevents
1642 unauthorized access to location information using measurement data.
1644 Validation of measurement data can be significantly more effective
1645 than independent acquisition of the same. For instance, a Device in
1646 a large Ethernet network could provide a measurement indicating its
1647 point of attachment using LLDP measurements. For a LIS, acquiring
1648 the same measurement data might require a request to all switches in
1649 that network. With the measurement data, validation can target the
1650 identified switch with a specific query.
1652 Validation is effective in identifying falsified measurement data
1653 (Section 7.1.4), including attacks involving replay of measurement
1654 data (Section 7.1.5). Validation also limits the amount of network
1655 topology information (Section 7.1.2) made available to Devices to
1656 that portion of the network topology that they are directly attached.
1658 Measurement validation has no effect if the underlying effect is
1659 being spoofed (Section 7.1.6).
1661 7.2.1.2. Limitations (Unique Observer)
1663 A Device is often in a unique position to make a measurement. It
1664 alone occupies the point in space-time that the location
1665 determination process seeks to determine. The Device becomes a
1666 unique observer for a particular property.
1668 The ability of the Device to become a unique observer makes the
1669 Device invaluable to the location determination process. As a unique
1670 observer, it also makes the claims of a Device difficult to validate
1671 and easily to spoof.
1673 As long as no other entity is capable of making the same
1674 measurements, there is also no other entity that can independently
1675 check that the measurements are correct and applicable to the Device.
1676 A LIS might be unable to validate all or part of the measurement data
1677 it receives from a unique observer. For instance, a signal strength
1678 measurement of the signal from a radio tower cannot be validated
1679 directly.
1681 Some portion of the measurement data might still be independently
1682 verified, even if all information cannot. In the previous example,
1683 the radio tower might be able to provide verification that the Device
1684 is present if it is able to observe a radio signal sent by the
1685 Device.
1687 If measurement data can only be partially validated, the extent to
1688 which it can be validated determines the effectiveness of validation
1689 against these attacks.
1691 The advantage of having the Device as a unique observer is that it
1692 makes it difficult for an attacker to acquire measurements without
1693 the assistance of the Device. Attempts to use measurements to gain
1694 unauthorized access to measurement data (Section 7.1.1) are largely
1695 ineffectual against a unique observer.
1697 7.2.2. Location Validation
1699 Location information that is derived from location-related
1700 measurement data can also be verified against trusted location
1701 information. Rather than validating inputs to the location
1702 determination process, suspect locations are identified at the output
1703 of the process.
1705 Trusted location information is acquired using sources of measurement
1706 data that are trusted. Untrusted location information is acquired
1707 using measurement data provided from untrusted sources, which might
1708 include the Device. These two locations are compared. If the
1709 untrusted location agrees with the trusted location, the untrusted
1710 location information is used.
1712 Algorithms for the comparison of location information are not
1713 included in this document. However, a simple comparison for
1714 agreement might require that the untrusted location be entirely
1715 contained within the uncertainty region of the trusted location.
1717 There is little point in using a less accurate, less trusted
1718 location. Untrusted location information that has worse accuracy
1719 than trusted information can be immediately discarded. There are
1720 multiple factors that affect accuracy, uncertainty and currency being
1721 the most important. How location information is compared for
1722 accuracy is not defined in this document.
1724 7.2.2.1. Effectiveness
1726 Location validation limits the extent to which falsified - or
1727 erroneous - measurement data can cause an incorrect location to be
1728 reported.
1730 Location validation can be more efficient than validation of inputs,
1731 particularly for a unique observer (Section 7.2.1.2).
1733 Validating location ensures that the Device is at or near the
1734 resulting location. Location validation can be used to limit or
1735 prevent all of the attacks identified in this document.
1737 7.2.2.2. Limitations
1738 The trusted location that is used for validation is always less
1739 accurate than the location that is being checked. The amount by
1740 which the untrusted location is more accurate, is the same amount
1741 that an attacker can exploit.
1743 For example, a trusted location might indicate a five kilometer
1744 radius uncertainty region. An untrusted location that describes a
1745 100 meter uncertainty within the larger region might be accepted as
1746 more accurate. An attacker might still falsify measurement data to
1747 select any location within the larger uncertainty region. While the
1748 100 meter uncertainty that is reported seems more accurate, a
1749 falsified location could be anywhere in the five kilometer region.
1751 Where measurement data might have been falsified, the actual
1752 uncertainty is effectively much higher. Local policy might allow
1753 differing degrees of trust to location information derived from
1754 untrusted measurement data. This might be a boolean operation with
1755 only two possible outcomes: untrusted location information might be
1756 used entirely or not at all. Alternatively, untrusted location could
1757 be combined with trusted location information using different
1758 weightings, based on a value set in local policy.
1760 7.2.3. Supporting Observations
1762 Replay attacks using previously acquired measurement data are
1763 particularly hard to detect without independent validation. Rather
1764 than validate the measurement data directly, supplementary data might
1765 be used to validate measurements or the location information derived
1766 from those measurements.
1768 These supporting observations could be used to convey information
1769 that provides additional assurance that the Device was acquired at a
1770 specific time and place. In effect, the Device is requested to
1771 provide proof of its presence at the resulting location.
1773 For instance, a Device that measures attributes of a radio signal
1774 could also be asked to provide a sample of the measured radio signal.
1775 If the LIS is able to observe the same signal, the two observations
1776 could be compared. Providing that the signal cannot be predicted in
1777 advance by the Device, this could be used to support the claim that
1778 the Device is able to receive the signal. Thus, the Device is likely
1779 to be within the range that the signal is transmitted. A LIS could
1780 use this to attribute a higher level of trust in the associated
1781 measurement data or resulting location.
1783 7.2.3.1. Effectiveness
1784 The use of supporting observations is limited by the ability of the
1785 LIS to acquire and validate these observations. The advantage of
1786 selecting observations independent of measurement data is that
1787 observations can be selected based on how readily available the data
1788 is for both LIS and Device. The amount and quality of the data can
1789 be selected based on the degree of assurance that is desired.
1791 Use of supporting observations is similar to both measurement
1792 validation and location validation. All three methods rely on
1793 independent validation of one or more properties. Applicability of
1794 each method is similar.
1796 Use of supporting observations can be used to limit or prevent all of
1797 the attacks identified in this document.
1799 7.2.3.2. Limitations
1801 The effectiveness of the validation method depends on the quality of
1802 the supporting observation: how hard it is to obtain at a different
1803 time or place, how difficult it is to guess, and what other costs
1804 might be involved in acquiring this data.
1806 In the example of an observed radio signal, requesting a sample of
1807 the signal only provides an assurance that the Device is able to
1808 receive the signal transmitted by the measured radio transmitter.
1809 This only provides some assurance that the Device is within range of
1810 the transmitter.
1812 As with location validation, a Device might still be able to provide
1813 falsified measurements that could alter the value of the location
1814 information as long as the result is within this region.
1816 Requesting additional supporting observations can reduce the size of
1817 the region over which location information can be altered by an
1818 attacker, or increase trust in the result, but each additional
1819 measurement imposes an acquisition cost. Supporting observations
1820 contribute little or nothing toward the primary goal of determining
1821 the location of the Device.
1823 7.2.4. Attribution
1825 Lying by proxy (Section 7.1.4) relies on the location recipient being
1826 able to attribute location information to a LIS. The effectiveness
1827 of this attack is negated if location information is explicitly
1828 attributed to a particular source.
1830 This requires an extension to the location object that explicitly
1831 identifies the source (or sources) of each item of location
1832 information.
1834 Rather than relying on a process that seeks to ensure that location
1835 information is accurate, this approach instead provides a location
1836 recipient with the information necessary to reach their own
1837 conclusion about the trustworthiness of the location information.
1839 Including an authenticated identity for all sources of measurement
1840 data presents a number of technical and operational challenges. It
1841 is possible that the LIS has a transient relationship with a Device.
1842 A Device is not expected to share authentication information with a
1843 LIS. There is no assurance that Device identification is usable by a
1844 potential location recipient. Privacy concerns might also prevent
1845 the sharing identification information, even if it were available and
1846 usable.
1848 Identifying the type of measurement source allows a location
1849 recipient to make a decision about the trustworthiness of location
1850 information without depending on having authenticated identity
1851 information for each source. An element for this purpose is defined
1852 in Section 4.4.
1854 When including location information that is based on measurement data
1855 from sources that might be untrusted, a LIS SHOULD include
1856 alternative location information that is derived from trusted sources
1857 of measurement data. Each item of location information can then be
1858 labelled with the source of that data.
1860 A location recipient that is able to identify a specific source of
1861 measurement data (whether it be LIS or Device) can use this
1862 information to attribute location information to either or both
1863 entity. The location recipient is then better able to make decisions
1864 about trustworthiness based on the source of the data.
1866 A location recipient that does not understand the "source" element is
1867 unable to make this distinction. When constructing a PIDF-LO
1868 document, trusted location information MUST be placed in the PIDF-LO
1869 so that it is given higher priority to any untrusted location
1870 information according to Rule #8 of [RFC5491].
1872 Attribution of information does nothing to address attacks that alter
1873 the observed parameters that are used in location determination
1874 (Section 7.1.6).
1876 7.2.5. Stateful Correlation of Location Requests
1877 Stateful examination of requests can be used to prevent a Device from
1878 attempting to map network topology using requests for location
1879 information (Section 7.1.2).
1881 Simply limiting the rate of requests from a single Device reduces the
1882 amount of data that a Device can acquire about network topology. A
1883 LIS could also make observations about the movements of a Device. A
1884 Device that is attempting to gather topology information is likely to
1885 be assigned a location that changes significantly between subsequent
1886 requests, possibly violating physical laws (or lower limits that
1887 might still be unlikely) with respect to speed and acceleration.
1889 7.3. An Unauthorized or Compromised LIS
1891 A compromised LIS, or a compromise in LIS discovery [RFC5986] could
1892 lead to an unathorized entity obtaining measurement data. This
1893 information could then be used or redistributed. A Device MUST
1894 ensure that it authenticate a LIS, as described in Section 9 of
1895 [RFC5985].
1897 An entity that is able to acquire measurement data can, in addition
1898 to using those measurements to learn the location of a Device, also
1899 use that information for other purposes. This information can be
1900 used to provide insight into network topology (Section 7.1.2).
1902 Measurement data might also be exploited in other ways. For example,
1903 revealing the type of 802.11 transceiver that a Device uses could
1904 allow an attacker to use specific vulnerabilities to attack a Device.
1905 Similarly, revealing information about network elements could enable
1906 targeted attacks on that infrastructure.
1908 8. Measurement Schemas
1910 The schema are broken up into their respective functions. There is a
1911 base container schema into which all measurements are placed, plus
1912 definitions for a measurement request (Section 8.1). A PIDF-LO
1913 extension is defined in a separate schema (Section 8.2). There is a
1914 basic types schema, that contains various base type definitions for
1915 things such as the "rmsError" and "samples" attributes IPv4, IPv6 and
1916 MAC addresses (Section 8.3). Then each of the specific measurement
1917 types is defined in its own schema.
1919 8.1. Measurement Container Schema
1921
1922
1930
1931
1933
1934
1935
1937 This schema defines a framework for location measurements.
1938
1939
1941
1943
1944
1945
1946
1947
1948
1950
1951
1952
1953
1954
1955
1956
1957
1958
1960
1962
1963
1964
1965
1966
1968
1970
1971
1972
1974
1976
1977
1978
1979
1980
1981
1983
1984
1985
1986
1987
1988
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2005 Measurement Container Schema
2007 8.2. Measurement Source Schema
2009
2010
2017
2018
2020
2021
2022
2024 This schema defines an extension to PIDF-LO that indicates the
2025 type of source that produced the measurement data used in
2026 generating the associated location information.
2027
2028
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2044 Measurement Source PIDF-LO Extension Schema
2046 8.3. Base Type Schema
2048 Note that the pattern rules in the following schema wrap due to
2049 length constraints. None of the patterns contain whitespace.
2051
2052
2059
2060
2062
2063
2064
2066 This schema defines a set of base type elements.
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2109
2110
2111
2113
2114
2115
2116
2118 An IP version 6 address, based on RFC 4291.
2119
2120
2121
2122
2123
2124
2125
2126
2127
2129
2131
2133
2135
2137
2139
2140
2141
2142
2150
2151
2152
2153
2155
2156
2157
2158
2162
2163
2165
2166
2167
2168
2170
2171
2173
2175 Base Type Schema
2177 8.4. LLDP Measurement Schema
2179
2180
2188
2189
2191
2192
2193
2195 This schema defines a set of LLDP location measurements.
2196
2197
2199
2201
2202
2203
2204
2205
2206
2207
2208
2210
2211
2212
2213
2215
2217
2218
2219
2220
2222
2223
2224
2226
2227
2228
2229
2230
2231
2233
2235 LLDP measurement schema
2237 8.5. DHCP Measurement Schema
2239
2240
2248
2249
2251
2252
2253
2255 This schema defines a set of DHCP location measurements.
2256
2257
2259
2261
2262
2263
2264
2265
2266
2267
2268
2270
2272
2274
2276
2277
2278
2279
2280
2282
2283
2284
2285
2287
2288
2289
2291
2293 DHCP measurement schema
2295 8.6. WiFi Measurement Schema
2297
2298
2307
2308
2310 802.11 location measurements
2312
2313
2314
2316 This schema defines a basic set of 802.11 location measurements.
2317
2318
2320
2321
2323
2325
2326
2327
2328
2329
2331
2333
2334
2335
2336
2337
2339
2340
2341
2342
2343
2344
2346
2348
2350
2352
2354
2356
2358
2361
2363
2365
2366
2368
2369
2370
2371
2373
2374
2375
2376
2378
2379
2380
2382
2384
2385
2386
2387
2388
2390
2391
2392
2393
2394
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2415
2416
2417
2418
2419
2421
2422
2424
2426
2428
2429
2430
2431
2433
2434
2435
2436
2437
2438
2439
2441
2442
2443
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2458
2459
2461
2463 WiFi measurement schema
2465 8.7. Cellular Measurement Schema
2467
2468
2475
2476
2478
2479
2480
2482 This schema defines a set of cellular location measurements.
2483
2484
2486
2488
2489
2490
2491
2492
2493
2494
2495
2496
2498
2499
2500
2501
2502
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2523
2524
2525
2526
2527
2528
2530
2531
2533
2534
2535
2536
2538
2539
2540
2541
2542
2544
2545
2546
2547
2548
2550
2551
2552
2553
2555
2557
2559
2560
2561
2562
2563
2564
2565
2566
2567
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2584
2586 Cellular measurement schema
2588 8.8. GNSS Measurement Schema
2590
2591
2599
2600
2602
2603
2604
2606 This schema defines a set of GNSS location measurements
2607
2608
2610
2612
2613
2614
2615
2616
2617
2618
2620
2621
2622
2623
2624
2626
2628
2630
2631
2632
2633
2634
2635
2636
2638
2639
2640
2641
2642
2643
2645
2646
2648
2650
2652
2653
2655
2656
2657
2659
2660
2661
2662
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2677 GNSS measurement Schema
2679 8.9. DSL Measurement Schema
2681
2682
2690
2691
2693 DSL measurement definitions
2694
2695
2696
2698 This schema defines a basic set of DSL location measurements.
2699
2701
2703
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2761
2763 DSL measurement schema
2765 9. IANA Considerations
2767 This section creates a registry for GNSS types (Section 5.5) and
2768 registers the namespaces and schema defined in Section 8.
2770 9.1. IANA Registry for GNSS Types
2772 This document establishes a new IANA registry for "Global Navigation
2773 Satellite System (GNSS) types". The registry includes tokens for the
2774 GNSS type and for each of the signals within that type. Referring to
2775 [RFC5226], this registry operates under "Specification Required"
2776 rules. The IESG will appoint an Expert Reviewer who will advise IANA
2777 promptly on each request for a new or updated GNSS type.
2779 Each entry in the registry requires the following information:
2781 GNSS name: the name of the GNSS
2783 Brief description: a brief description of the GNSS
2785 GNSS token: a token that can be used to identify the GNSS
2787 Signals: a set of tokens that represent each of the signals that the
2788 system provides
2790 Documentation reference: a reference to one or more stable, public
2791 specifications that outline usage of the GNSS, including (but not
2792 limited to) signal specifications and time systems
2794 The registry initially includes two registrations:
2796 GNSS name: Global Positioning System (GPS)
2797 Brief description: a system of satellites that use spread-spectrum
2798 transmission, operated by the US military for commercial and
2799 military applications
2801 GNSS token: gps
2803 Signals: L1, L2, L1C, L2C, L5
2805 Documentation reference: Navstar GPS Space Segment/Navigation User
2806 Interface [GPS.ICD]
2808 GNSS name: Galileo
2810 Brief description: a system of satellites that operate in the same
2811 spectrum as GPS, operated by the European Union for commercial
2812 applications
2814 GNSS Token: galileo
2816 Signals: L1, E5A, E5B, E5A+B, E6
2818 Documentation Reference: Galileo Open Service Signal In Space
2819 Interface Control Document (SIS ICD) [Galileo.ICD]
2821 9.2. URN Sub-Namespace Registration for
2822 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
2824 This section registers a new XML namespace,
2825 "urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc", as per the guidelines
2826 in [RFC3688].
2828 URI: urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
2830 Registrant Contact: IETF, GEOPRIV working group,
2831 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2833 XML:
2835 BEGIN
2836
2837
2839
2840
2841 Measurement Source for PIDF-LO
2842
2843
2844 Namespace for Location Measurement Source
2845 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
2846 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2847 with the RFC number for this specification.]]
2848 See RFCXXXX.
2849
2850
2851 END
2853 9.3. URN Sub-Namespace Registration for
2854 urn:ietf:params:xml:ns:geopriv:lm
2856 This section registers a new XML namespace,
2857 "urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in
2858 [RFC3688].
2860 URI: urn:ietf:params:xml:ns:geopriv:lm
2862 Registrant Contact: IETF, GEOPRIV working group,
2863 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2865 XML:
2867 BEGIN
2868
2869
2871
2872
2873 Measurement Container
2874
2875
2876 Namespace for Location Measurement Container
2877 urn:ietf:params:xml:ns:geopriv:lm
2878 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2879 with the RFC number for this specification.]]
2880 See RFCXXXX.
2881
2882
2883 END
2885 9.4. URN Sub-Namespace Registration for
2886 urn:ietf:params:xml:ns:geopriv:lm:basetypes
2888 This section registers a new XML namespace,
2889 "urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines
2890 in [RFC3688].
2892 URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes
2894 Registrant Contact: IETF, GEOPRIV working group,
2895 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2897 XML:
2899 BEGIN
2900
2901
2903
2904
2905 Base Device Types
2906
2907
2908 Namespace for Base Types
2909 urn:ietf:params:xml:ns:geopriv:lm:basetypes
2910 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2911 with the RFC number for this specification.]]
2912 See RFCXXXX.
2913
2914
2915 END
2917 9.5. URN Sub-Namespace Registration for
2918 urn:ietf:params:xml:ns:geopriv:lm:lldp
2920 This section registers a new XML namespace,
2921 "urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in
2922 [RFC3688].
2924 URI: urn:ietf:params:xml:ns:geopriv:lm:lldp
2926 Registrant Contact: IETF, GEOPRIV working group,
2927 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2929 XML:
2931 BEGIN
2932
2933
2935
2936
2937 LLDP Measurement Set
2938
2939
2940 Namespace for LLDP Measurement Set
2941 urn:ietf:params:xml:ns:geopriv:lm:lldp
2942 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2943 with the RFC number for this specification.]]
2944 See RFCXXXX.
2945
2946
2947 END
2949 9.6. URN Sub-Namespace Registration for
2950 urn:ietf:params:xml:ns:geopriv:lm:dhcp
2952 This section registers a new XML namespace,
2953 "urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in
2954 [RFC3688].
2956 URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp
2958 Registrant Contact: IETF, GEOPRIV working group,
2959 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2961 XML:
2963 BEGIN
2964
2965
2967
2968
2969 DHCP Measurement Set
2970
2971
2972 Namespace for DHCP Measurement Set
2973 urn:ietf:params:xml:ns:geopriv:lm:dhcp
2974 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2975 with the RFC number for this specification.]]
2976 See RFCXXXX.
2977
2979
2980 END
2982 9.7. URN Sub-Namespace Registration for
2983 urn:ietf:params:xml:ns:geopriv:lm:wifi
2985 This section registers a new XML namespace,
2986 "urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in
2987 [RFC3688].
2989 URI: urn:ietf:params:xml:ns:geopriv:lm:wifi
2991 Registrant Contact: IETF, GEOPRIV working group,
2992 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2994 XML:
2996 BEGIN
2997
2998
3000
3001
3002 WiFi Measurement Set
3003
3004
3005 Namespace for WiFi Measurement Set
3006 urn:ietf:params:xml:ns:geopriv:lm:wifi
3007 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
3008 with the RFC number for this specification.]]
3009 See RFCXXXX.
3010
3011
3012 END
3014 9.8. URN Sub-Namespace Registration for
3015 urn:ietf:params:xml:ns:geopriv:lm:cell
3017 This section registers a new XML namespace,
3018 "urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in
3019 [RFC3688].
3021 URI: urn:ietf:params:xml:ns:geopriv:lm:cell
3023 Registrant Contact: IETF, GEOPRIV working group,
3024 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
3026 XML:
3028 BEGIN
3029
3030
3032
3033
3034 Cellular Measurement Set
3035
3036
3037 Namespace for Cellular Measurement Set
3038 urn:ietf:params:xml:ns:geopriv:lm:cell
3039 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
3040 with the RFC number for this specification.]]
3041 See RFCXXXX.
3042
3043
3044 END
3046 9.9. URN Sub-Namespace Registration for
3047 urn:ietf:params:xml:ns:geopriv:lm:gnss
3049 This section registers a new XML namespace,
3050 "urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in
3051 [RFC3688].
3053 URI: urn:ietf:params:xml:ns:geopriv:lm:gnss
3055 Registrant Contact: IETF, GEOPRIV working group,
3056 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
3058 XML:
3060 BEGIN
3061
3062
3064
3065
3066 GNSS Measurement Set
3067
3068
3069 Namespace for GNSS Measurement Set
3070 urn:ietf:params:xml:ns:geopriv:lm:gnss
3071 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
3072 with the RFC number for this specification.]]
3073 See RFCXXXX.
3074
3075
3076 END
3078 9.10. URN Sub-Namespace Registration for
3079 urn:ietf:params:xml:ns:geopriv:lm:dsl
3081 This section registers a new XML namespace,
3082 "urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in
3083 [RFC3688].
3085 URI: urn:ietf:params:xml:ns:geopriv:lm:dsl
3087 Registrant Contact: IETF, GEOPRIV working group,
3088 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
3090 XML:
3092 BEGIN
3093
3094
3096
3097
3098 DSL Measurement Set
3099
3100
3101 Namespace for DSL Measurement Set
3102 urn:ietf:params:xml:ns:geopriv:lm:dsl
3103 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
3104 with the RFC number for this specification.]]
3105 See RFCXXXX.
3106
3107
3108 END
3110 9.11. XML Schema Registration for Measurement Source Schema
3112 This section registers an XML schema as per the guidelines in
3113 [RFC3688].
3115 URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc
3117 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3118 Martin Thomson (martin.thomson@commscope.com).
3120 Schema: The XML for this schema can be found in Section 8.2 of this
3121 document.
3123 9.12. XML Schema Registration for Measurement Container Schema
3125 This section registers an XML schema as per the guidelines in
3126 [RFC3688].
3128 URI: urn:ietf:params:xml:schema:lm
3130 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3131 Martin Thomson (martin.thomson@commscope.com).
3133 Schema: The XML for this schema can be found in Section 8.1 of this
3134 document.
3136 9.13. XML Schema Registration for Base Types Schema
3138 This section registers an XML schema as per the guidelines in
3139 [RFC3688].
3141 URI: urn:ietf:params:xml:schema:lm:basetypes
3143 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3144 Martin Thomson (martin.thomson@commscope.com).
3146 Schema: The XML for this schema can be found in Section 8.3 of this
3147 document.
3149 9.14. XML Schema Registration for LLDP Schema
3151 This section registers an XML schema as per the guidelines in
3152 [RFC3688].
3154 URI: urn:ietf:params:xml:schema:lm:lldp
3156 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3157 Martin Thomson (martin.thomson@commscope.com).
3159 Schema: The XML for this schema can be found in Section 8.4 of this
3160 document.
3162 9.15. XML Schema Registration for DHCP Schema
3164 This section registers an XML schema as per the guidelines in
3165 [RFC3688].
3167 URI: urn:ietf:params:xml:schema:lm:dhcp
3168 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3169 Martin Thomson (martin.thomson@commscope.com).
3171 Schema: The XML for this schema can be found in Section 8.5 of this
3172 document.
3174 9.16. XML Schema Registration for WiFi Schema
3176 This section registers an XML schema as per the guidelines in
3177 [RFC3688].
3179 URI: urn:ietf:params:xml:schema:lm:wifi
3181 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3182 Martin Thomson (martin.thomson@commscope.com).
3184 Schema: The XML for this schema can be found in Section 8.6 of this
3185 document.
3187 9.17. XML Schema Registration for Cellular Schema
3189 This section registers an XML schema as per the guidelines in
3190 [RFC3688].
3192 URI: urn:ietf:params:xml:schema:lm:cellular
3194 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3195 Martin Thomson (martin.thomson@commscope.com).
3197 Schema: The XML for this schema can be found in Section 8.7 of this
3198 document.
3200 9.18. XML Schema Registration for GNSS Schema
3202 This section registers an XML schema as per the guidelines in
3203 [RFC3688].
3205 URI: urn:ietf:params:xml:schema:lm:gnss
3207 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3208 Martin Thomson (martin.thomson@commscope.com).
3210 Schema: The XML for this schema can be found in Section 8.8 of this
3211 document.
3213 9.19. XML Schema Registration for DSL Schema
3214 This section registers an XML schema as per the guidelines in
3215 [RFC3688].
3217 URI: urn:ietf:params:xml:schema:lm:dsl
3219 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3220 Martin Thomson (martin.thomson@commscope.com).
3222 Schema: The XML for this schema can be found in Section 8.9 of this
3223 document.
3225 10. Acknowledgements
3227 Thanks go to Simon Cox for his comments relating to terminology that
3228 have helped ensure that this document is aligned with ongoing work in
3229 the Open Geospatial Consortium (OGC). Thanks to Neil Harper for his
3230 review and comments on the GNSS sections of this document. Thanks to
3231 Noor-E-Gagan Singh, Gabor Bajko, Russell Priebe, and Khalid Al-Mufti
3232 for their significant input to and suggestions for improving the
3233 802.11 measurements. Thanks to Cullen Jennings for feedback and
3234 suggestions. Bernard Aboba provided review and feedback on a range
3235 of measurement data definitions. Mary Barnes and Geoff Thompson
3236 provided a review and corrections. David Waitzman and John Bressler
3237 both noted shortcomings with 802.11 measurements. Keith Drage,
3238 Darren Pawson provided expert LTE knowledge.
3240 11. References
3242 11.1. Normative References
3244 [ASCII] , "US-ASCII. Coded Character Set - 7-Bit American Standard
3245 Code for Information Interchange. Standard ANSI X3.4-1986,
3246 ANSI, 1986.", .
3248 [GPS.ICD] , "Navstar GPS Space Segment/Navigation User Interface",
3249 ICD GPS-200, Apr 2000.
3251 [Galileo.ICD]
3252 GJU, "Galileo Open Service Signal In Space Interface
3253 Control Document (SIS ICD)", May 2006.
3255 [IANA.enterprise]
3256 IANA, "Private Enterprise Numbers", 2011,
3257 .
3259 [IEEE.80211]
3260 IEEE, "Wireless LAN Medium Access Control (MAC) and
3261 Physical Layer (PHY) specifications", IEEE Std
3262 802.11-2012, March 2012.
3264 [IEEE.8021AB]
3265 IEEE, "IEEE Standard for Local and Metropolitan area
3266 networks, Station and Media Access Control Connectivity
3267 Discovery", IEEE Std 802.1AB-2009, September 2009.
3269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3270 Requirement Levels", BCP 14, RFC 2119, March 1997.
3272 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3273 3046, January 2001.
3275 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
3276 and M. Carney, "Dynamic Host Configuration Protocol for
3277 IPv6 (DHCPv6)", RFC 3315, July 2003.
3279 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
3280 10646", STD 63, RFC 3629, November 2003.
3282 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
3283 Resource Identifier (URI): Generic Syntax", STD 66, RFC
3284 3986, January 2005.
3286 [RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID
3287 Suboption for the Dynamic Host Configuration Protocol
3288 (DHCP) Relay Agent Option", RFC 3993, March 2005.
3290 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
3291 Format", RFC 4119, December 2005.
3293 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
3294 Architecture", RFC 4291, February 2006.
3296 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6
3297 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, June
3298 2006.
3300 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
3301 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August
3302 2006.
3304 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
3305 Presence Information Data Format Location Object (PIDF-LO)
3306 Usage Clarification, Considerations, and Recommendations",
3307 RFC 5491, March 2009.
3309 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
3310 Address Text Representation", RFC 5952, August 2010.
3312 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC
3313 5985, September 2010.
3315 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
3316 Location Information Server (LIS)", RFC 5986, September
3317 2010.
3319 [TIA-2000.5]
3320 TIA/EIA, "Upper Layer (Layer 3) Signaling Standard for
3321 cdma2000(R) Spread Spectrum Systems", TIA-2000.5-D, March
3322 2004.
3324 [TS.3GPP.23.003]
3325 3GPP, "Numbering, addressing and identification", 3GPP TS
3326 23.003 9.4.0, September 2010.
3328 11.2. Informative References
3330 [ANSI-TIA-1057]
3331 ANSI/TIA, "Link Layer Discovery Protocol for Media
3332 Endpoint Devices", TIA 1057, April 2006.
3334 [DSL.TR025]
3335 Wang, R., "Core Network Architecture Recommendations for
3336 Access to Legacy Data Networks over ADSL", September 1999.
3338 [DSL.TR101]
3339 Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL
3340 Aggregation", April 2006.
3342 [GPS.SPOOF]
3343 Scott, L., "Anti-Spoofing and Authenticated Signal
3344 Architectures for Civil Navigation Signals", ION-GNSS
3345 Portland, Oregon, 2003.
3347 [HARPER] Harper, N., Dawson, M., and D. Evans, "Server-side
3348 spoofing and detection for Assisted-GPS", Proceedings of
3349 International Global Navigation Satellite Systems Society
3350 (IGNSS) Symposium 2009 16, December 2009,
3351 .
3353 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
3354 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
3355 RFC 2661, August 1999.
3357 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
3358 "Remote Authentication Dial In User Service (RADIUS)", RFC
3359 2865, June 2000.
3361 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
3362 January 2004.
3364 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
3365 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
3367 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
3368 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
3369 May 2008.
3371 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R.
3372 Barnes, "Use of Device Identity in HTTP-Enabled Location
3373 Delivery (HELD)", RFC 6155, March 2011.
3375 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
3376 Tschofenig, H., and H. Schulzrinne, "An Architecture for
3377 Location and Location Privacy in Internet Applications",
3378 BCP 160, RFC 6280, July 2011.
3380 Authors' Addresses
3382 Martin Thomson
3383 Microsoft
3384 3210 Porter Drive
3385 Palo Alto, CA 94304
3386 US
3388 Phone: +1 650-353-1925
3389 Email: martin.thomson@skype.net
3391 James Winterbottom
3392 Unaffiliated
3393 AU
3395 Email: a.james.winterbottom@gmail.com