---------------------------------------+------------------------------------
Reporter: bernard_aboba@hotmail.com | Owner: Bernard Aboba
Type: enhancement | Status: new
Priority: minor | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version: 2.0
Severity: Active WG Document | Resolution:
Keywords: 3825bis |
---------------------------------------+------------------------------------
Comment(by bernard_aboba@hotmail.com):
Here is a current (rough) draft of a revised Section 1:
1. Introduction
The physical location of a network device has a range of
applications. In particular, emergency telephony applications rely
on knowing the location of a caller in order to determine the correct
emergency center.
The location of a device can be represented either in terms of
geospatial (or geodetic) coordinates, or as a civic address.
Different applications may be more suited to one form of location
information; therefore, both the geodetic and civic forms may be used
simultaneously.
"Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for
Civic Addresses Configuration Information" [RFC4776] specifies DHCP
options for civic addresses. This document specifies Dynamic Host
Configuration Protocol (DHCPv4) [RFC2131] and DHCPv6 [RFC3315])
options for the coordinate-based geographic location of the client,
to be provided by the server.
These options enable a wired Ethernet host to obtain its location.
The location information is derived from a wiremap by the DHCP
server, using the Circuit-ID Relay Agent Information Option (RAIO)
defined (as Sub-Option 1) in RFC 3046 [RFC3046]. The DHCP server is
assumed to have access to a service that can correlate a Circuit-ID
with the geographic location where the identified circuit terminates
(such as the location of the wall jack).
The options defined in this document have limited applicability for
mobile hosts. Typically DHCP clients refresh their configuration in
response to changes in interface state or pending lease expirations.
As a result, when a mobile host changes location without subsequently
completing another DHCP exchange, location configuration information
initially obtained via DHCP could become outdated.
An important feature of this specification is that after the relevant
DHC exchanges have taken place, the location information is stored on
the end device rather than somewhere else, where retrieving it might
be difficult in practice.
1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. Resolution and Uncertainty
The DHCPv4 option format defined in this document utilizes both
resolution and uncertainty parameters. The DHCPv6 option format only
utilizes an uncertainty parameter.
Version 0 of the DHCPv4 option format defined in this document
includes a resolution parameter for each of the dimensions of
location. Since this resolution parameter need not apply to all
dimensions equally, a resolution value is included for each of the 3
location elements. Resolution does not define Geographic Privacy
policy.
Appendix A of this document provides some arithmetic examples of the
implication of different resolution values on the La/Lo/Alt.
The DHCPv6 option format as well as version 1 of the DHCPv4 option
format utilizes an uncertainty parameter. In the context of location
technology, uncertainty is a quantification of errors. Any method
for determining location is subject to some sources of error;
uncertainty describes the amount of error that is present.
Uncertainty might be the coverage area of a wireless transmitter, the
extent of a building or a single room.
Uncertainty is usually represented as an area within which the target
is located. In this document, each of the three axes can be assigned
an uncertainty value. In effect, this describes a rectangular prism.
When representing locations from sources that can quantify
uncertainty, the goal is to find the smallest possible rectangular
prism that this format can describe. This is achieved by taking the
minimum and maximum values on each axis and ensuring that the final
encoding covers these points. This increases the region of
uncertainty, but ensures that the region that is described
encompasses the target location.
--
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/20#comment:1>
geopriv <http://tools.ietf.org/geopriv/>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
