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

From: "geopriv issue tracker" <[email-masked]>
Date: Thu, 17 Sep 2009 04:09:52 -0000

#20: Section 1 re-organization
---------------------------------------+------------------------------------
 Reporter:  [email-masked]  |       Owner:  Bernard Aboba             
     Type:  enhancement                |      Status:  new                       
 Priority:  minor                      |   Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                 |     Version:  2.0                       
 Severity:  Active WG Document         |    Keywords:  3825bis                   
---------------------------------------+------------------------------------
 With the introduction of uncertainty as well as resolution, it probably
 makes sense to remove discussion of uncertainty and resolution from
 Section 1 into a separate section.

 The overall flow would be enhanced by integrating the current section 1.2
 (Motivation) into the revised Section 1, so as to provide the reader with
 context up front.

 Material currently in Section 1.3 (Rationale) relating to Latitude,
 Longitude, Altitude and Altitude Type probably belongs in Section 2.

-- 
Ticket URL: <http://wiki.tools.ietf.org/wg/geopriv/trac/ticket/20>
geopriv <http://tools.ietf.org/geopriv/>

---

From: "geopriv issue tracker" <[email-masked]>
Date: Thu, 17 Sep 2009 04:11:29 -0000

Severity:  Active WG Document         |   Resolution:                            
 Keywords:  3825bis                    |  

Comment(by [email-masked]):

 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/>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 16 Sep 2009 23:33:19 -0500

This re-organization makes sense.  I have some minor concerns with some of the original content, but I'll raise that as separate issues.  I don't want to confuse things too much.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of geopriv issue tracker
> Sent: Thursday, 17 September 2009 2:11 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Geopriv] [geopriv] #20: Section 1 re-organization
> 
> Ticket URL:
> <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/20#comment:1>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> 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]

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 17 Sep 2009 01:42:22 -0500

one nit below

>#20: Section 1 re-organization

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").

---

From: "geopriv issue tracker" <[email-masked]>
Date: Thu, 17 Sep 2009 07:12:22 -0000

#20: Section 1 re-organization
---------------------------------------+------------------------------------
 Reporter:  [email-masked]  |        Owner:  Bernard Aboba             
     Type:  enhancement                |       Status:  closed                    
 Priority:  minor                      |    Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                 |      Version:  2.0                       
 Severity:  Active WG Document         |   Resolution:  fixed                     
 Keywords:  3825bis                    |  
---------------------------------------+------------------------------------
Changes (by [email-masked]):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Incorporated edits from James.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/20#comment:2>
geopriv <http://tools.ietf.org/geopriv/>