Presentation is loading. Please wait.

Presentation is loading. Please wait.

RELO: Retrieving End System Location Information draft-schulzrinne-geopriv-relo-03 Henning Schulzrinne March 2007 IETF68 - GEOPRIV.

Similar presentations


Presentation on theme: "RELO: Retrieving End System Location Information draft-schulzrinne-geopriv-relo-03 Henning Schulzrinne March 2007 IETF68 - GEOPRIV."— Presentation transcript:

1 RELO: Retrieving End System Location Information draft-schulzrinne-geopriv-relo-03
Henning Schulzrinne March 2007 IETF68 - GEOPRIV

2 Motivation Layer-7 mapping of identifier to location
typically network termination equipment DSL modem, AP Believed to satisfy L7-LCP requirements Narrowly-focused protocol -- one purpose make it easier to specify interoperability Since just mapping, could map SNR measurements to location… March 2007 IETF68 - GEOPRIV

3 Discovery Currently, S-NAPTR should probably be U-NAPTR
domain from host configuration (DHCP) or reverse DNS March 2007 IETF68 - GEOPRIV

4 Query Just send HTTP GET Uses GET parameters, as in Parameters:
TLS RECOMMENDED Uses GET parameters, as in Parameters: by: value or reference within: time willing to wait type: civic or geo retransmission-allowed: yes/no retention-expiry: usage rule external-ruleset: usage rule note-well: usage rule url: URL to renew expires: LO/LR should expire secret: secret for modification assert: LO to store March 2007 IETF68 - GEOPRIV

5 Identifiers Default: IP address of request mac: MAC address
cdp: Cisco Discovery Protocol string msap: MAC service access point (LLDP) March 2007 IETF68 - GEOPRIV

6 OBO/... LIS-LIS just variants of LbyR
Operations OBO/... LIS-LIS just variants of LbyR Retrieval civic or geo, value or reference Renewal of reference lifetime provide URL and secret Assertion provide LO for storage and/or signature March 2007 IETF68 - GEOPRIV

7 Response Returns location object or URI (reference)
text/uri-list acceptable location types indicated by Accept header Uses HTTP Expires header to indicate validity If error, use HTTP response sufficient for error detection, with HTTP response body To subscribe to location, insert Subscribe HTTP header (and maybe Event) see SIP configuration framework for HTTP Event header March 2007 IETF68 - GEOPRIV

8 Design decisions No notion of context -- stateless
no need for state maintenance PIDF-LO (or any other future LO) First-party retrieval (mainly) reduce privacy risks Specify discovery mechanism -- see related draft use S-NAPTR (or U-NAPTR) via host name Allow other identifiers Uses HTTP error codes and status line, rather than define own Subscribe URL in response header separate discussion (tactical and technical) March 2007 IETF68 - GEOPRIV

9 Requirements L7-1: Identifier choice L7-2: Mobility choice
several, extensible L7-2: Mobility choice subscription or polling L7-3: Layer 7 and Layer 2/3 Provider Relationship none assumed L7-4: Layer 2 and Layer 3 Provider Relationship satisfied L7-5: Legacy devices March 2007 IETF68 - GEOPRIV

10 Requirements L7-6: VPN awareness L7-7: Network access authentication
prior to VPN attachment L7-7: Network access authentication none assumed L7-8: Network topology unawareness doesn’t care March 2007 IETF68 - GEOPRIV


Download ppt "RELO: Retrieving End System Location Information draft-schulzrinne-geopriv-relo-03 Henning Schulzrinne March 2007 IETF68 - GEOPRIV."

Similar presentations


Ads by Google