Re: [Geopriv] [geopriv] #20: Section 1 re-organization

["James M. Polk" <[e-mail]>]

one nit below

At 11:11 PM 9/16/2009, geopriv issue tracker wrote:
>#20: Section 1 re-organization
>---------------------------------------+------------------------------------
>  Reporter:  [e-mail]  |        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 [e-mail]):
>
>  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.

Bernard

I suggest switching the order of the two sentences in the above 
paragraph.  Admittedly, the civic format is more popular, it was the 
second RFC to produce LCI.

Besides, the present order seems to downplay what this document is 
all about (i.e., "here's what this doc is about, look for the civic 
format in 4776").


>     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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/geopriv