Subject: wireless geolocation

From: Randy Bush <[email-masked]>
Date: Tue, 06 Jun 2017 21:36:07 +0600

you may have noticed, when you get to an ietf meeting and get on the
wireless, you will often geolocate to the last city on the eternal tour.
this is because access point bssids are recorded by a number of
geolocation providers and those location data are then used by
application providers.

the noc tries to deal with this, but it is a manual mess involving
trying to convince geoloc providers to do complex things such as answer
their frelling email.  the pain is not congruent with the fix.

the ietf is far from the only event with this problem.  but it is kind
of in our purview to automate it.  the noc is not the place to work on
protocols and databases; the noc is just the customer/user.  a bof or
some existing wg might be.

oh, and warning.  there is a significant chance we will see the issue in
praha as we have been unable to get a response from one major geoloc
provider (not google; they were wonderfully responsive).

randy

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Jun 2017 12:35:30 -0400

Why do we even have a stable IP address range anymore?   It seems like an unnecessary lift.   If we just take what the ISP offers (IPv4 and IPv6) and use that, why is that not good enough?

---

From: Warren Kumari <[email-masked]>
Date: Tue, 6 Jun 2017 12:48:04 -0400

> Why do we even have a stable IP address range anymore?   It seems like an unnecessary lift.   If we just take what the ISP offers (IPv4 and IPv6) and use that, why is that not good enough?

Because we use a *large* amount of address space - we (currently) give
everyone a public IP address, we have multiple SSIDs / networks, etc.
ISPs would be quite unlikely to be willing to give us a big enough
block, we (often) also have multiple providers, etc. We would also
need to renumber all of our infrastructure, redo DNS, etc.

We currently publish geo-location info in
https://tools.ietf.org/html/draft-google-self-published-geofeeds-02
format -- noc.ietf.org/geo/google.csv. This gets updated (assuming I /
we don't forget :-)) before each meeting, and should be imported by
google in advance of the meeting...

But, much of the issue is location being tied to the MAC address of
the APs, not just the source IP. There are lots of geo providers, and
they all need to be updated, etc.

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Jun 2017 12:55:54 -0400

> need to renumber all of our infrastructure, redo DNS, etc.

Please understand when I say this that I am not proposing an unfunded mandate on the backs of volunteers here, but (a) it doesn't seem to me that we need to continue providing everyone with a routable IPv4 address, and (b) if renumbering is that hard, maybe that's worth thinking about, because renumbering is not generally all that hard, and we have developed a lot of technology in the IETF to _make_ it not hard.

E.g., if everything is numbered using IPv6, and the reason it needs numbered is so that it can be managed, wouldn't a ULA prefix for numbering managed devices solve that problem?   Or are we still managing them using stone knives and IPv4?

> https://tools.ietf.org/html/draft-google-self-published-geofeeds-02 <https://tools.ietf.org/html/draft-google-self-published-geofeeds-02>
> format -- noc.ietf.org/geo/google.csv <http://noc.ietf.org/geo/google.csv>. This gets updated (assuming I /

Apparently that's not solving the problem, though.   Google maps always seems to redirect me to the previous country, every IETF.   I think this is more of an operational problem than not having a routable IPv4 address would be—I don't assume when I'm traveling that I will have a routable IPv4 address.

> they all need to be updated, etc.

Can't APs have their user-facing MAC addresses changed/randomized?   Again, I realize that that potentially another unfunded mandate, but I'm just asking whether this is something that can be done, not saying you should do it.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 6 Jun 2017 21:36:10 +0200

> provider (not google; they were wonderfully responsive).

Just came back from TNC2017 - a significantly less sophisticated network
setup - that regularly runs into the same issue for the same reasons.

	Cheers Leif

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jun 2017 08:15:37 +1200

> setup - that regularly runs into the same issue for the same reasons.

Does it matter?

Geolocation via topologically defined addresses is silly. Why do we
care about fixing it?

    Brian

---

From: Leif Johansson <[email-masked]>
Date: Tue, 6 Jun 2017 22:17:48 +0200

>> setup - that regularly runs into the same issue for the same reasons.

It is a source of irritation, certainly not more than that...

> Geolocation via topologically defined addresses is silly. Why do we

Because it is a widely deployed technology that gets used a lot?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Jun 2017 16:50:27 -0400

Because it makes it very difficult to use various services if they think we
are 7000 miles away from where we are. Latency can be bad, and using maps
can be impossible. I don't love the fact that the internet works this way,
but since it does, if we don't account for that, ux is significantly
degraded.

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Jun 2017 02:51:10 +0600

> Why do we even have a stable IP address range anymore?

red herring.  reread my message.  they are geolocating by AP BSSID

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Jun 2017 03:42:14 +0600

> Geolocation via topologically defined addresses is silly. Why do we

i was not aware that bssid/macs were topologically assigned.  i thought
they were mfr based.  i guess slaac can be used to confuddle the two. :)

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Jun 2017 03:53:20 +0600

