> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of geopriv issue tracker
> Sent: Thursday, 17 September 2009 2:11 PM
> To: bernard_aboba@hotmail.com
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] [geopriv] #20: Section 1 re-organization
>
> #20: Section 1 re-organization
> ---------------------------------------+-------------------------------
> -----
> 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
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
