idnits 2.17.1
draft-ietf-geopriv-held-measurements-09.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 (September 06, 2013) is 3876 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 2160, but not defined
== Missing Reference: '0-4' is mentioned on line 2160, but not defined
== Missing Reference: '0-9' is mentioned on line 2160, but not defined
== Missing Reference: '0-1' is mentioned on line 2160, 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: March 10, 2014 Unaffiliated
6 September 06, 2013
8 Using Device-provided Location-Related Measurements in Location
9 Configuration Protocols
10 draft-ietf-geopriv-held-measurements-09
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 March 10, 2014.
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 . . . . . . . . . . . . . 8
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 provided whenever possible. This
334 allows a LIS to avoid selecting an arbitrary timestamp. Exceptions
335 to this, where omitting time might make sense, include relatively
336 static types of measurement (for instance, the DSL measurements in
337 Section 5.6) or for legacy Devices that don't record time information
338 (such as the Home Location Register/Home Subscriber Server for
339 cellular).
341 The "time" attribute is attached to the root "measurement" element.
342 Multiple measurements can often be given the same timestamp, even
343 when the measurements were not actually taken at the same time
344 (consider a set of measurements taken sequentially, where the
345 difference in time between observations is not significant).
346 Measurements cannot be grouped if they have different types, or there
347 is a need for independent time values on each measurement. In these
348 instances, multiple measurement sets are necessary.
350 4.1.2. Expiry Time on Location-Related Measurement Data
352 A Device is able to indicate an expiry time in the location
353 measurement using the "expires" attribute. Nominally, this attribute
354 indicates how long information is expected to be valid, but it can
355 also indicate a time limit on the retention and use of the
356 measurement data. A Device can use this attribute to request that
357 the LIS not retain measurement data beyond the indicated time.
359 Note: Movement of the Device might result in the measurement data
360 being invalidated before the expiry time.
362 A Device is advised to set the "expires" attribute to earlier of: the
363 time that measurements are likely to be unusable, and the time that
364 it desires to have measurements discarded by the LIS. A Device that
365 does not desire measurement data to be retained can omit the
366 "expires" attribute. Section 6 describes more specific rules
367 regarding measurement data retention.
369 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 gather the same measurement data from
1624 a trusted and independent source without undue expense, the LIS can
1625 use the trusted data in place of what the untrusted Device has sent.
1626 In cases where that is impractical, the untrusted data can provide
1627 hints that allow corroboration of the data (see Section 7.2.1.1).
1629 Measurement information might contain no inherent indication that it
1630 is falsified. On the contrary, it can be difficult to obtain
1631 information that would provide any degree of assurance that the
1632 measurement device is physically at any particular location.
1633 Measurements that are difficult to verify require other forms of
1634 assurance before they can be used.
1636 7.2.1.1. Effectiveness
1638 Measurement validation MUST be used if measurement data for a
1639 particular Device can be easily acquired by unauthorized location
1640 recipients, as described in Section 7.1.1. This prevents
1641 unauthorized access to location information using measurement data.
1643 Validation of measurement data can be significantly more effective
1644 than independent acquisition of the same. For instance, a Device in
1645 a large Ethernet network could provide a measurement indicating its
1646 point of attachment using LLDP measurements. For a LIS, acquiring
1647 the same measurement data might require a request to all switches in
1648 that network. With the measurement data, validation can target the
1649 identified switch with a specific query.
1651 Validation is effective in identifying falsified measurement data
1652 (Section 7.1.4), including attacks involving replay of measurement
1653 data (Section 7.1.5). Validation also limits the amount of network
1654 topology information (Section 7.1.2) made available to Devices to
1655 that portion of the network topology that they are directly attached.
1657 Measurement validation has no effect if the underlying effect is
1658 being spoofed (Section 7.1.6).
1660 7.2.1.2. Limitations (Unique Observer)
1662 A Device is often in a unique position to make a measurement. It
1663 alone occupies the point in space-time that the location
1664 determination process seeks to determine. The Device becomes a
1665 unique observer for a particular property.
1667 The ability of the Device to become a unique observer makes the
1668 Device invaluable to the location determination process. As a unique
1669 observer, it also makes the claims of a Device difficult to validate
1670 and easily to spoof.
1672 As long as no other entity is capable of making the same
1673 measurements, there is also no other entity that can independently
1674 check that the measurements are correct and applicable to the Device.
1675 A LIS might be unable to validate all or part of the measurement data
1676 it receives from a unique observer. For instance, a signal strength
1677 measurement of the signal from a radio tower cannot be validated
1678 directly.
1680 Some portion of the measurement data might still be independently
1681 verified, even if all information cannot. In the previous example,
1682 the radio tower might be able to provide verification that the Device
1683 is present if it is able to observe a radio signal sent by the
1684 Device.
1686 If measurement data can only be partially validated, the extent to
1687 which it can be validated determines the effectiveness of validation
1688 against these attacks.
1690 The advantage of having the Device as a unique observer is that it
1691 makes it difficult for an attacker to acquire measurements without
1692 the assistance of the Device. Attempts to use measurements to gain
1693 unauthorized access to measurement data (Section 7.1.1) are largely
1694 ineffectual against a unique observer.
1696 7.2.2. Location Validation
1698 Location information that is derived from location-related
1699 measurement data can also be verified against trusted location
1700 information. Rather than validating inputs to the location
1701 determination process, suspect locations are identified at the output
1702 of the process.
1704 Trusted location information is acquired using sources of measurement
1705 data that are trusted. Untrusted location information is acquired
1706 using measurement data provided from untrusted sources, which might
1707 include the Device. These two locations are compared. If the
1708 untrusted location agrees with the trusted location, the untrusted
1709 location information is used.
1711 Algorithms for the comparison of location information are not
1712 included in this document. However, a simple comparison for
1713 agreement might require that the untrusted location be entirely
1714 contained within the uncertainty region of the trusted location.
1716 There is little point in using a less accurate, less trusted
1717 location. Untrusted location information that has worse accuracy
1718 than trusted information can be immediately discarded. There are
1719 multiple factors that affect accuracy, uncertainty and currency being
1720 the most important. How location information is compared for
1721 accuracy is not defined in this document.
1723 7.2.2.1. Effectiveness
1725 Location validation limits the extent to which falsified - or
1726 erroneous - measurement data can cause an incorrect location to be
1727 reported.
1729 Location validation can be more efficient than validation of inputs,
1730 particularly for a unique observer (Section 7.2.1.2).
1732 Validating location ensures that the Device is at or near the
1733 resulting location. Location validation can be used to limit or
1734 prevent all of the attacks identified in this document.
1736 7.2.2.2. Limitations
1737 The trusted location that is used for validation is always less
1738 accurate than the location that is being checked. The amount by
1739 which the untrusted location is more accurate, is the same amount
1740 that an attacker can exploit.
1742 For example, a trusted location might indicate a five kilometer
1743 radius uncertainty region. An untrusted location that describes a
1744 100 meter uncertainty within the larger region might be accepted as
1745 more accurate. An attacker might still falsify measurement data to
1746 select any location within the larger uncertainty region. While the
1747 100 meter uncertainty that is reported seems more accurate, a
1748 falsified location could be anywhere in the five kilometer region.
1750 Where measurement data might have been falsified, the actual
1751 uncertainty is effectively much higher. Local policy might allow
1752 differing degrees of trust to location information derived from
1753 untrusted measurement data. This might be a boolean operation with
1754 only two possible outcomes: untrusted location information might be
1755 used entirely or not at all. Alternatively, untrusted location could
1756 be combined with trusted location information using different
1757 weightings, based on a value set in local policy.
1759 7.2.3. Supporting Observations
1761 Replay attacks using previously acquired measurement data are
1762 particularly hard to detect without independent validation. Rather
1763 than validate the measurement data directly, supplementary data might
1764 be used to validate measurements or the location information derived
1765 from those measurements.
1767 These supporting observations could be used to convey information
1768 that provides additional assurance that the Device was acquired at a
1769 specific time and place. In effect, the Device is requested to
1770 provide proof of its presence at the resulting location.
1772 For instance, a Device that measures attributes of a radio signal
1773 could also be asked to provide a sample of the measured radio signal.
1774 If the LIS is able to observe the same signal, the two observations
1775 could be compared. Providing that the signal cannot be predicted in
1776 advance by the Device, this could be used to support the claim that
1777 the Device is able to receive the signal. Thus, the Device is likely
1778 to be within the range that the signal is transmitted. A LIS could
1779 use this to attribute a higher level of trust in the associated
1780 measurement data or resulting location.
1782 7.2.3.1. Effectiveness
1783 The use of supporting observations is limited by the ability of the
1784 LIS to acquire and validate these observations. The advantage of
1785 selecting observations independent of measurement data is that
1786 observations can be selected based on how readily available the data
1787 is for both LIS and Device. The amount and quality of the data can
1788 be selected based on the degree of assurance that is desired.
1790 Use of supporting observations is similar to both measurement
1791 validation and location validation. All three methods rely on
1792 independent validation of one or more properties. Applicability of
1793 each method is similar.
1795 Use of supporting observations can be used to limit or prevent all of
1796 the attacks identified in this document.
1798 7.2.3.2. Limitations
1800 The effectiveness of the validation method depends on the quality of
1801 the supporting observation: how hard it is to obtain at a different
1802 time or place, how difficult it is to guess, and what other costs
1803 might be involved in acquiring this data.
1805 In the example of an observed radio signal, requesting a sample of
1806 the signal only provides an assurance that the Device is able to
1807 receive the signal transmitted by the measured radio transmitter.
1808 This only provides some assurance that the Device is within range of
1809 the transmitter.
1811 As with location validation, a Device might still be able to provide
1812 falsified measurements that could alter the value of the location
1813 information as long as the result is within this region.
1815 Requesting additional supporting observations can reduce the size of
1816 the region over which location information can be altered by an
1817 attacker, or increase trust in the result, but each additional
1818 measurement imposes an acquisition cost. Supporting observations
1819 contribute little or nothing toward the primary goal of determining
1820 the location of the Device.
1822 7.2.4. Attribution
1824 Lying by proxy (Section 7.1.4) relies on the location recipient being
1825 able to attribute location information to a LIS. The effectiveness
1826 of this attack is negated if location information is explicitly
1827 attributed to a particular source.
1829 This requires an extension to the location object that explicitly
1830 identifies the source (or sources) of each item of location
1831 information.
1833 Rather than relying on a process that seeks to ensure that location
1834 information is accurate, this approach instead provides a location
1835 recipient with the information necessary to reach their own
1836 conclusion about the trustworthiness of the location information.
1838 Including an authenticated identity for all sources of measurement
1839 data presents a number of technical and operational challenges. It
1840 is possible that the LIS has a transient relationship with a Device.
1841 A Device is not expected to share authentication information with a
1842 LIS. There is no assurance that Device identification is usable by a
1843 potential location recipient. Privacy concerns might also prevent
1844 the sharing identification information, even if it were available and
1845 usable.
1847 Identifying the type of measurement source allows a location
1848 recipient to make a decision about the trustworthiness of location
1849 information without depending on having authenticated identity
1850 information for each source. An element for this purpose is defined
1851 in Section 4.4.
1853 When including location information that is based on measurement data
1854 from sources that might be untrusted, a LIS SHOULD include
1855 alternative location information that is derived from trusted sources
1856 of measurement data. Each item of location information can then be
1857 labelled with the source of that data.
1859 A location recipient that is able to identify a specific source of
1860 measurement data (whether it be LIS or Device) can use this
1861 information to attribute location information to either or both
1862 entity. The location recipient is then better able to make decisions
1863 about trustworthiness based on the source of the data.
1865 A location recipient that does not understand the "source" element is
1866 unable to make this distinction. When constructing a PIDF-LO
1867 document, trusted location information MUST be placed in the PIDF-LO
1868 so that it is given higher priority to any untrusted location
1869 information according to Rule #8 of [RFC5491].
1871 Attribution of information does nothing to address attacks that alter
1872 the observed parameters that are used in location determination
1873 (Section 7.1.6).
1875 7.2.5. Stateful Correlation of Location Requests
1876 Stateful examination of requests can be used to prevent a Device from
1877 attempting to map network topology using requests for location
1878 information (Section 7.1.2).
1880 Simply limiting the rate of requests from a single Device reduces the
1881 amount of data that a Device can acquire about network topology. A
1882 LIS could also make observations about the movements of a Device. A
1883 Device that is attempting to gather topology information is likely to
1884 be assigned a location that changes significantly between subsequent
1885 requests, possibly violating physical laws (or lower limits that
1886 might still be unlikely) with respect to speed and acceleration.
1888 7.3. An Unauthorized or Compromised LIS
1890 A compromised LIS, or a compromise in LIS discovery [RFC5986] could
1891 lead to an unathorized entity obtaining measurement data. This
1892 information could then be used or redistributed. A Device MUST
1893 ensure that it authenticate a LIS, as described in Section 9 of
1894 [RFC5985].
1896 An entity that is able to acquire measurement data can, in addition
1897 to using those measurements to learn the location of a Device, also
1898 use that information for other purposes. This information can be
1899 used to provide insight into network topology (Section 7.1.2).
1901 Measurement data might also be exploited in other ways. For example,
1902 revealing the type of 802.11 transceiver that a Device uses could
1903 allow an attacker to use specific vulnerabilities to attack a Device.
1904 Similarly, revealing information about network elements could enable
1905 targeted attacks on that infrastructure.
1907 8. Measurement Schemas
1909 The schema are broken up into their respective functions. There is a
1910 base container schema into which all measurements are placed, plus
1911 definitions for a measurement request (Section 8.1). A PIDF-LO
1912 extension is defined in a separate schema (Section 8.2). There is a
1913 basic types schema, that contains various base type definitions for
1914 things such as the "rmsError" and "samples" attributes IPv4, IPv6 and
1915 MAC addresses (Section 8.3). Then each of the specific measurement
1916 types is defined in its own schema.
1918 8.1. Measurement Container Schema
1920
1921
1929
1930
1932
1933
1934
1936 This schema defines a framework for location measurements.
1937
1938
1940
1942
1943
1944
1945
1946
1947
1949
1950
1951
1952
1953
1954
1955
1956
1957
1959
1961
1962
1963
1964
1965
1967
1969
1970
1971
1973
1975
1976
1977
1978
1979
1980
1982
1983
1984
1985
1986
1987
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2004 Measurement Container Schema
2006 8.2. Measurement Source Schema
2008
2009
2016
2017
2019
2020
2021
2023 This schema defines an extension to PIDF-LO that indicates the
2024 type of source that produced the measurement data used in
2025 generating the associated location information.
2026
2027
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2043 Measurement Source PIDF-LO Extension Schema
2045 8.3. Base Type Schema
2047 Note that the pattern rules in the following schema wrap due to
2048 length constraints. None of the patterns contain whitespace.
2050
2051
2058
2059
2061
2062
2063
2065 This schema defines a set of base type elements.
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2108
2109
2110
2112
2113
2114
2115
2117 An IP version 6 address, based on RFC 4291.
2118
2119
2120
2121
2122
2123
2124
2125
2126
2128
2130
2132
2134
2136
2138
2139
2140
2141
2149
2150
2151
2152
2154
2155
2156
2157
2161
2162
2164
2165
2166
2167
2169
2170
2172
2174 Base Type Schema
2176 8.4. LLDP Measurement Schema
2178
2179
2187
2188
2190
2191
2192
2194 This schema defines a set of LLDP location measurements.
2195
2196
2198
2200
2201
2202
2203
2204
2205
2206
2207
2209
2210
2211
2212
2214
2216
2217
2218
2219
2221
2222
2223
2225
2226
2227
2228
2229
2230
2232
2234 LLDP measurement schema
2236 8.5. DHCP Measurement Schema
2238
2239
2247
2248
2250
2251
2252
2254 This schema defines a set of DHCP location measurements.
2255
2256
2258
2260
2261
2262
2263
2264
2265
2266
2267
2269
2271
2273
2275
2276
2277
2278
2279
2281
2282
2283
2284
2286
2287
2288
2290
2292 DHCP measurement schema
2294 8.6. WiFi Measurement Schema
2296
2297
2306
2307
2309 802.11 location measurements
2311
2312
2313
2315 This schema defines a basic set of 802.11 location measurements.
2316
2317
2319
2320
2322
2324
2325
2326
2327
2328
2330
2332
2333
2334
2335
2336
2338
2339
2340
2341
2342
2343
2345
2347
2349
2351
2353
2355
2357
2360
2362
2364
2365
2367
2368
2369
2370
2372
2373
2374
2375
2377
2378
2379
2381
2383
2384
2385
2386
2387
2389
2390
2391
2392
2393
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2414
2415
2416
2417
2418
2420
2421
2423
2425
2427
2428
2429
2430
2432
2433
2434
2435
2436
2437
2438
2440
2441
2442
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2457
2458
2460
2462 WiFi measurement schema
2464 8.7. Cellular Measurement Schema
2466
2467
2474
2475
2477
2478
2479
2481 This schema defines a set of cellular location measurements.
2482
2483
2485
2487
2488
2489
2490
2491
2492
2493
2494
2495
2497
2498
2499
2500
2501
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2522
2523
2524
2525
2526
2527
2529
2530
2532
2533
2534
2535
2537
2538
2539
2540
2541
2543
2544
2545
2546
2547
2549
2550
2551
2552
2554
2556
2558
2559
2560
2561
2562
2563
2564
2565
2566
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2583
2585 Cellular measurement schema
2587 8.8. GNSS Measurement Schema
2589
2590
2598
2599
2601
2602
2603
2605 This schema defines a set of GNSS location measurements
2606
2607
2609
2611
2612
2613
2614
2615
2616
2617
2619
2620
2621
2622
2623
2625
2627
2629
2630
2631
2632
2633
2634
2635
2637
2638
2639
2640
2641
2642
2644
2645
2647
2649
2651
2652
2654
2655
2656
2658
2659
2660
2661
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2676 GNSS measurement Schema
2678 8.9. DSL Measurement Schema
2680
2681
2689
2690
2692 DSL measurement definitions
2693
2694
2695
2697 This schema defines a basic set of DSL location measurements.
2698
2700
2702
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2760
2762 DSL measurement schema
2764 9. IANA Considerations
2766 This section creates a registry for GNSS types (Section 5.5) and
2767 registers the namespaces and schema defined in Section 8.
2769 9.1. IANA Registry for GNSS Types
2771 This document establishes a new IANA registry for "Global Navigation
2772 Satellite System (GNSS) types". The registry includes tokens for the
2773 GNSS type and for each of the signals within that type. Referring to
2774 [RFC5226], this registry operates under "Specification Required"
2775 rules. The IESG will appoint an Expert Reviewer who will advise IANA
2776 promptly on each request for a new or updated GNSS type.
2778 Each entry in the registry requires the following information:
2780 GNSS name: the name of the GNSS
2782 Brief description: a brief description of the GNSS
2784 GNSS token: a token that can be used to identify the GNSS
2786 Signals: a set of tokens that represent each of the signals that the
2787 system provides
2789 Documentation reference: a reference to one or more stable, public
2790 specifications that outline usage of the GNSS, including (but not
2791 limited to) signal specifications and time systems
2793 The registry initially includes two registrations:
2795 GNSS name: Global Positioning System (GPS)
2796 Brief description: a system of satellites that use spread-spectrum
2797 transmission, operated by the US military for commercial and
2798 military applications
2800 GNSS token: gps
2802 Signals: L1, L2, L1C, L2C, L5
2804 Documentation reference: Navstar GPS Space Segment/Navigation User
2805 Interface [GPS.ICD]
2807 GNSS name: Galileo
2809 Brief description: a system of satellites that operate in the same
2810 spectrum as GPS, operated by the European Union for commercial
2811 applications
2813 GNSS Token: galileo
2815 Signals: L1, E5A, E5B, E5A+B, E6
2817 Documentation Reference: Galileo Open Service Signal In Space
2818 Interface Control Document (SIS ICD) [Galileo.ICD]
2820 9.2. URN Sub-Namespace Registration for
2821 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
2823 This section registers a new XML namespace,
2824 "urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc", as per the guidelines
2825 in [RFC3688].
2827 URI: urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
2829 Registrant Contact: IETF, GEOPRIV working group,
2830 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2832 XML:
2834 BEGIN
2835
2836
2838
2839
2840 Measurement Source for PIDF-LO
2841
2842
2843 Namespace for Location Measurement Source
2844 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
2845 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2846 with the RFC number for this specification.]]
2847 See RFCXXXX.
2848
2849
2850 END
2852 9.3. URN Sub-Namespace Registration for
2853 urn:ietf:params:xml:ns:geopriv:lm
2855 This section registers a new XML namespace,
2856 "urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in
2857 [RFC3688].
2859 URI: urn:ietf:params:xml:ns:geopriv:lm
2861 Registrant Contact: IETF, GEOPRIV working group,
2862 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2864 XML:
2866 BEGIN
2867
2868
2870
2871
2872 Measurement Container
2873
2874
2875 Namespace for Location Measurement Container
2876 urn:ietf:params:xml:ns:geopriv:lm
2877 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2878 with the RFC number for this specification.]]
2879 See RFCXXXX.
2880
2881
2882 END
2884 9.4. URN Sub-Namespace Registration for
2885 urn:ietf:params:xml:ns:geopriv:lm:basetypes
2887 This section registers a new XML namespace,
2888 "urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines
2889 in [RFC3688].
2891 URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes
2893 Registrant Contact: IETF, GEOPRIV working group,
2894 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2896 XML:
2898 BEGIN
2899
2900
2902
2903
2904 Base Device Types
2905
2906
2907 Namespace for Base Types
2908 urn:ietf:params:xml:ns:geopriv:lm:basetypes
2909 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2910 with the RFC number for this specification.]]
2911 See RFCXXXX.
2912
2913
2914 END
2916 9.5. URN Sub-Namespace Registration for
2917 urn:ietf:params:xml:ns:geopriv:lm:lldp
2919 This section registers a new XML namespace,
2920 "urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in
2921 [RFC3688].
2923 URI: urn:ietf:params:xml:ns:geopriv:lm:lldp
2925 Registrant Contact: IETF, GEOPRIV working group,
2926 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2928 XML:
2930 BEGIN
2931
2932
2934
2935
2936 LLDP Measurement Set
2937
2938
2939 Namespace for LLDP Measurement Set
2940 urn:ietf:params:xml:ns:geopriv:lm:lldp
2941 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2942 with the RFC number for this specification.]]
2943 See RFCXXXX.
2944
2945
2946 END
2948 9.6. URN Sub-Namespace Registration for
2949 urn:ietf:params:xml:ns:geopriv:lm:dhcp
2951 This section registers a new XML namespace,
2952 "urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in
2953 [RFC3688].
2955 URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp
2957 Registrant Contact: IETF, GEOPRIV working group,
2958 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2960 XML:
2962 BEGIN
2963
2964
2966
2967
2968 DHCP Measurement Set
2969
2970
2971 Namespace for DHCP Measurement Set
2972 urn:ietf:params:xml:ns:geopriv:lm:dhcp
2973 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2974 with the RFC number for this specification.]]
2975 See RFCXXXX.
2976
2978
2979 END
2981 9.7. URN Sub-Namespace Registration for
2982 urn:ietf:params:xml:ns:geopriv:lm:wifi
2984 This section registers a new XML namespace,
2985 "urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in
2986 [RFC3688].
2988 URI: urn:ietf:params:xml:ns:geopriv:lm:wifi
2990 Registrant Contact: IETF, GEOPRIV working group,
2991 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
2993 XML:
2995 BEGIN
2996
2997
2999
3000
3001 WiFi Measurement Set
3002
3003
3004 Namespace for WiFi Measurement Set
3005 urn:ietf:params:xml:ns:geopriv:lm:wifi
3006 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
3007 with the RFC number for this specification.]]
3008 See RFCXXXX.
3009
3010
3011 END
3013 9.8. URN Sub-Namespace Registration for
3014 urn:ietf:params:xml:ns:geopriv:lm:cell
3016 This section registers a new XML namespace,
3017 "urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in
3018 [RFC3688].
3020 URI: urn:ietf:params:xml:ns:geopriv:lm:cell
3022 Registrant Contact: IETF, GEOPRIV working group,
3023 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
3025 XML:
3027 BEGIN
3028
3029
3031
3032
3033 Cellular Measurement Set
3034
3035
3036 Namespace for Cellular Measurement Set
3037 urn:ietf:params:xml:ns:geopriv:lm:cell
3038 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
3039 with the RFC number for this specification.]]
3040 See RFCXXXX.
3041
3042
3043 END
3045 9.9. URN Sub-Namespace Registration for
3046 urn:ietf:params:xml:ns:geopriv:lm:gnss
3048 This section registers a new XML namespace,
3049 "urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in
3050 [RFC3688].
3052 URI: urn:ietf:params:xml:ns:geopriv:lm:gnss
3054 Registrant Contact: IETF, GEOPRIV working group,
3055 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
3057 XML:
3059 BEGIN
3060
3061
3063
3064
3065 GNSS Measurement Set
3066
3067
3068 Namespace for GNSS Measurement Set
3069 urn:ietf:params:xml:ns:geopriv:lm:gnss
3070 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
3071 with the RFC number for this specification.]]
3072 See RFCXXXX.
3073
3074
3075 END
3077 9.10. URN Sub-Namespace Registration for
3078 urn:ietf:params:xml:ns:geopriv:lm:dsl
3080 This section registers a new XML namespace,
3081 "urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in
3082 [RFC3688].
3084 URI: urn:ietf:params:xml:ns:geopriv:lm:dsl
3086 Registrant Contact: IETF, GEOPRIV working group,
3087 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
3089 XML:
3091 BEGIN
3092
3093
3095
3096
3097 DSL Measurement Set
3098
3099
3100 Namespace for DSL Measurement Set
3101 urn:ietf:params:xml:ns:geopriv:lm:dsl
3102 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
3103 with the RFC number for this specification.]]
3104 See RFCXXXX.
3105
3106
3107 END
3109 9.11. XML Schema Registration for Measurement Source Schema
3111 This section registers an XML schema as per the guidelines in
3112 [RFC3688].
3114 URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc
3116 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3117 Martin Thomson (martin.thomson@commscope.com).
3119 Schema: The XML for this schema can be found in Section 8.2 of this
3120 document.
3122 9.12. XML Schema Registration for Measurement Container Schema
3124 This section registers an XML schema as per the guidelines in
3125 [RFC3688].
3127 URI: urn:ietf:params:xml:schema:lm
3129 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3130 Martin Thomson (martin.thomson@commscope.com).
3132 Schema: The XML for this schema can be found in Section 8.1 of this
3133 document.
3135 9.13. XML Schema Registration for Base Types Schema
3137 This section registers an XML schema as per the guidelines in
3138 [RFC3688].
3140 URI: urn:ietf:params:xml:schema:lm:basetypes
3142 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3143 Martin Thomson (martin.thomson@commscope.com).
3145 Schema: The XML for this schema can be found in Section 8.3 of this
3146 document.
3148 9.14. XML Schema Registration for LLDP Schema
3150 This section registers an XML schema as per the guidelines in
3151 [RFC3688].
3153 URI: urn:ietf:params:xml:schema:lm:lldp
3155 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3156 Martin Thomson (martin.thomson@commscope.com).
3158 Schema: The XML for this schema can be found in Section 8.4 of this
3159 document.
3161 9.15. XML Schema Registration for DHCP Schema
3163 This section registers an XML schema as per the guidelines in
3164 [RFC3688].
3166 URI: urn:ietf:params:xml:schema:lm:dhcp
3167 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3168 Martin Thomson (martin.thomson@commscope.com).
3170 Schema: The XML for this schema can be found in Section 8.5 of this
3171 document.
3173 9.16. XML Schema Registration for WiFi Schema
3175 This section registers an XML schema as per the guidelines in
3176 [RFC3688].
3178 URI: urn:ietf:params:xml:schema:lm:wifi
3180 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3181 Martin Thomson (martin.thomson@commscope.com).
3183 Schema: The XML for this schema can be found in Section 8.6 of this
3184 document.
3186 9.17. XML Schema Registration for Cellular Schema
3188 This section registers an XML schema as per the guidelines in
3189 [RFC3688].
3191 URI: urn:ietf:params:xml:schema:lm:cellular
3193 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3194 Martin Thomson (martin.thomson@commscope.com).
3196 Schema: The XML for this schema can be found in Section 8.7 of this
3197 document.
3199 9.18. XML Schema Registration for GNSS Schema
3201 This section registers an XML schema as per the guidelines in
3202 [RFC3688].
3204 URI: urn:ietf:params:xml:schema:lm:gnss
3206 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3207 Martin Thomson (martin.thomson@commscope.com).
3209 Schema: The XML for this schema can be found in Section 8.8 of this
3210 document.
3212 9.19. XML Schema Registration for DSL Schema
3213 This section registers an XML schema as per the guidelines in
3214 [RFC3688].
3216 URI: urn:ietf:params:xml:schema:lm:dsl
3218 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
3219 Martin Thomson (martin.thomson@commscope.com).
3221 Schema: The XML for this schema can be found in Section 8.9 of this
3222 document.
3224 10. Acknowledgements
3226 Thanks go to Simon Cox for his comments relating to terminology that
3227 have helped ensure that this document is aligned with ongoing work in
3228 the Open Geospatial Consortium (OGC). Thanks to Neil Harper for his
3229 review and comments on the GNSS sections of this document. Thanks to
3230 Noor-E-Gagan Singh, Gabor Bajko, Russell Priebe, and Khalid Al-Mufti
3231 for their significant input to and suggestions for improving the
3232 802.11 measurements. Thanks to Cullen Jennings for feedback and
3233 suggestions. Bernard Aboba provided review and feedback on a range
3234 of measurement data definitions. Mary Barnes and Geoff Thompson
3235 provided a review and corrections. David Waitzman and John Bressler
3236 both noted shortcomings with 802.11 measurements. Keith Drage,
3237 Darren Pawson provided expert LTE knowledge.
3239 11. References
3241 11.1. Normative References
3243 [ASCII] , "US-ASCII. Coded Character Set - 7-Bit American Standard
3244 Code for Information Interchange. Standard ANSI X3.4-1986,
3245 ANSI, 1986.", .
3247 [GPS.ICD] , "Navstar GPS Space Segment/Navigation User Interface",
3248 ICD GPS-200, Apr 2000.
3250 [Galileo.ICD]
3251 GJU, "Galileo Open Service Signal In Space Interface
3252 Control Document (SIS ICD)", May 2006.
3254 [IANA.enterprise]
3255 IANA, "Private Enterprise Numbers", 2011,
3256 .
3258 [IEEE.80211]
3259 IEEE, "Wireless LAN Medium Access Control (MAC) and
3260 Physical Layer (PHY) specifications", IEEE Std
3261 802.11-2012, March 2012.
3263 [IEEE.8021AB]
3264 IEEE, "IEEE Standard for Local and Metropolitan area
3265 networks, Station and Media Access Control Connectivity
3266 Discovery", IEEE Std 802.1AB-2009, September 2009.
3268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3269 Requirement Levels", BCP 14, RFC 2119, March 1997.
3271 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3272 3046, January 2001.
3274 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
3275 and M. Carney, "Dynamic Host Configuration Protocol for
3276 IPv6 (DHCPv6)", RFC 3315, July 2003.
3278 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
3279 10646", STD 63, RFC 3629, November 2003.
3281 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
3282 Resource Identifier (URI): Generic Syntax", STD 66, RFC
3283 3986, January 2005.
3285 [RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID
3286 Suboption for the Dynamic Host Configuration Protocol
3287 (DHCP) Relay Agent Option", RFC 3993, March 2005.
3289 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
3290 Format", RFC 4119, December 2005.
3292 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
3293 Architecture", RFC 4291, February 2006.
3295 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6
3296 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, June
3297 2006.
3299 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
3300 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August
3301 2006.
3303 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
3304 Presence Information Data Format Location Object (PIDF-LO)
3305 Usage Clarification, Considerations, and Recommendations",
3306 RFC 5491, March 2009.
3308 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
3309 Address Text Representation", RFC 5952, August 2010.
3311 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC
3312 5985, September 2010.
3314 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
3315 Location Information Server (LIS)", RFC 5986, September
3316 2010.
3318 [TIA-2000.5]
3319 TIA/EIA, "Upper Layer (Layer 3) Signaling Standard for
3320 cdma2000(R) Spread Spectrum Systems", TIA-2000.5-D, March
3321 2004.
3323 [TS.3GPP.23.003]
3324 3GPP, "Numbering, addressing and identification", 3GPP TS
3325 23.003 9.4.0, September 2010.
3327 11.2. Informative References
3329 [ANSI-TIA-1057]
3330 ANSI/TIA, "Link Layer Discovery Protocol for Media
3331 Endpoint Devices", TIA 1057, April 2006.
3333 [DSL.TR025]
3334 Wang, R., "Core Network Architecture Recommendations for
3335 Access to Legacy Data Networks over ADSL", September 1999.
3337 [DSL.TR101]
3338 Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL
3339 Aggregation", April 2006.
3341 [GPS.SPOOF]
3342 Scott, L., "Anti-Spoofing and Authenticated Signal
3343 Architectures for Civil Navigation Signals", ION-GNSS
3344 Portland, Oregon, 2003.
3346 [HARPER] Harper, N., Dawson, M., and D. Evans, "Server-side
3347 spoofing and detection for Assisted-GPS", Proceedings of
3348 International Global Navigation Satellite Systems Society
3349 (IGNSS) Symposium 2009 16, December 2009,
3350 .
3352 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
3353 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
3354 RFC 2661, August 1999.
3356 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
3357 "Remote Authentication Dial In User Service (RADIUS)", RFC
3358 2865, June 2000.
3360 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
3361 January 2004.
3363 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
3364 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
3366 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
3367 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
3368 May 2008.
3370 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R.
3371 Barnes, "Use of Device Identity in HTTP-Enabled Location
3372 Delivery (HELD)", RFC 6155, March 2011.
3374 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
3375 Tschofenig, H., and H. Schulzrinne, "An Architecture for
3376 Location and Location Privacy in Internet Applications",
3377 BCP 160, RFC 6280, July 2011.
3379 Authors' Addresses
3381 Martin Thomson
3382 Microsoft
3383 3210 Porter Drive
3384 Palo Alto, CA 94304
3385 US
3387 Phone: +1 650-353-1925
3388 Email: martin.thomson@skype.net
3390 James Winterbottom
3391 Unaffiliated
3392 AU
3394 Email: a.james.winterbottom@gmail.com