Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
RFC 6155

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>,
    geopriv mailing list <geopriv@ietf.org>,
    geopriv chair <geopriv-chairs@tools.ietf.org>
Subject: Protocol Action: 'Use of Device Identity in HTTP-Enabled Location Delivery (HELD)' to Proposed Standard (draft-ietf-geopriv-held-identity-extensions-06.txt)

The IESG has approved the following document:
- 'Use of Device Identity in HTTP-Enabled Location Delivery (HELD)'
  (draft-ietf-geopriv-held-identity-extensions-06.txt) as a Proposed
Standard

This document is the product of the Geographic Location/Privacy Working
Group.

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-geopriv-held-identity-extensions/

Technical Summary

When a Location Information Server receives a request for location
information (using the locationRequest message), described in the base
HTTP Enabled Location Delivery (HELD) specification, it uses the
source IP address of the arriving message as a pointer to the location
determination process. Two additional use cases are addressed by this
document. In the first, location configuration requires additional or
alternative identifiers from the source IP address provided in the
request. In the second, an entity other than the Device requests the
location of the Device.

Working Group Summary

This document has been discussed at length within the working group,
with a particular focus on security and privacy. There is WG consensus
that this document describes an important piece of the HELD
architecture and that it has addressed concerns raised previously.

Document Quality

The HELD extensions described in this document are simple to read and
understand. Multiple revisions of this document have made for a
straightforward but comprehensive discussion of relevant security and
privacy issues. 

Personnel

Alissa Cooper is the document shepherd. Robert Sparks is the responsible AD.

RFC Editor Note 
(applies to version -06)

Section 2, ADD section:
2.1.3.  Network Interfaces and Devices

  Several of the identifiers in this document are used to identify a
  network interface.  A Device can have multiple network interfaces.
  Uniquely identifying any network interface is assumed to be
  sufficient to identify the Device.  When a network interface is
  identified, the goal is to identify the Device that is immediately
  attached to the network interface.

  Most network interfaces remain physically attached to a particular
  Device, though a network interface might be physically separable from
  the Device.  By identifying a network interface, any Device that is
  intended to be identified could change.

Section 3.1, first paragraph, OLD:
  [...] The textual format for IP	
  version 4 and version 6 addresses MUST conform to the grammar defined
  in [RFC3986] ("IPv4address" and "IPv6address" respectively).
NEW (new sentence):
  [...] The textual format for IP	
  version 4 and version 6 addresses MUST conform to the grammar defined	
  in [RFC3986] ("IPv4address" and "IPv6address" respectively). IP	
  version 6 addresses SHOULD conform to the formatting conventions in	
  [RFC5952].

Section 3.2, first paragraph, OLD:
  The media access control (MAC) address used by the IEEE 802 family of
  access technologies is an identifier that is assigned to a particular
  network Device.  A MAC address is a unique sequence that is either
  assigned at the time of manufacture of a Device, or assigned by a
  local administrator.  A MAC address rarely changes; therefore, a MAC
  address is an appropriate identifier for a Device.
NEW:
  The media access control (MAC) address used by network interfaces
  attached to the IEEE LAN [IEEE802].  A MAC address is a unique
  sequence that is either assigned at the time of manufacture of the
  interface, or assigned by a local administrator.  A MAC address is an
  appropriate identifier for the Device that uses the network
  interface as long as the two remain together (see Section 2.1.3).

Section 3.7, imsi, OLD:
  imsi: The International Mobile Subscriber Identity (IMSI)
     [TS.3GPP.23.003] an identifier associated with all GSM and UMTS
     mobile subscribers.
NEW:
  imsi: The International Mobile Subscriber Identity (IMSI)
     [TS.3GPP.23.003] an identifier associated with all GSM and UMTS
     mobile subscribers between 6 and 15 digits in length.

Section 3.7, min, OLD:
  min: The Mobile Identification Number (MIN) [TIA.EIA.IS-2000-6] is a
     unique number assigned to CDMA handsets.
NEW:
  min: The Mobile Identification Number (MIN) [TIA.EIA.IS-2000-6] is a
     10 digit unique number assigned to CDMA handsets.

Section 5, OLD:
     Note that HELD [RFC5985] does not mandate that Devices implement
     authentication. A LIS SHOULD NOT send a HTTP 401 response if the
     Device does not include Device identity.
NEW (note loss of indentation):
  HELD [RFC5985] does not mandate that Devices implement
  authentication. A LIS SHOULD NOT send a HTTP 401 response if the
  Device does not include Device identity.

NEW Reference:
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
         Address Text Representation", RFC 5952, August 2010.