fwiw, various folk who run intl wandering events have written to say
"yes, please."

randy

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 6 Jun 2017 18:38:00 -0400

bssid/macs are manufacturer based but there are companies that provide
positioning services based on learning where those MACs are -- typically
combining such MAC based Wi-Fi/Bluetooth information with IP, GPS, ...
information to try to get an accurate location. If you happen to be in a
hotel function room and can only see meeting provided APs, so you can't see
any fixed local APs, you can easily get Geolocated to the previous meeting
site.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jun 2017 11:15:49 +1200

> they were mfr based.  i guess slaac can be used to confuddle the two. :)
 
A fair hit, but topologically- or physical device- based are
both broken solutions IMNSHO. I understand that the IETF NOC
has to deal with it pragmatically, but let's not imagine that
there's any real fix for intrinsic breakage.

   Brian

---

From: Theodore Ts'o <[email-masked]>
Date: Tue, 6 Jun 2017 19:31:06 -0400

> any fixed local APs, you can easily get Geolocated to the previous meeting

What really surprises me is that it should be relatively easy for
these geolocation services to detect that BSSID/MAC's for the Access
Points belong to conference / rental services.  The pattern is pretty
obvious, even if the conference isn't kind enough to provide the
BSSID/MAC list to geolocation service.

The IETF AP's go active for a short-time, and then go dark, and when
they come back, they are obviously in a different location --- users
who geolocate to those AP's quickly shown to be in the "wrong" place,
in that when they get Cell Tower information, it conflicts with the
geolocation hint associated with the AP.  If they are rental AP's,
perhaps the only go dark for a day or two before they come up in a
different location, but the pattern of "these AP does not have a
stable geolocation" should be really easy to spot.  (At least, until
Star Trek style transporters or some other matter teleporter comes a
Thing.)

The service could keep them on a list of AP's where after they go dark
for say, 24 hours, when they come back on-line the system should try
to use location services based on cell tower, GPS, etc., to figure out
where they are on a real-time basis.  And if the system isn't able to
do that kind of automatical location deduction on a real-time basis,
it could simply blacklist those AP's for use as a geolocation hint.

This doesn't seem hard....

						- Ted

---

From: Nico Williams <[email-masked]>
Date: Tue, 6 Jun 2017 18:44:14 -0500

> any fixed local APs, you can easily get Geolocated to the previous meeting

Can the BSSIDs be changed?  I know, that might be disruptive in that
users will have to re-teach their devices about trusted APs, but that
seems like a decent trade-off.

---

From: Clint Chaplin <[email-masked]>
Date: Tue, 6 Jun 2017 16:52:55 -0700

I guess they could be changed to Locally Administered.  Not sure the AP's
UI supports that.

-- 
Clint Chaplin
Principal Standards Engineer
Samsung Research America

---

From: George Michaelson <[email-masked]>
Date: Wed, 7 Jun 2017 09:56:38 +1000

I feel pretty odd about this. On the one hand, I think GeoLoc is
counter to <whimsy, belief, emotion> but I also recognize that it
happens, and a lot of things now depend on it. Stupid things like DRM
region lock, but also other things like optimal content source
selection, or language for an interface.

