Spatial Location BOF Meeting Report IETF-48, Pittsburgh, PA, USA Monday 31st July 2000, 19:30 - 22:00 Chairs: Haitao Tang and James M. Polk Minutes reported by: Jussi Ruutu and Mari Korkea-aho Agenda: - Agenda Bashing - Haitao Tang 5 min - Scope of This Effort - Haitao Tang 10 min - Spatial Location Protocol Requirements - Brian Rosen 40 min - A Simple Text Format for the Spatial Location Protocol - Rohan Mahy 10 min - Target Naming Scheme - Haitao Tang 10 min - Basic SLoP Architecture Proposal - John Loughney 10 min - OGC comments Louis Hecht - Charter Bashing - James M. Polk 20 min - Review of Milestones and Group Status - Haitao Tang 10 min Agenda Bashing The agenda was accepted as shown above. Scope of the BOF by Haitao Tang The purpose of this effort is to have a standard protocol, called Spatial Location Protocol (SLoP), for an application to acquire the spatial location of an identifiable resource over or represented on the Internet in a reliable, secure and scalable manner. The basic model for SLoP includes three components: 1) Target that is the object whose location is of interest 2) Server that can provide the location information and 3) Client that is interested in the location of the Target. The scope of the SLOP BOF/WG is to define 1) Spatial Location Representations 2) Representation Negotiation Mechanism 3) Security mechanisms 4) Policy Mechanisms 5) Server Discovery Mechanisms 6) Transmission and Reliability Mechanism and 7) SLoP Message Coding Mechanism. The way how the location is determined is out of the scope of SLoP. Q: This kind of approach is useful also for a number of other protocols, not just for spatial location. A: Yes Q: Does this SLoP also include moving targets A: Yes. Q: Is the server assumed to be static? A: No. C: To standardize the way of add location information into existing protocols. Individual presentations Spatial Location Protocol Requirements by Brian Rosen (draft-rosen-spatial-requirements-00.txt) Document contains requirements for the SLoP. Document written by a small team and it contains seven sections. Document includes: - Definition of terms Three concepts are essential: 1) Target, 2) Server and 3) Client. Client asks the Server what is the location of the Target. For example GPS or triangulation systems are included. The way how target is located is out of the scope. These requirements are for the protocol, not for the implementation. Also some concepts such as accuracy, exactness or obfuscation are defined. Q: There are other activities at other places. Do you know? A: We are aware but want to focus - Location representation "Schema" defines the logical scheme that the location representations are based on, such as WGS84. "Format" defines how a given schema is represented. The protocol must define one default location representation. Protocol must also permit as a minimum certain values to be included in a report, such as used location type, geocentric position, accuracy, exactness, time stamp, etc. Multiple representations must be supported in a single report. Protocol must be also extendible. Q: Is WG going to specify all this? A: One set is going to be specified. The first version of the protocol should define a way to expand the protocol. It is not an exhausted list. Q: Does SLoP include other planets? A: Perhaps the reality is that now in 2000 we do not need this for the first version. Q: Is there a format for targets that are more than the size of point? A: Not yet considered. Discussion is encouraged in the mailing list. The first version should be something realistic for most of the people. Q: Does this have relationship to E911? A. Some people in list are aware of E911 Q: Is exactness different from accuracy? A. Yes. Exactness is for example 3 inc. but accuracy reported may be 3 miles. Protocol only delivers accuracy. Exactness can be used for multiple replies, but accuracy is different for different clients. This can be discussed more in the list since exactness is internal parameter while accuracy is external. Q: What is Target? A: The object that is located. C: It seems that use cases are missing - scope not clear. A: We do it in the architecture document. Q: Is there any overlap with protocol requirements for location information and representation information that was discussed earlier (IMPP)? A: IMPP is not yet ready to support location. IMPP may share some type of requirements issues. C: This is one aspect included in the older work with IMPP. A: The general requirements are similar but not detailed. SLoP should pay more attention to IMPP document. C: Accuracy and exactness should be re-named. A: This has been discussed, but can discussed more in list, precision and accuracy. - Message coding Multiple format should be supported. A simple format is needed and timestamp as well. Coding should be extendible. - Representation negotiation A mechanism is needed for the server to inform the client which representations it supports. The client should also be able to select which is used. Periodic position updates are needed. - Server discovery The client must/shall be able to find the appropriate server for a given target. URI is currently supported for identifying the servers. The discovery mechanism should be some widely supported mechanism such as DNS. - Transport UDP transport shall be supported. TCP is optional. Protocol may support RTP and/or SCTP as optional transports. Also QoS should be able to be requested. Q: Is authentication included? A: It is in the next part. Authenticate first and check what you can do next. IPsec is most possibly used. - Security Security is a big issue. Security associations are needed. Authentication is mandatory to implement between client to server and server to client. NATs and firewalls should be considered. Location policy decisions should be based on factors in addition to identity, such as group membership etc. Data integrity and confidentiality are needed. Anonymous use should be supported. Security mechanisms should specify a mechanism for extending the security mechanisms for additional capability. - Policy Policy Enforcement Point mechanism is needed. Optional Policy Decision Point can be added. Q: Is there a way to tell the server that there is a single policy for, for example, several devices of one person? A: We should use what there exist. Q: Can the location be sent without authentication? For example a cellular phone with anonymous subscription? A. This is policy issue. We are not aiming for E911 now. This depends on the policy used. Q: Is authentication required (yes)- what about emergency calls? A: This should not be a problem for E911 calls since I should know that when I make E911 call the phone should be located. Q: Cachebility of the information? Multiple copies of the reports. A: Good suggestion. This should be brought up in the mailing list. Q: Timestamp should show that this is the same report? A: But timestamp can serve the purpose. A: This should be discussed in the list. Q: Can one somehow determine from where the location information comes from? A: Identifying the server from where the info comes. A: Basic things must be defined first. More complex things can be added but they must be practical and useful. A Simple Text Format for the Spatial Location Protocol by Rohan Mahy (draft-mahy-spatial-simple-coord-00.txt) Main part of the presentation on the philosophy and motivation of the draft. Single question: What is the location of the target? This is the basic question that is most often needed. Single reference system; Geocentric (near Earth) location. This is practical now. What use is the simple text format: Common geocentric exchange format; If I know my geocentric location it is convertible to WGS84 How do I get my location Fixed configuration Global Positioning System Triangulation Inertial Navigation Dead Reckoning Example models include: 1) Target and server are physically the same (Where am I?) 2) Proxy is between target/Server and client. Simple coordinates can be used between client and proxy. Target is IP device. 3) Target is non IP device. Simple means: - Human readable text encoding - Single datum (WGS84) - Single time format (UTC) [no timezones] - Only two mandatory properties: Latitude and Longitude - Only degrees and decimal fractions Q: Is time required? A: No. Still flexible: - arbitrary precision - other optional parameters: altitude time accuracy (horizontal, vertical, temporal) Out of scope: - directions and orientation (2D? 3D?) - speed - mass - acceleration - temperature What next? Correct altitude terminology - height above datum vs. MSL Is this sufficient for default SLoP format? C: This is close to some existing formats Q: Design is good. But should look at some existing RFC. Have you check checked RFC 1876? C: like Loc RR same format. Separate data representation separated from protocol - Specify a generic way of expressing location information C: It would be shame if this is considered only in SLoP. A: I want it be included to others (http, impp ...). Q: Is it useful to take DNS location block ? C: Not to tie this format too closely to SLoP. Q: You mentioned to use wgs84 but not UTP? A: No, use realtime. Q: XML contains some datum presentation A: There is a list for "future" (non phase 1) SLoP issues Target Naming Scheme by Haitao Tang (draft-tang-spatial-target-00.txt) This is an individual contribution. - Two basic concepts: TAD - Target record Accessing ID This contains target record name and server info TID - Target information ID Contains target profile and owner/server profile - Usage of TIDs and TADs When target is associated to the server, home server contains TAD and TID. When target moves to visiting server, the new server allocates a new TAD that is bound to home server. - Benefits: Easier to setup target-server association Support target roaming among servers Support anonymity Carry more information - Need of Character-Set indicator to tell what character-set is used for a URI of the target. UTF-8 is the default. C: Character-set indicator is good idea. This naming scheme has feeling of killing NAT. This is more than needed for SLoP. This is complicated. Only subset is needed. A: This (TID) may be left out of Phase 1, including Roaming issue. C: This makes SLoP too complicated, especially when the idea of SLoP was to keep things simple. Q: looks like the presence protocol ... Could this be converged? C: SLoP should be a little bit careful with this naming scheme. Basic SLoP Architectural Considerations by John Loughney (draft-loughney-spatial-arch-00.txt) Serves as input for future architectural IDs - Why? Spatial location is an interesting parameter Lots of potential services can be enabled Basic Assumptions - the way how server learns the position is out of scope - one format is used - format translation out of scope (initially) Broker architecture is going to be needed since the number of SLoP servers may be huge. Broker is positioned between client and server(s) - SLoP server proxying SLoP is a protocol between SLoP client/server and transport layer - Security issues: Underlying security support (IPSec ) Hop by hop security Secure proxying - useful but needs studying Payload encryption - define standard encryption method What to do next? - security architecture needs a lot of work - add section on basic assumptions - add section on SLOP proxying - rework roaming support - policy architecture section Future study - Roaming study - broker study - Server discovery - Authentication support - Architecture for pushing location Q: There are a number of protocols that do all this. This should be taken a look at. A: Yes. Good idea. Louis Hecht, OGC consortium OGC's Comments: - Architecture is well suited for OGC - This evening suggests that the scope should be limited - Geographic side is not concentrated well enough - focus on fixed target - consider descriptive locations things - Mobile target is going to be difficult - OGC can bring technology for testbed - New consortium is formed - WGS84 is not going to work everywhere (this is political issue) C: WGS84 does not work in a large ship. A: Abstract locations are for later phase Charter Bashing (James Polk) Seven focus areas within current charter Spatial location representations - need for single Absolute Location System - provisions for new formats should be considered C: There are a wide variety of location usage. Location info is useful, http, impp, existing protocols may use it. C: Focus on how the location info is represented and handled. C: Take some of the hard problems out, but also use existing solutions. Q: Accuracy vs. datum? A: This should be discussed. Q: Do we need spatial location but not protocol? A: WG aspect is the representation. Range of problems are out of the scope of existing WGs. E.g., where is the nearest pizza shop. A: Disagreement about the problem: IMPP people think that this is a subset of IMPP. C: IMPP's network presence has fundamental difference from spatial location. C: Mobile Internet needs location mechanisms for management. This must be done by IETF soon. C: DNS is not suitable as such. C: Problem is more specialized and generalized ! Q: Not good to have almost similar protocols for almost similar problems. Q: No clear problem defined. The group has not focused yet. So, explain what the problem is and to make people understand what we want to do. A: Mailing list has been up a long time. A: In the first BOF quite good definition of problems. A lot of work done then. Time in this BOF has been spent by comparing existing protocols to SLoP. But it is not the basic idea. A: In just this short time, a few people rised the "payload" and "protocol". We have not heard in the comments to the BOF list. C: We seem to have lots of good reasons for somebody in IETF to worry about location. Q: Three big problems/questions addressed in BOF. Go just down to one? C: Split the transport and representation issues of the charter. Take naming, privacy... away. C: Specify a payload first and check what protocol(s) are suitable. C: Deal with payload issues first, and look for the existing protocol(s) second... Q: If we cannot find suitable protocol, then what to do? A: Select an existing protocol and make possibly extensions to suit for the payload. Q: How Patrik feels? A: Rephrase a bit the charter according to this. More specific problem statement is needed. Request: Those support the splitting show your hands please. C: Most support the splitting. Request: Those against the splitting show your hands please. C: It seems no one against the splitting. C: Good, we separate spatial location payload from transport parts. Focus on the payload first. Then, investigate and try to use existing transport protocols. The BOF consensus: - The group will focus on spatial location payload (spatial location representations, etc.) and the issues related to it - The charter will be developed to scope the group's focus on the issues of and related to spatial location payload - the group is to apply for WG status with the developed charter. Meeting closed.