Spatial Location BOF Meeting Report
Minutes, Spatial Location BOF Meeting, IETF-47, Adelaide,
Australia, Thursday, March 30th, 2000, 9:00-11:30 am
Chairs: Haitao Tang, James M. Polk
Minutes reported by: La Monte H.P. Yarroll, John Loughney,
James M. Polk, and Haitao Tang
The following agenda was presented and accepted:
1. Agenda bashing 3 min
2. Individual presentations 72 min
3. Invited presentations 25 min
4. Open review of this effort 30 min
5. Charter bashing 12 min
6. WG / another BOF formation? 8 min
Individual Presentations
This Spatial Location Effort and Its Problem Scope - Haitao Tang
Related files: draft-tang-is1f-req-00.txt and
http://www-nrc.nokia.com/mail-archive/ext-ip-location
Haitao first give a brief overview of the discussions had in the mailing
lists. They were related to apps, spatial location info, spatial
location info access and exchange, security issues, architectures of the
spatial location related systems, protocol considerations (ISLP, SLOP,
PLOP...), others (regulation, people’s addresses and identifiers...).
There are five problems proposed and discussed in the list:
(1) determining Spatial Location of an IP device itself, (2) locate the
spatial location of an IP device, (3) find IP devices w/a certain
resource, (4) send to unknown IP device in a geo-region, and (5) publish
to a geo-region (for a period). Some identified requirements: security,
dev-server association, spatial Location request/update routing (among
servers), spatial Location info verification, and spatial location based
messaging.
Haitao proposes to focus on "For two IP devices to exchange spatial
location info reliably and securely", where the the devices can be
various types.
The People Location Protocol - Patrik Fältström
Related file: draft-faltstrom-plop-01.txt (unsubmitted), at
http://www-nrc.nokia.com/ip-location/draft-faltstrom-plop-01.txt
Patrik present the PLOP, an I-D made in 1997. He voice during this
presentation that the scope presented here might be too limiting.
The People Location Protocol shows the examples of how the PLOP people
were thinking. They were: "Why not plop? (How to identify a stream of
data? How to handle keep alive event? Given an object, how to find the
service provider which happen to have the location? Is this the
multicast problem?)" and "Why plop? (There is a need in finding the
geographical location of objects. Objects might now want to be found.)".
The key issues were: privacy (is a huge issue! The object can have a
policy for access control. Access is not yes/no, but a gray space),
alternative responses, scaling (is also a HUGE issue), and security.
There are four functional entities in PLOP: object for locating,
announcer, provider, and subscriber. PLOP has two parts: PCP is control
protocol and PLP is the secure location protocol. PCP and PLP are used
between the functional entities as shown in "Object<-- Unspecified
(i.e. tech specific)--> Announcer <--PLP and PCP--> Provider <-- PLP
and PCP --> Subscriber". There can be a mesh of providers in real cases.
PLOP works as such. The announcer updates access control lists using
the PLOP Control Protocol (PCP) which is secured using PGP. The
announcer also signs & encrypts the location of the object and the
advertises to Provider Mesh. The subscriber get the info after
authentication by the provider...
Big question from this presentation is: How do you scope the location
reply to the ‘system' with policy then determines who can them access
that loc. Info & how different subsequent Loc. Requests for (my)
location info can get appropriate different query results?
Spatial Location Based Services - Kenji Takahashi
Kenji present the issues on Spatial Location Data Services, based on
what has happened in Japan - such as PCS-based solutions already on
market and a large list of possible applications, e.g., property mgmt,
emergency safety, local adv. EC, entertainment tourism, regional
marketing, local community (Comm info, city planning...).
There were ways to get location information [These are mostly network
Loc. examples. --piggy]. They are at different levels, such as URI
(Web resources), IP address (device), and Lower layers. The reasons of
the ways needed in different levels were also identified, for example,
the way at IP device level is needed for handling location of IP
devices and IP-based location services.
An L2 example is given here. Basic types of services are "Where am
I?", "Where are they?", "Costs a few cents per usage", "Operated by
PCS service providers", "Accurate to 100-400 yards", "Scenario", and
"Subscriber registers phone# and monitor phone#". Monitor (trusted
party) has password given by Subscriber. There are multiple access
methods for the information. Monitor calls the location center. The
center calls the PCS phone and the phone calls back with location
information.
Spatial Location Server Authentication - James M. Polk
Related file: draft-polk-slp-loc-auth-server-00.txt
Spatial location protocol server authentication expressed the
following.
Server needs to determine it's own location. There is the need of
authenticating servers (trusted infrastructure). IPsec is proposed for
the purpose. Note that we can have multiple infrastructures involved.
General comments regarding: Does the Server really need to determine
it’s own location first? Likely answer is: "No".
Some Scenarios for Location Based - Mari Korkea-aho
Related file: draft-korkea-aho-isl-scenarios-00.txt
Some scenarios for an ISL arch has presented the following.
Functional Requirements are:
1. Locate/track somebody/something, such as "Where did I leave my
laptop?" and "Where is Pluto running around? (IP-device in dog
collar)". Its implications are IP-dev can retrieve/receive location
info of another IP-device.
2. Broadcast information to devices in a certain region, e.g.,
"Emergency warning of snowstorm" and "Location site shutdown
warning". Its implications are (1) IP-dev can determine target
IP-devices in region and (2) Client IP-dev can control publication.
3. Retrieval of location based information and service, e.g., "Mobile
user wants to order local taxi, pizza" and "User wants regional
information about Helsinki". The implications are (1) service must
be able to obtain client location and (2) find server providing
service for the specific region/location
4. User subscribed location based services, such as an IETF-
participant wants to be notified about sights in Adelaide when
walking past them. Its implications are (1) service must obtain
client location periodically and/or determine if it is still within
the region for the service and (2) find server providing service
for the specific region.
What needed are the basic functions:
1. IP devices need to be able to communicate location information,
2. Finding IP-devices located in a location important, and
3. Finding services available for a certain location/region.
Location Types and Their Relations - Rohan Mahy
Location Types and their relations, with abstract slides, get away
from just physical location of GPS device or cell phone. They include:
expressions of location, measurement issues, uncertainty, and
granularity.
Expressions of location consist of: geographic (relative - distance
from X, absolute - lat, long, descriptive - address, topological -
connected to...
One can combine, convert, add these: (1)relative + topological ->
absolute, (2) absolute <-> descriptive, and (3) topological ->
descriptive.
Types of endpoints consist of those of mobile wireless, portable
wired, fixed (wired or wireless).
Including wired devices is for the cases such as "kiosks and wired
laptops" and "emergency services".
Uncertainty/accuracy is concerning: accuracy within some distance
- "85% certainty within 10m radius" and multiple possibilities -
e.g. reflections, or multiple location information sources.
Granularity is specified by such as country, postal code, street
Address or landmark room, lat/long in minutes/sec.
Time sensitivity/movement imply: (1) very granular requests are more
time/motion sensitive, (2) Is it important to predict location?, and
(3) more movement = more uncertainty.
Location technologies are triangulation, inertial navigation, and
configured [I would add network visibility].
Location computation is about "where is location calculated?",
"end device?", "network device?", etc.
What do applications need? As usual, provided excellent foundations
for what needs to be thought of within this BOF.
Inter-technology Mobility (ITMO) Management aided
with Geo-location Information - Mika Ylianttila
Related file: draft-ylianttila-isl-prot-req-00.txt
Inter-technology handoff presents the work of Project WINGIP
(Wireless Indoor Geoloc and IPv6 traffic analysis).
ITHO scenarios are Moving-in, Moving-out, and Moving-through.
Requirements for the system architecture are: (1) geolocation data
source, (2) secure coordinate server, (3) updating Frequency/Terminal
velocity, (4) geolocation accuracy, (5) inter-working functions,
(6) checking resolution of LPN beacon, (7) transition time,
(8) transition region, and (9) initiation distance [See the picture
on the ITHO SCENARIOS slide.]
Requirements for the terminal are: (1) (must) interfaces for LPN and
GPN, (2) transparent mobility mgmt, (3) supports selected IWF, such
as mobile IP, and (4) secure communication with SCS, etc. [Author
provides a location algorithm.]
IP Telephony E911 Requirements, Issues and Solutions - Mo Zonoun
IP telephony E911 requirements is presented by Mo, who believes E911
as a killer application--a regulatory requirement. The Scope of E911
is defined by US rules, while other countries can have similar rules.
E911 has the features - CO routes (Selective routing) 911 calls with
ANI to emergence service center.
NENA's MODEL STATE LEGISLATION (NENA) is writing requirements for
Model State Legislation (ref: http://nena.org).
FCC WIRELESS REQUIREMENTS was skipped. IP TEL LOCATION ID PROBLEMS
were covered by other speakers. IP TELEPHONY PROTOCOL STACK was
mentioned for reference if needed.
Lots of issues with whether the IETF, being international, should
necessarily cater to the requirements of a single government
regulation set? Most participants said no the IETF shouldn’t.
Counters were mentioned that when possible, there should be
provisions and awareness to certain "show stopping" regulations that
will prevent any IETF effort. There isn’t a room consensus on this
issue.
It is brought up that the possibility of a ‘Big Brother’ role with
this protocol but no one seemed to want to go down that detail,
at least, not during the meeting.
2nd presentation: IP Telephone Spatial Location - Mo Zonoun
It is an example case of solution - a NORTEL's solution. It provides
accurate trusted location and is suggested working everywhere for
many things cheaply.
Its considered location information transmitter is a stationary
device - installed at various locations (offices, hotels and homes),
similar to smoke alarm detectors. When activated it transmits a
unique preprogrammed location. Its considered location information
receiver works as, after installed on telephones/computers, the
unit transmits its location.
Mo Agree to provide this list a formal declaration of known IPR
issues with the recently filed Patents from Nortel Networks, on this
subject presented upon.
ISL Architectural Considerations - John Loughney
Related file: draft-nyckelgard-isl-arch-00.txt
The reasons for this architecture consideration are:
(1) More and more wireless devices interact with IP networks
(2) This impacts the current end-to-end nature of IETF protocols
(3) Location becomes an important parameter in providing and
accessing services and users.
This consideration on the architecture is to answer the following
questions: (1) Implications of obtaining location, (2) How a terminal
stores or registers its location, and (3) How to exchange/relay
location to other parties.
Terminology used in this consideration includes: User Interface,
Location Agent (Location Proxy), Positioning Function, Information
User.
Its implementation scenarios consist of that of terminal centric, that
of network centric, and their mixed.
Issues raised are: "Does this cover all cases?", "Security concerns (as
well as authorization, confidentiality)", "Accuracy", "Raw data
accuracy", and "Desired accuracy".
Invited Presentations from Other Organizations/IETF Working Groups
The Open GIS Consortium - a platform for place-based and position
advantaged information systems and services
- Louis Hecht (VP, representing Open GIS Consortium, Inc)
Related source: http://www.opengis.org
OpenGIS is:
- Not-for-profit trade assoc. to enhance interop of GIS technology
- Funded to identify pain, solve, get out of way, and
- SCOTS.
[They have a wonderfully complicated specification process. They are
fully buzzword-compliant. They play nice with all the other standards
bodies.]
We have demonstrated interoperability of geospatial systems at two
levels: Component Interoperability (tightly-coupled) and Messaging
Interoperability (loosely-coupled).
Application development options are: open competition, no standards,
tightly-/loosely-coupled (available now) - would build applications
with any commercial mapping product, using commercial products that
implement a commercial standard interface. The loosely coupled are
such as "Catalog Services (course-grained)" and "Web Mapping Server".
There are six families of interfaces in OpenGIS.
WHY ARE WE HERE? We want to support the IETF in getting location
services (at communication level?), [Layer 2? 3? something else?
-piggy], to let IETF solve the related scalability issue, etc.
A coherent vision is:
loca obj
IP Device ----------> Communication Service Providers --->
Partitioned Services
Services to an end user has the partitioning by content and network
constraints. There are thus communications service provider,
location conversion service provider, content service broker, and
location based service provider, where they inter-act with each
other in certain ways.
This location object is very complicated. More than just an x,y
coordinate pair.
Problem Space is suggested as those of network (IETF), joint stuff,
and those of applications (OGIS). OGC offers to coordinate with
IETF WG if one is formed. Louis supports this effort to be a WG.
WAP Location DC Scope - Frank Zillikens (chair, representing WAP
location) [due to schedule conflict, Frank cannot make to
this IETF meeting. Mari is asked to help for a
very brief presentation by Haitao.]
WAP Location DC Scope includes:
- Define the overall WAP architectural framework
- Location based application interface
- User privacy
- Legality
- Location requirements
- Network Operator privacy
- Out of scope: Position Technology and Certain legal issues.
Invites this effort of IETF to present in Miami 2 April to April 7
or later. Mail questions to <Frank.Zillikens@nokia.com>
Global Positioning - Joseph M. Reagle Jr. (representing W3C,
on behalf of Johan HJELM)
Related file:
http://www.w3.org/2000/Talks/0330-ietf47-spatial/all.htm
We want a single data format and a consistent serialization for many
protocols. Suggested approach is: that based on the lowest denominator
of the formats proposed or used. Please don't fragment further.
Service Location Protocol - Erik Guttman (chair, SVRLOC WG)
Related file:
http://www-nrc.nokia.com/ip-location/Erik-SLP-abstract.txt
Service Location Protocol has RFC’s 2165, 2608, 2609, 2610, and 2614.
Its applicability is limited and within a single administered network.
It requires either admin scoped, multicast, or dhcp config.
Fully Decentralized or Automatic "Concentration"
Service "Model" is of:
- A URL Identifies AND Locates the service
- A Service is associated with a set of Attributes
- A service can be discovered within a scope.
[Physical scope is germane here.]
The characteristics are assigned with approaches of the static, the
dynamic, that from SLP (scopes da adverts), that from DHCP, and that
from MADCAP.
Location based on spatial information in SLP [This is a built
prototype--the GLOWING PRINTER]
- assumes clients move servers don't,
- operator configures map-coord tuples on server, and
- let clients select a map, click or drag a region and the
available nearest server.
SLP security is based on assuming keys, where server signs
advertisement and client verifies signature of advertisement with
caches. There is an extra key for signatures.
Open Forum
Attendees are refreshed and informed on how to sign onto the
mailing list with: majordomo@research.nokia.com
subscribe ext-ip-location (in mail body) and
nothing else in the email (no sigs!)
La Monte H.P. Yarroll get a chance to present their thoughts based
on draft-oberlander-location-00.txt (unsubmitted yet). The main
message is: "Location is more - Location is more than where you are",
such as spatial, topo., geopolitical, network, logical, and personal.
This BOF meeting is finished with the following combined agenda items
into a single open session: "Open review of this effort", "Charter
Bashing", and "WG/another BOF?" In addition, where are we going from
here?
Generally, a great interest had been shown from the attendees. There
are fair amount of questions mainly related to the not-very-clear-yet
direction of the BOF. Most of them seem to be on how large this BOF’s
scope could be and what is realistic one for the BOF’s Charter. That
is suggested to get worked out on the BOF list.
Room consensus is that, if the charter gets more clearer, this BOF
should proceed towards getting full Working Group Status.
Decisions are: (1) Further review/re-consider the exact problem(s)
for the effort to solve, (2) Further investigate the requirements,
and (3) Develop a WG charter and apply for a "spatial location" WG
in the next IETF meeting.
Meeting is closed. Note: All received slides are attached with
this minutes to IETF.