July 2006 IETF66 - ECRIT 1

RELO: Retrieving End System Location Information

draft-schulzrinne-geopriv-relo-00

Henning Schulzrinne

July 2006 IETF66 - ECRIT 2

Motivation

• Layer-7 mapping of identifier to location– typically network termination equipment

• DSL modem, 802.11 AP

• Work behind NAT

• Narrowly-focused protocol -- one purpose– make it easier to specify interoperability

• Since just mapping, could map SNR measurements to location…

July 2006 IETF66 - ECRIT 3

Discovery

• Currently, S-NAPTR– should probably be U-NAPTR– domain from host configuration (DHCP) or

reverse DNS

July 2006 IETF66 - ECRIT 4

Query

• Just send HTTP GET– TLS RECOMMENDED

• Could also use GET parameters, as in– http://example.com?

by=value&type=civic

<?xml version="1.0" encoding="UTF-8"?> <get-location by="value" type="civic” />

July 2006 IETF66 - ECRIT 5

Response

• Returns location object or URI:– <returnURI><URI>sip:155yojglky@example.com</URI></returnURI>

• Uses HTTP Expires header to indicate validity• If error, use HTTP response• To subscribe to location, insert Subscribe HTTP

header (and maybe Event)– see SIP configuration framework for HTTP Event

header

July 2006 IETF66 - ECRIT 6

Design decisions

• No notion of context -- stateless– no need for state maintenance

• Just location, no PIDF-LO– avoid having to obscure privacy-sensitive information such as entity

URL

• First-party retrieval (mainly)– reduce privacy risks

• Specify discovery mechanism– use S-NAPTR (or U-NAPTR) via host name

• Allow other identifiers– but only IP address specified until others are better understood

• Uses HTTP error codes, rather than define own• Subscribe URL in response header

– separate discussion (tactical and technical)

July 2006 IETF66 - ECRIT 7

Open issues

• What other identifiers?– must survive NAT and home routers

• e.g., MAC address unlikely to be useful

– examples:• circuit ID• signal strength and AP MACs