What do I want? I want less stupid. So I want either the DRM to die
(gonna happen. can I have a chocolate pony too?) or the Geo selection
method to work better.

But what my day job tells me, is that adding 'more' people to offer
ways to declare Geo, doesn't "fix" this problem. We, the RIR tried. We
didn't entirely help. Lots of reasons this turns out not to be
entirely useful. Some people say they don't want to believe what we
declare. They don't want to believe what Internet Address holders
self-declare. They only want to believe what they can measure,
triangulate, learn from <secret sauce> like BGP (oooooh! super
secret!!!) in ways which we don't understand. Or, from what websites
say. or DNS says. I know, lets put it in crypto, in the DNS...

And it also tells me that people have strong motivations to "mislead"
about their Geo, because of .. well.. basically the dynamics of the US
content industry and consumer choices. When it comes down to it if you
can demonstrate that a caribbean island resort hotel secured a
financial advantage having US located IP addresses and customer-choice
drove it up the price table (story I was told) then.. you know this is
a "thing" you can't control.

Really, I think if we stepped back, "geo information" is pretty
interesting. It feels like something we should have some ownership of.
But stepping forward, its been a tar pit, the entire time I've engaged
in it. Nobody can point me to a subject more likely to descend into
hell. Ok. maybe the DNS. And routing. or operations. I dunno. Its more
political than SNMP.

If something as simple as changing the BSSID stops the stupid, I'd say
add it to the playsheet. But it sucks this is likely to be workable,
and it sucks that something as silly as a Layer-2 device unique ID is
being tied to a location, for an agency which moves around the world.

Model be broken. Have no fix.

PS on a personal level I like more specifics in WHOIS, and
self-declared in the DNS and websites, I don't like super-secret sauce
methods, and I dont like people who re-publish public data as
privately tuned data, but are non-responsive on their 'fix problems'
email address. You know who you are...

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Jun 2017 07:56:08 +0600

> any fixed local APs, you can easily get Geolocated to the previous meeting

yes, that is what i thought i was trying to say

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Jun 2017 07:57:56 +0600

> there's any real fix for intrinsic breakage.

we have a text database of our bssid/macs.  we could prod the geoloc
provider to pull it and the new location.  would need authentication,
authorization, etc. of course.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Jun 2017 07:58:29 +0600

> Can the BSSIDs be changed?

many mfrs do not support

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Jun 2017 08:07:34 +0600

> they come back, they are obviously in a different location

how does the geoloc provider detect that they are in a new locatio?
i assume, but do not know, that google drives by, but not very often.
i have no ideas how others do it.  gsm comparison?  phone gps?  but does
my phone give them those data; i might not like that.

> users who geolocate to those AP's quickly shown to be in the "wrong"
> place, in that when they get Cell Tower information, it conflicts with
> the geolocation hint associated with the AP.

my phone gets the conflict, but does the geoloc provider?  does my phone
give them those data; i might not like that.

> where they are on a real-time basis.

i suspect they already do some sort of thing such as this.  after all,
it's their business.  unfortunately, roaming APs are probably a
negligible percent of their targets; which is why they do not even
answer our email.

randy

---

From: Christian Huitema <[email-masked]>
Date: Wed, 7 Jun 2017 09:23:13 +0200

> some existing wg might be.

Another argument for MAC Address randomization...

-- Christian Huitema

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 7 Jun 2017 09:23:51 +0100

From an entirely personal perspective I would prefer that
geolocation be irretrievable broken so that it could never
work rather than fixed to work correctly.

- Stewart

---

From: Christian de Larrinaga <[email-masked]>
Date: Wed, 07 Jun 2017 09:34:32 +0100

IETF perhaps via IAB could and I think probably ought to issue a health
warning on geolocation. It is too convenient for policy makers to assume
the snake oil is real - Christian

---

From: Andrew Newton <[email-masked]>
Date: Wed, 7 Jun 2017 08:39:59 -0400

> work rather than fixed to work correctly.

You're not alone.

The IETF did have a WG called GEOPRIV that ran for over a decade. On
top of that, other various proposals for geoloc have been put through
the IETF, some reaching standardization and some not.

