Subject: [Geopriv] [geopriv] #38: Section 1

From: "geopriv issue tracker" <[email-masked]>
Date: Tue, 10 Aug 2010 21:10:25 -0000

#38: Section 1
------------------------------------------+---------------------------------
 Reporter:  bernard_aboba@…               |       Owner:  bernard_aboba@…           
     Type:  defect                        |      Status:  new                       
 Priority:  minor                         |   Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                    |     Version:  1.0                       
 Severity:  Waiting for Shepherd Writeup  |    Keywords:                            
------------------------------------------+---------------------------------
 Marc Linsner said:

 "Further, RFC3825 includes:

 "  Wireless hosts can utilize this option to gain knowledge of the
    location of the radio access point used during host configuration,
    but would need some more exotic mechanisms, maybe GPS, or maybe a
    future DHCP option, which includes a list of geo-locations like that
    defined here, containing the locations of the radio access points
    that are close to the client"

 Since draft-ietf-geopriv-rfc3825bis is updating RFC3825, it takes strong
 consensus to add/remove text from RFC3825.  Since this text is missing
 from
 draft-ietf-geopriv-rfc3825bis, one has to assume the wg agreed to taking
 it
 out.

 You might want to go back and figure out why this text was removed and
 suggest that it's put back in, or modified and put back in."

 [BA] It appears that the text in question was removed in -02, as part of
 the merger of Sections 1 and 1.2, covered by Ticket #20.  The proposed
 merger was discussed on the list in September 2009 (see
 http://www.ietf.org/mail-archive/web/geopriv/current/msg07895.html ).

 In addition to the text that was removed, some text from
 draft-thomson-geopriv-3825bis was edited into Section 1:

    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.

 [BA] By replacing the text on wireless usage with a statement of
 applicability relating to mobile uses, the overall impression that
 Section 1 leaves is a focus on wired uses.

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

---

From: Marc Linsner <[email-masked]>
Date: Fri, 13 Aug 2010 09:27:20 -0400

Bernard,

On 8/10/10 5:10 PM, "geopriv issue tracker" <[email-masked]> wrote:

"The options defined in this document have limited applicability for

response to changes in interface state or pending lease expirations. As a
result, when a mobile host changes location without subsequently

initially obtained via DHCP could become outdated."

applicability relating to mobile uses, the overall impression that
 Section
1 leaves is a focus on wired uses.

[ML]  After re-reading the above text, I wonder if it might be better
understood to re-word:

"The options defined in this document have limited applicability for

response to changes in interface state or pending lease expirations. As a
result, when a mobile host changes location it MUST complete another DHCP
exchange to keep location current.  Otherwise, the location configuration
information initially obtained via DHCP could become outdated."

Comments?

-Marc-

---

From: Marc Linsner <[email-masked]>
Date: Fri, 13 Aug 2010 09:42:04 -0400

On the security issue Hannes raised, I'm OK with the current statement in
Section 3 and don't believe anything more is warranted:

"
   Since there is no privacy protection for DHCP messages, an
   eavesdropper who can monitor the link between the DHCP server and
   requesting client can discover this LCI.
"

As I/others have stated, confidentiality of DHCP messages on a modern wired
networks is inherent in the design or at layer 2.  The applicability for
DHCP to hand out device-level location information on mobile networks is
simply not feasible or practical, hence implementers understand the
limitations of this mechanism.

-Marc-

On 8/10/10 5:10 PM, "geopriv issue tracker" <[email-masked]> wrote:

> #38: Section 
> 1
 Reporter:  bernard_aboba@Š               |       Owner:  bernard_aboba@Š
 Priority:  minor                         |   Milestone:
> draft-ietf-geopriv-3825bis
Component:  rfc3825bis                    |
> Version:  1.0                       
 Severity:  Waiting for Shepherd Writeup
> |    Keywords:   

 "  Wireless hosts can
> utilize this option to gain knowledge of the
    location of the radio access
> point used during host configuration,
    but would need some more exotic
> mechanisms, maybe GPS, or maybe a
    future DHCP option, which includes a
> list of geo-locations like that
    defined here, containing the locations of
> the radio access points

 Since
> draft-ietf-geopriv-rfc3825bis is updating RFC3825, it takes strong
 consensus
> to add/remove text from RFC3825.  Since this text is missing
 from

 it

> suggest that it's put back in, or modified and put back in."

 [BA] It appears
> that the text in question was removed in -02, as part of
 the merger of
> Sections 1 and 1.2, covered by Ticket #20.  The proposed
 merger was discussed
> on the list in September 2009 (see

> http://www.ietf.org/mail-archive/web/geopriv/current/msg07895.html ).

 In
> addition to the text that was removed, some text from

> draft-thomson-geopriv-3825bis was edited into Section 1:

    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.

 [BA] By replacing the text on wireless usage with a
> statement of
 applicability relating to mobile uses, the overall impression
> that

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

____________________________________________
> ___
Geopriv mailing
> list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 13 Aug 2010 07:46:59 -0700

My question with the paragraph is what it is trying to
convey about the "limited applicability".  
We had discussed how DHCP might work reasonably well in 
static or nomadic wireless scenarios, so that wireless
itself was not the issue.

The original text seems to suggest that the issue is movement of 
the mobile host without changing the point of attachment (which 
will trigger a DHCP exchange).  

My presumption is that this is an issue in situations where
the location could change a great deal without a change to the point
of attachment.  Unfortunately, it is these situations (e.g. wireless
WAN networks) where continuous triggering of DHCP might be
most objectionable. 

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Friday, August 13, 2010 6:27 AM
To: geopriv issue tracker; [email-masked]
Cc: [email-masked]
Subject: Re: [Geopriv] [geopriv] #38: Section 1

Bernard,

Comments?

-Marc-

---

From: Marc Linsner <[email-masked]>
Date: Fri, 13 Aug 2010 12:02:34 -0400

Bernard,

A host using *any* LCP must initiate another message exchange to get updated
location information when they determine it's necessary.  This is the same
whether the LCP is HELD, DHCP, LLDP-MED (or wait for 30 sec. for next
packet), or .11(?).  Hence, I don't understand your statement (in the
context of this document), "where continuous triggering of DHCP might be
most objectionable".  Are not 'bits-on-the-wire', 'bits-on-the-wire'?

My change to the current paragraph below stems from when I read the current
text, one could infer that obtaining updated location information via the
DHCP LCP mechanism is not possible.  In fact, it is possible using a
DHCPInform message (yes, renew of a lease also).

Further, I believe it's fairly obvious that *only* using the DHCP RAIO
options as a location determination mechanism renders device level location
(more granular than just AP) *almost* impossible in an 802.11 network (since
RAIO doesn't support measurements).  So, when the connection AP is a DHCP
relay agent, I don't believe there are any RAIO options that would allow the
DHCP server to determine, by itself, device level location.  Obviously
someone could develop a connection between the DHCP server and the .11
location determination infrastructure, but I don't think we should go there,
nor even mention such in the document.

Hence, I believe the most limiting factor to using DHCP as the LCI for
wireless networks is the impracticality of the DHCP server performing device
level location (vs. AP level location) determination using the available
RAIO information.  I also believe that we don't need to point this out as
any developer will realize this within 30 seconds of thinking about.

Does this make any sense?

-Marc-

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 13 Aug 2010 10:31:15 -0700

Yes, what you say below makes a lot of sense.   If a mobile host wants an updated
location, it has to obtain it somehow, regardless of the LCP it is using.  In the case
of DHCP this need not necessarily entail obtaining a new address.  Given that, is
the "applicability" text really unique to DHCP?

Also, I'd also like to see some statement made about wireless usage, if only to make 
it clear that the mechanism is not purely for use in wired scenarios. 

> Date: Fri, 13 Aug 2010 12:02:34 -0400
> From: [email-masked]
> To: [email-masked]; [email-masked]
> CC: [email-masked]
> 
> Bernard,
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 17 Aug 2010 08:33:12 +0800

Marc Linsner writes:
> location information when they determine it's necessary.

That's only true for location by value.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 16 Aug 2010 21:35:27 -0400

Depending, of course, on the scope in which you interpret "message  
exchange".  I would think that a dereference transaction would count.   
It comes down to what kind of exchange you want to talk about.  Either  
way it's just bandwidth and server power, just depends which server  
you want to burden.
--Richard

On Aug 16, 2010, at 8:33 PM, Thomson, Martin wrote:

> _______________________________________________
> Geopriv mailing list
> [email-masked]

---

From: Marc Linsner <[email-masked]>
Date: Tue, 17 Aug 2010 07:51:44 -0400

Martin,

> That's only true for location by value.

This statement is certainly true, but this draft is location by value.

???

-Marc-

---

From: Marc Linsner <[email-masked]>
Date: Thu, 19 Aug 2010 09:40:48 -0400

Bernard,

> it clear that the mechanism is not purely for use in wired scenarios.

3825 says,

"
Wireless hosts can utilize this option to gain knowledge of the
   location of the radio access point used during host configuration,
   but would need some more exotic mechanisms, maybe GPS, or maybe a
   future DHCP option, which includes a list of geo-locations like that
   defined here, containing the locations of the radio access points
   that are close to the client.
"

draft 3825bis says,

"

I suggest replacing the above with,

"
The options defined in this document may have limited applicability for
mobile hosts.  The mechanism defined here utilizes DHC relay agent
sub-options (RFC3046) enabling the DHC server to perform host location
determination.  Currently, the relay agent sub-options do not include data
sets required for device level location determination of mobile hosts.  A
mobile host can use this mechanism to discover location of the radio access
point, or the area of coverage for the radio access point.
" 

Comments?

-Marc-

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 20 Aug 2010 06:31:46 +0800

This is not necessarily true:

> The mechanism defined here utilizes DHC relay agent
> determination.  

Though that would be the easiest and most logical approach to determination, the protocol does not require this.  I could implement a DHCP server that doesn't need RAIO in order to provide location information.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Marc Linsner
> Sent: Thursday, 19 August 2010 11:41 PM
> To: Bernard Aboba; [email-masked]
> Cc: [email-masked]
> > Yes, what you say below makes a lot of sense.   If a mobile host
> wants an
> > updated
> > location, it has to obtain it somehow, regardless of the LCP it is
> using.  In
> > the case
> > of DHCP this need not necessarily entail obtaining a new address.
> Given that,
> > is
> > Also, I'd also like to see some statement made about wireless usage,
> if only
> > to make

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 19 Aug 2010 23:26:19 -0700

Within the wireless case there are static, nomadic and mobile cases.  I
think that some of the text you suggest relates to all wireless cases, not
just mobile.  So how about this? 

"The mechanism defined here may also be utilized to provide location to 
wireless hosts.  DHC relay agent sub-options [RFC3046] enable the DHCP
server to perform host location determination.  Currently, the relay agent 
sub-options do not include data sets required for device level location 
determination of wireless hosts.  A wireless  host can use this mechanism 
to discover location of the radio access point, or the area of coverage for 
the radio access point."

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Thursday, August 19, 2010 6:41 AM
To: Bernard Aboba; [email-masked]
Cc: [email-masked]
Subject: Re: [Geopriv] [geopriv] #38: Section 1

Bernard,

On 8/13/10 1:31 PM, "Bernard Aboba" <[email-masked]> wrote:

> location, it has to obtain it somehow, regardless of the LCP it is using.
In
> the case
> of DHCP this need not necessarily entail obtaining a new address.  Given
that,
> Also, I'd also like to see some statement made about wireless usage, if
only

3825 says,

"

draft 3825bis says,

"

"

Comments?

-Marc-

---

From: Marc Linsner <[email-masked]>
Date: Fri, 20 Aug 2010 08:56:44 -0400

In an effort to cover Martin's concern about the DHC server using
alternative location determination methods.  How about:

"The mechanism defined here may also be utilized to provide location to
wireless hosts.  DHC relay agent sub-options (RAIO) [RFC3046] is one method
a DHC server might use to perform host location determination.  Currently,
the relay agent sub-options do not include data sets required for device
level location determination of wireless hosts.  In cases where the DHC
server uses RAIO for location determination, a wireless host can use this
mechanism to discover location of the radio access point, or the area of
coverage for the radio access point."

(this may be too wordy for the Intro section)

Comments?

-Marc-

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 20 Aug 2010 07:58:57 -0700

Works for me.

---

From: "geopriv issue tracker" <[email-masked]>
Date: Sat, 21 Aug 2010 03:44:43 -0000

#38: Section 1
------------------------------------------+---------------------------------
 Reporter:  bernard_aboba@…               |        Owner:  bernard_aboba@…           
     Type:  defect                        |       Status:  closed                    
 Priority:  minor                         |    Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                    |      Version:  1.0                       
 Severity:  Waiting for Shepherd Writeup  |   Resolution:  fixed                     
 Keywords:                                |  
------------------------------------------+---------------------------------
Changes (by bernard_aboba@…):

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

Comment:

 Recommended resolution:

 Delete the following Section 1 text:

 Replace with:

    The mechanism defined here may also be utilized to provide location
    to wireless hosts.  DHCP relay agent sub-options (RAIO) [RFC3046] is
    one method a DHCP server might use to perform host location
    determination.  Currently, the relay agent sub-options do not include
    data sets required for device level location determination of
    wireless hosts.  In cases where the DHC server uses RAIO for location
    determination, a wireless host can use this mechanism to discover
    location of the radio access point, or the area of coverage for the
    radio access point.

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 23 Aug 2010 07:47:37 +0800

I can live with that.

> Behalf Of Bernard Aboba
> Sent: Saturday, 21 August 2010 12:59 AM
> To: Marc Linsner
> Cc: <[email-masked]>; <[email-masked]>
> using.
> Given