Subject: [Geopriv] [geopriv] #21: Location determination method

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

#21: Location determination method
---------------------------------------+------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked] 
     Type:  defect                     |      Status:  new                       
 Priority:  trivial                    |   Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                 |     Version:                            
 Severity:  Active WG Document         |    Keywords:  determination             
---------------------------------------+------------------------------------
 The following statement does not necessarily hold true and needs to be
 challenged:

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

 Indeed it goes beyond what is necessary for interoperability.  Would it
 cause interoperability problems if I just looked up the MAC address of a
 client in a table to determine where they are?  Because that's not a lot
 different from what happens in cable networks from what I remember?

 Since this is hidden, this is only really useful as a way of pointing out
 one way that this could be done - a feasibility proof as it were.

 It shouldn't take much to fix this:

 >The location information could be 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].  In this case, the DHCP server
 >could correlate the Circuit-ID with the geographic location where the
 >identified circuit terminates (such as the location of the wall jack).

 Furthermore, the lead-in to this paragraph seems to be incorrect also:

 >These options enable a wired Ethernet host to obtain its location.

 Since this is being used in other network types, I think that it would be
 sensible to say this:

 >These options enable a DHCP client to obtain its location.  For example,
 a
 >wired Ethernet host might use this option to obtain its location.  In
 this
 >case, the location information could be derived from a wiremap by the
 DHCP
 >server ...

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

---

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

#21: Location determination method
---------------------------------------+------------------------------------
 Reporter:  [email-masked]  |        Owner:  [email-masked] 
     Type:  defect                     |       Status:  closed                    
 Priority:  trivial                    |    Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                 |      Version:  2.0                       
 Severity:  Active WG Document         |   Resolution:  fixed                     
 Keywords:  determination              |  
---------------------------------------+------------------------------------
Changes (by [email-masked]):

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

Comment:

 Changes incorporated into strawman -02:
 http://www.drizzle.com/~aboba/GEOPRIV/draft-ietf-geopriv-rfc3825bis-02.txt

-- 
Ticket URL: <http://wiki.tools.ietf.org/wg/geopriv/trac/ticket/21#comment:1>
geopriv <http://tools.ietf.org/geopriv/>

---

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

Comment(by [email-masked]):

 Actually on review of the proposed text for Issue #20, the phrase "these
 options" could be thought to apply to the RFC 4776 civic data.  It might
 be wise to clarify this a little:

 >The geodetic coordinate options defined in this document and the civic
 address options in [RFC4776] enable a DHCP client to obtain its location.
 ...

 ...sorry Bernard :|

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

---

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

Comment(by [email-masked]):

 Fixed.

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