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