The "PRIV" part of GEOPRIV was about "privacy", and any "good-enough"
geoloc solution will smack into some very serious privacy
considerations.

-andy

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 Jun 2017 09:42:27 -0500

> > Can the BSSIDs be changed?

Yes, I figured that might be the case here, but since it might not I
thought it worth asking.

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 Jun 2017 10:01:12 -0500

> Another argument for MAC Address randomization...

+1

Though that's likely to lead geoloc providers to use other methods over
which we'd have even less control.  But still, MAC address randomization
is a good thing all around.

---

From: David Farmer <[email-masked]>
Date: Wed, 7 Jun 2017 10:18:33 -0500

> is a good thing all around.

How would Client MAC address randomization help this situation? I not aware
of APs implementing MAC address (BSSID) randomization.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 Jun 2017 10:33:16 -0500

> of APs implementing MAC address (BSSID) randomization.

Neither Christian nor I said "client".  We're arguing that all MAC
addresses should be randomized.  As for BSSIDs, I'm not sure randomizing
them on boot is a good idea, but certainly on install/reset.

Nico
--

---

From: Theodore V Faber <[email-masked]>
Date: Wed, 7 Jun 2017 15:33:16 +0000

> From: ietf <[email-masked]> on behalf of Stewart Bryant <[email-masked]>

>work rather than fixed to work correctly.

I have good news for you, then: https://gimletmedia.com/episode/53-in-the-desert/

--
Ted Faber <[email-masked]>
Engineering Specialist
Computer Systems Research Department
The Aerospace Corporation
310-336-7373

---

From: Theodore Ts'o <[email-masked]>
Date: Wed, 7 Jun 2017 12:06:42 -0400

> work rather than fixed to work correctly.

On many platforms you can turn off locaion services (such as those
that depend on sending which cell towers or WiFi AP's your phone can
see) off.  This is true for Android, IOS, and Windows 10.

     	   	   	    	     	  - Ted

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Jun 2017 12:36:56 -0400

> see) off.  This is true for Android, IOS, and Windows 10.

Unfortunately there is typically no way to turn off just the location service that's broken.   Also, web sites guess your location regardless of whether you have location services enabled: it only takes one person with a phone that's reporting the BSSID of its AP to something that does geolocation to leak it.   So asking people to shut this off on the client isn't going to improve the UX problem for anyone, unfortunately.

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 Jun 2017 11:58:39 -0500

On Wed, Jun 07, 2017 at 12:36:56PM -0400, Ted Lemon wrote:
> Unfortunately there is typically no way to turn off just the location
> service that's broken.   Also, web sites guess your location
> regardless of whether you have location services enabled: it only
> takes one person with a phone that's reporting the BSSID of its AP to
> something that does geolocation to leak it.   So asking people to shut
> this off on the client isn't going to improve the UX problem for
> anyone, unfortunately.

Indeed.

This thread is ultimately caused by people wanting geoloc to at least
work correctly if it is used at all, not by people who prefer privacy.
Disabling location services on your devices will only make geoloc worse
for users who want geoloc to work.

If the gear allows it, just changes the BSSIDs and be done for now.

Maybe we need a WG to improve geoloc in general.  Though given some of
the issues described in this thread (e.g., geoloc providers not trusting
self-reported [by network providers] location information), I'm not sure
it can be done.  I'm OK with the idea that geoloc can't be improved.

Nico
--

---

From: "John Levine" <[email-masked]>
Date: 7 Jun 2017 18:27:37 -0000

In article <CAPt1N1ni9Z12gfNArK4GaJpXdp2OMoZXv_wKrHYCcCG2wom=[email-masked]> you write:
>are 7000 miles away from where we are.

I find the benefits of a real non-NAT address vastly exceed the
inconvenience of some map application showing me a default view of the
city where I was three months ago.  

Also, I dunno about you, but for me it would be far more convenient to
be geolocated in the US for the week while I'm at a conference,
regardless of where I am physically, since that's where I live.  I
expect that's true for many people who live in other countries, too.

