Spatial Location Protocol Location Server Authentication draft-polk-slp-loc-auth-server-00.txt James M. Polk (Co-Chair) March 30th, 2000

Basic premise of I-D Early considerations for a Spatial Location Server and issues that will need to be addressed when an IP Device that has determined its location requests, or is requested, to provide that information to a Spatial Location Server (SLS)

Mechanisms of the Spatial Location Server First - Spatial Location Server (SLS) MUST determine its own location based on the SLOP Protocol Need for Authentication Server, similar to a Security Server, should be within the Network Domain of an SLS Server in order to authenticate to that Domain SLS infrastructure could become a combination of Hierarchical and Peering in communications to other SLS Server (similar to a Certificate Authority Network) IPsec likely should become the communications method between SLS Servers regardless of Hierarchical or Peering in relationship within the Network

Location Possibilities The following is an early potential list, in no particular order and easily a subset of the possibilities, of coordinate mechanisms/values: –X, Y, Z –Long., Lat., Alt. –Planet, Country, State/Province, City/town, street, building, zip code, floor, quadrant of floor, office/cube number –To geographic area like a floor, part of a floor, a building a city ()

Additional Considerations for SLP Location representation Known additional or replacement identification information could include: Relation to directly attached L2 Switch/Router Relative or absolute location to any of the above items Perhaps a remote site relative to a Corporate site Residence or Company name