With that in mind, and understanding that the appropriate response to
"would someone do X" is "we're all volunteers here", it'd be cool to
permanently geolocate chunks of the IETF network to fixed countries,
then have a way to ask for an address in a country's chunk.  At IETF
98 the top ten countries were US, CN, CA, DE, JP, GB, FR, SE, NL, KR.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 7 Jun 2017 18:30:53 -0000

In article <[email-masked]> you write:
>Points belong to conference / rental services. ...

>This doesn't seem hard....

You're making the unwarranted assumption that they care.  Remember how
hard it was to get Maxmind to stop sending a stream of angry people to
the farm that happened to be at the default location for unknown US
networks.

R's,
John

---

From: Leif Johansson <[email-masked]>
Date: Wed, 7 Jun 2017 21:53:42 +0200

So to sum up:

"Here is a problem: ... "

"No its not and even if it was, its not a bug, its a feature and
besides you can turn it off in the settings and also we covered it
in 5 different working groups over the course of the last decade
and also email is broken and I like the way it worked in DOS."

Sounds about right?

	Cheers Leif

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 7 Jun 2017 17:24:32 -0400

> and also email is broken and I like the way it worked in DOS."
Isn't the OP's question really:
  "GEO is not working well for conference organizers, users seem to
actually want it to work (despite protestations of even the OP, at times),
 are there folk on-list who would like to gather and discuss making the
processing of changes a bit more automagical?"

yes, some folk 'do not want to give up their privacy', and some folk want
to 'order pizza near me'... welcome to the tubez dudez.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 7 Jun 2017 23:27:38 +0200

Skickat från min iPhone

> 7 juni 2017 kl. 23:24 skrev Christopher Morrow <[email-masked]>:
> 
> 
> 
>   "GEO is not working well for conference organizers, users seem to actually want it to work (despite protestations of even the OP, at times),  are there folk on-list who would like to gather and discuss making the processing of changes a bit more automagical?"

Yep

> 
> yes, some folk 'do not want to give up their privacy', and some folk want to 'order pizza near me'... welcome to the tubez dudez.
> 

:-)

---

From: "John Levine" <[email-masked]>
Date: 7 Jun 2017 22:09:39 -0000

In article <[email-masked]> you write:
>"No its not and even if it was, ...

I'd say that summary is not even wrong.  Our problem is not technical.
Geolocation is handled by a handful of companies that have no
incentive to solve our problem.

How many wifi networks are there in the world?  I expect upward of a
hundred million.

How many wifi networks regularly move from one continent to another?
You can probably count them on your fingers.  We're not even a
rounding error, and we're not paying customers.  Why should Maxmind et
al. spend money to build a mechanism to deal with us and networks like
ours?

R's,
John

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 Jun 2017 17:27:00 -0500

> al. spend money to build a mechanism to deal with us and networks like

See, now, this is why we need to put geoloc information into DNS and/or
BGP, thus cutting out the secret sauce makers for all cases where
services don't mind trusting DNS/BGP geoloc data.

I mean that half-facetiously, half-seriously.

---

From: "John R Levine" <[email-masked]>
Date: 7 Jun 2017 18:36:25 -0400

> I mean that half-facetiously, half-seriously.

If you want a GPOS or LOC rrtype, you know where to find them.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Theodore Ts'o <[email-masked]>
Date: Wed, 7 Jun 2017 19:41:16 -0400

> al. spend money to build a mechanism to deal with us and networks like

Well, it's said that conference/standards travellers often drop large
sums of money at many fine dining establishments.  And no one seems to
have a problem when concierges get referral fees for suggesting
restaurants to their clients.  There may be more money in getting this
geolocation thing as right as possible than you think.

It is interesting though that if someone picks up a phone and says,
"Hey Samantha[1], find a nice restaurant near me", and it does, (a) some
people think it's creepy, and (b) some people think it's somehow dirty
that the company that created "Samantha" might get paid for the
referral just like a hotel concierge.

[1] http://www.imdb.com/title/tt1798709/

Or does it cross the line when "Samantha" remembers that you've been
asking her questions about molecular gastronomy and tailors the
responses she sends back to you based on that?

It's really fascinating to me that somehow it's OK when a Nordstrum's
sales associate does basic research on his or her clients, or keeps a
notes in their notebooks of their client's likes and dislikes, and the
dates of their wedding anniversary, relative's birthdays, and suggests
gifts for their client.  Somehow *that*'s not creepy (in fact, some
find it flattering, or makes them feel important), but when a computer
does it, it's creep city....

					- Ted

---

From: Dave Cridland <[email-masked]>
Date: Thu, 8 Jun 2017 08:43:28 +0100

> I mean that half-facetiously, half-seriously.

I'll take you seriously, if I may.

First, I'd note that several WiFi networks move around on one
continent on a frequent basis, and many fly through the air between
continents. While a network that is physically bundled into boxes and
moved might be an edge-case, there are an ever increasing number of
access points on the move these days.

Given that the geoloc problem fits into one of two cases, I think you
have half the issue sorted there - a DNS record in the reverse-lookup
domain would satisfy the case where a service wants to go from only an
IP address to a location.

But much of the discussion revolved around a device complicitly
sharing its location based off the BSSID; in this case a DHCP
extension would surely be useful? We're working on the assumption,
here, that the device - and therefore hopefully its owner - is
deliberately providing a location, after all.

On the assumption that administrators of access points are often not
going to set this up, it might also be useful to have an extension
which simply indicated whether the network was fixed or mobile.

Dave.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 8 Jun 2017 14:40:48 +0200

Hi John,

> incentive to solve our problem.

THIS. 

Those companies make their business off of selling information, and that
information has to be accurate to within some degree.  The IETF is in
the noise.  How many roaming show networks are there really?  If this is
something that is really important to the IETF, then the organization
should use equipment where the BSSID is changed, and/or perhaps start to
rely on local facilities to provide the appropriate services.  Yes, that
might prove expensive.

Not only THIS, but developers are now actually being paid to link their
apps to certain libraries to invade consumer privacy (Egelman et al). 
And that means that just rotating BSSIDs to protect privacy doesn't
actually do much for privacy, but it might do something for accuracy.

Eliot

---

From: Leif Johansson <[email-masked]>
Date: Thu, 8 Jun 2017 16:43:55 +0200

> actually do much for privacy, but it might do something for accuracy.

All right so the claim is now that it may be an issue but its not
worth spending time on since the "other side" won't want to play ball?

Fair enough, however I note that the OPs message claimed that the
NOC is /reasonably/ successful in dealing with this issue by
sending emails so its not inconceivable that an automated process
could work...

otoh it would require that the IETF manage to keep it simple... ;-)

	Cheers Leif

---

From: Randy Bush <[email-masked]>
Date: Thu, 08 Jun 2017 21:27:20 +0600

had a convo with a very large and well known cdn provider who uses ip
address based geoloc.  they actually go to the noc web site to check if
our address ranges have changed, where our next meeting will be, and set
their database accordingly.

i would like to make their life easier.  i do not think on the wire
protocol is needed; i suspect it can be done with some sort of pre-
registered authorization and a signed well known data format.  ip
address and mac seem to be the two mobile meeting identifiers.  but
i am probably a bit premature to be in the solution space.

the following did have a certain ring to it.  welcome to the ietf.  

of course i have never been guilty of such :)

randy

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Jun 2017 12:04:13 -0400

> rely on local facilities to provide the appropriate services.  Yes, that

So, if we want to get their attention, we need to increase the noise until
the data is useless? :-)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Randall Gellens <[email-masked]>
Date: Thu, 8 Jun 2017 09:58:01 -0700

At 4:50 PM -0400 6/6/17, Ted Lemon wrote:

>  Because it makes it very difficult to use various services if they 
> think we are 7000 miles away from where we are. Latency can be bad, 
> and using maps can be impossible.

I personally find the effects more an amusing artifact that an actual 
hindrance, but that's just me.  However, when I'm traveling and not 
part of an IETF, I find that using a hotel provided IP address 
without a full VPN causes its own set of difficulties with web sites 
assuming the language and character set of the country I'm in.  In 
some cases I'm unable to use a Capcha since it's in a script I can't 
read, and I'm unable to select a language or country on the web site 
for the same reason.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Politics is the art of making the inevitable appear to be a
matter of wise human choice.                 --Quentin Crisp

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Jun 2017 13:12:25 -0400

On Jun 8, 2017, at 12:58 PM, Randall Gellens <[email-masked]> wrote:
> hindrance, but that's just me.

It made it a pain to schedule an IoTdir dinner in Chicago—I kept getting redirected to sites with similar names in Seoul.   I am embarrassed at how long it took me to realize that I could just use my phone's tethering capability to solve the problem.

That said, the artifact you are talking about actually happened to me in Chicago, because I was "in Seoul" as far as (some) geolocation services were concerned.   The way to prevent this behavior when in a foreign country is to use a VPN; this should work just fine from the IETF network, if not from the hotel network.

Of course, even better would be if geolocation information could be overridden from the browser; I'm not aware of such a possibility that actually generally works, however.

---

From: "John Levine" <[email-masked]>
Date: 8 Jun 2017 17:22:24 -0000

>geolocation thing as right as possible than you think.

Our phones geolocate just fine, so I think that part of the problem is
solved.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 8 Jun 2017 17:23:41 -0000

In article <[email-masked]> you write:
>i would like to make their life easier.

If there are geoloc providers who would like our updates, that would
be dandy.  But my impression is that the problem is that there are
many (or at least some large ones) that don't.

R's,
John

---

From: Randall Gellens <[email-masked]>
Date: Thu, 8 Jun 2017 10:53:36 -0700

At 1:12 PM -0400 6/8/17, Ted Lemon wrote:

>  The way to prevent this behavior when in a foreign country is to 
> use a VPN; this should work just fine from the IETF network, if not 
> from the hotel network.

Indeed, VPNs solve the problem by changing where one appears to be to 
the web site, which is why I said the problem happens "without a full 
VPN."

Really, everything we're talking about in this thread is because of 
the various hacks that have grown up to guess at various things such 
as location, language, character set, etc.  The hacks work well 
enough enough of the time that people rely on them.

Because the hack works well enough enough of the time, it's common 
for people to assume that it's reliable, but as we're discussing 
here, it isn't.  Interestingly, in the U.S., there is work ongoing to 
develop a National Emergency Address Database (NEAD), which is 
designed to reliably and authoritatively provide a specific location, 
e.g., by having a venue owner specify the MAC addresses of Wi-Fi APs 
within the venue, as well as other sources and inputs.

-------------- Randomly selected tag: ---------------
Badkruka (BAD-ruke-ah; Swedish; noun): Someone who refuses to enter
a body of water, no matter how warm.

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Jun 2017 13:56:10 -0400

--On Thursday, June 8, 2017 09:58 -0700 Randall Gellens
<[email-masked]> wrote:

> I personally find the effects more an amusing artifact that an
> actual hindrance, but that's just me.  However, when I'm
> traveling and not part of an IETF, I find that using a hotel
> provided IP address without a full VPN causes its own set of
> difficulties with web sites assuming the language and
> character set of the country I'm in.  In some cases I'm unable
> to use a Capcha since it's in a script I can't read, and I'm
> unable to select a language or country on the web site for the
> same reason.

While I agree, I think this may be a different problem and one
that we (and/or W3C) could fix if we were motivated.  A
variation on the "incentives" theme is useful here too -- very
few actors have incentives to condition information being
provided to you based on bad choices of language or locale, even
if there are complex case-by-case decisions (or sheer laziness)
about whether the costs of getting things right in a larger
number of cases are worth it.    We've got machinery for
specifying preferences in cultural or locale information to web
browsers (and the SLIM WG has been working on somewhat parallel
arrangements for other kinds of real time communications).   Are
those options right?  Do they provide enough preference
information that you (or a typical user, or a heuristic) can
figure out whether to use the information they think you've
given a browser (or failed to provide), rather than what the
hotel, or the hotel network, or even the choice of computer if
you are using one you don't own) are telling them?

Those are actually not easy questions in terms of designing the
right sorts of tools and indicators.  Pursuing your example,
suppose you are in Lower Slobbovia, don't speak or read Lower
Slobbovian, but want to find a nearby pizza restaurant.
Probably you want to have the system communicate with you in
English, but you don't want the locale information to reflect,
e.g., California, because knowing where the nearest pizza
restaurant would be if you were in California would not be of
much interest. That, in turn, leads to another economic issue:
if the local, Lower Slobbovian, restaurant operators federation
has concluded that it isn't worth the costs of supplying
information in English,  then you don't even have a localization
issue any more, you simply have a choice between asking in Lower
Slobbovian (or some other language they want to support) or not
asking in any way that yields answers.

On can respond to that example by asking questions about
automated translation, etc., but I'd just make the example more
complicated.

It seems to me that set of issues has little to do with how the
servers that interact with the hotel network guess at language
or location and, in particular, whether they use the IP or MAC
address to get there.   But it does seems to me that it suggests
we should review whether our various means for explicitly
telling systems about locale information do what is wanted and
fix them if they don't.  Certainly, such fixes should recognize
the right of those who don't want accurate location information
under any circumstances to starve in the dark, but it is not
clear to me that they should be our primary audience. 

   john

---

From: Leif Johansson <[email-masked]>
Date: Thu, 8 Jun 2017 20:24:34 +0200

> many (or at least some large ones) that don't.

I didn't get that impression from the OP but maybe thats a topic for
a bar BoF... in Praha ... if we can find something close to the Loop.

	Cheers Leif

---

From: Theodore Ts'o <[email-masked]>
Date: Thu, 8 Jun 2017 16:58:25 -0400

> Our phones geolocate just fine, so I think that part of the problem is

We should be clear what problem we're trying to solve.  Randy Bush's
original posting was about geolocation using BSSID's belonging to Wifi
AP's.  This is typically done on mobile devices, although I suppose
some browsers could be querying the OS for Wireless BSSID's.

Other people have broadened this discussion out to geolocation by IP
address, where the server may be trying to make inferences based on
the IP address of the web request as it appears to the front-end
server of the web service.

This is very different from the Browser providing HTML5 Gelocation
information, after asking permission of the user whether a particular
web site should be given visibility to whatever location information
the browser might posses.

So in classic IETF fashion, if this is something where someone wants
to start a wg or a BOF, it would be helpful if the scope of the
problem is very clearly defined.  :-)

						- Ted

---

From: Randy Bush <[email-masked]>
Date: Fri, 09 Jun 2017 08:52:34 +0600

> ...

i did try.  to be honest, the (to be polite) broad ranging discussion is
about what i expected.  i thought it worth the try.  the good side is
that it gave so many people an opportunity to show how smart they are.

in the meantime, the noc will work it as best we can.  as google has
already relocated, phones will generally work.  some cdns have
relocated.  as to the rest, you'll have to excuse me if i rofl when
anyone whines that they are in chicago or seoul or whatever.

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 09 Jun 2017 08:54:22 +0600

> the web site

so, when in praha, a restaurant search will give me a recommendation in
tokyo.  this is great, as i prefer tokyo food.

randy

---

From: "John Levine" <[email-masked]>
Date: 9 Jun 2017 15:31:14 -0000

>> problem is very clearly defined.  :-)

Would it be useful to document the various ways the meeting network
gets geolocated so at least we have a reference for what's broken?

I'm thinking of an info RFC.

R's,
John

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Jun 2017 12:49:40 -0400

> I'm thinking of an info RFC.

I think so.
    "A survey of failure cases for IP and BSSID based geolocation"
or maybe you can work in the word "Tragedy".
(cf: https://www.goodreads.com/book/show/555377.The_Tragedy_of_the_Moon )

I wonder if AMS runs over roaving conferences and could provide contacts to
others...

---

From: Randy Bush <[email-masked]>
Date: Mon, 12 Jun 2017 20:29:09 +0700

>     "A survey of failure cases for IP and BSSID based geolocation"

thanks for volunteering, guys

randy