Geopriv                                                  J. Winterbottom
Internet-Draft                                                M. Thomson
Intended status: Standards Track                      Andrew Corporation
Expires: May 7, 2009                                       H. Tschofenig
                                                  Nokia Siemens Networks
                                                               R. Barnes
                                                        BBN Technologies
                                                        November 3, 2008

                        HELD Identity Extensions

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May 7, 2009.

Winterbottom, et al.       Expires May 7, 2009                  [Page 1]

Internet-Draft                HELD Identity                November 2008


   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 arriving message as a pointer to the location
   determination process.  This is sufficient in environments where an
   Target's location can be determined based on its IP address.

   Two additional use cases are addresses by this document.  In the
   first, the source IP address in the request is not the only
   identifier for the Target.  In the second, an entity other than the
   Target requests the Target's location.

   This document extends the HELD protocol to allow the location request
   message to carry additional identifiers assisting the location
   determination process.  It defines a set of URIs for Target
   identifiers and an XML containment schema.  This extension is used in
   conjunction with HELD to provide Target identification, and set of
   criteria of when to use this extensions are provided.  Examples and
   usage in HELD message syntax are also shown.

Winterbottom, et al.       Expires May 7, 2009                  [Page 2]

Internet-Draft                HELD Identity                November 2008

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Identity Extension Details . . . . . . . . . . . . . . . . . .  6
     3.1.  URI Definitions  . . . . . . . . . . . . . . . . . . . . .  6
       3.1.1.  MAC Address URI  . . . . . . . . . . . . . . . . . . .  6
       3.1.2.  IP Address URIs  . . . . . . . . . . . . . . . . . . .  6
     3.2.  Schema . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
     5.1.  Location Configuration Protocol Requests . . . . . . . . . 12
     5.2.  Third Party Requests . . . . . . . . . . . . . . . . . . . 12
     5.3.  Distinguishing LCP Requests from Third Party Requests  . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     6.1.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 14
     6.2.  XML Schema Registration  . . . . . . . . . . . . . . . . . 14
     6.3.  Identifier 'type' Attribute values . . . . . . . . . . . . 15
     6.4.  URI Type Attribute Values  . . . . . . . . . . . . . . . . 15
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     8.1.  Normative references . . . . . . . . . . . . . . . . . . . 18
     8.2.  Informative references . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 21

Winterbottom, et al.       Expires May 7, 2009                  [Page 3]

Internet-Draft                HELD Identity                November 2008

1.  Introduction

   Protocols for requesting and providing location information require a
   way for the requestor to specify the location that should be
   returned.  In a location configuration protocol (LCP), the location
   being requested is the requestor's location.  This fact can make the
   problem of identifying the Target simpler for LCPs, since IP
   datagrams that carry the request already carry an identifier for the
   Target, namely the source IP address of an incoming request.
   Existing LCPs, such as HELD [I-D.ietf-geopriv-http-location-delivery]
   and DHCP ([RFC3825], [RFC4776]) rely on the source IP address, and
   possibly lower-layer identifiers to identify a Target.

   Aside from the datagrams that form a request, a location information
   server (LIS) does not necessarily have access to information that
   could further identify the Target of the request.  In some
   circumstances, as shown in [I-D.ietf-geopriv-l7-lcp-ps], additional
   identification information can be included in a request to identify a

   This document extends the HELD protocol to support the inclusion of
   additional identifiers for the Target in HELD location requests.  The
   identifiers are defined as URIs that include a range of different
   types of identification information.  Finally, an XML schema is
   defined that provides a structure for including these identifiers in
   HELD requests.

   An important characteristic of this addition to the HELD protocol is
   that is also expands the potential scope of HELD beyond that of an
   LCP.  The scope of an LCP is limited to the interaction between a
   Target and a LIS.  That is, an LCP is limited to the Target
   retrieving information about their own location.  With this addition,
   third party location recipients (LRs) are able to make requests that
   include identifiers to retrieve location information about a
   particular Target.

   The usage of HELD for purposes beyond the Target-LIS interaction
   obviously introduces a new set of privacy concerns.  In an LCP, the
   requester is implicitly authorized to access the request location
   information, because it is their own location.  In contrast, when a
   third party LR requests a Target's location, the LR MUST be
   explicitly authorized.  Establishing appropriate authorization and
   other related privacy concerns are discussed in Section 4.

Winterbottom, et al.       Expires May 7, 2009                  [Page 4]

Internet-Draft                HELD Identity                November 2008

2.  Terminology

   This document reuses the term Target, as defined in [RFC3693].

   This document uses the term Location Information Server, LIS as
   described in [I-D.ietf-geopriv-l7-lcp-ps].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

Winterbottom, et al.       Expires May 7, 2009                  [Page 5]

Internet-Draft                HELD Identity                November 2008

3.  Identity Extension Details

   This section defines the details of the schema extension for HELD to
   support the inclusion of a Target identity in the form of a URI or
   typed-token.  A set of URI definitions that can be used to specify
   these identities is also provided.

3.1.  URI Definitions

   The URIs defined in this section are designed to identify a Target;
   they do not identify measurements or sighting data associated with a
   Target, such as the switch and port information to which the Target
   is attached.  This information may, for example, be acquired using
   DHCP relay information [RFC3046] or LLDP [LLDP].  Device measurements
   and sighting data are described in
   [I-D.thomson-geopriv-held-measurements].  The identity provided may
   be transitory, such as an IP address that is leased from a DHCP
   server pool.

   The URIs in the following sub-sections are defined using ABNF
   (augmented Backus-Naur form) described in [RFC2234].

3.1.1.  MAC Address URI

   A MAC URI represents the media access control address of the Device,
   as defined in the IEEE 802 series of specifications.  The ABNF for
   this URI type is defined as:

   mac-uri = "mac:" 2*2HEXDIG 5*5macdig
   macdig = "-" 2*2HEXDIG

   MAC URIs can be used in the same manner as is suggested by the
   undefined "mac:" URIs used in examples in RFC 4479 [RFC4479].  An
   example of its use is provided in Figure 3.

3.1.2.  IP Address URIs

   This section provides the ABNF for IP version 4 and IP version 6
   URIs.  One application of this URI scheme is described in
   [I-D.ietf-geopriv-l7-lcp-ps], where an outbound SIP proxy needs to
   make location requests to a LIS on behalf of a Target because, for
   some reason, the necessary information was not provided by the

   ip-uri = "ip:" ipv4 / ipv6
   ipv4 = "IPv4+" IPv4address    ; from RFC 3986
   ipv6 = "IPv6+" IPv6address    ; from RFC 3986

Winterbottom, et al.       Expires May 7, 2009                  [Page 6]

Internet-Draft                HELD Identity                November 2008

   The definitions for "IPv4address" and "IPv6address" are taken from

   An example of a location request including a URI in this form to
   identify the Target device is shown in Figure 1.

        xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="8000">
   <deviceIdentity xmlns="urn:ietf:params:xml:ns:geopriv:held:id">

            Figure 1: HELD Location Request Using an IP Address

   Note that the URI types are not case sensitive and the iP:ipv4+ is still a valid URI.

3.2.  Schema

   This section defines a schema that is used to provide Target
   identifiers in a HELD location request.

Winterbottom, et al.       Expires May 7, 2009                  [Page 7]

Internet-Draft                HELD Identity                November 2008

   <?xml version="1.0"?>
   elementFormDefault="qualified" attributeFormDefault="unqualified">

     <!-- typedURI definition -->

     <xs:complexType name="typedURI">
         <xs:extension base="xs:anyURI">
           <xs:attribute name="type" type="xs:token"

     <!-- typedToken definition -->

     <xs:complexType name="typedToken">
         <xs:extension base="xs:token">
           <xs:attribute name="type" type="xs:token"

     <!-- Identity Parameters -->

     <xs:complexType name="idParameters">
         <xs:element name="uri" type="heldDI:typedURI"
                     minOccurs="0" maxOccurs="unbounded"/>
         <xs:element name="identifier" type="heldDI:typedToken"
                     minOccurs="0" maxOccurs="unbounded"/>

     <xs:element name="deviceIdentity" type="heldDI:idParameters"/>


                             Figure 2: Schema

Winterbottom, et al.       Expires May 7, 2009                  [Page 8]

Internet-Draft                HELD Identity                November 2008

   The schema provided in Figure 2 allows a URI and/or token to be
   provided so that a Target can identify itself by more than just its
   IP address.  The URI can also include an optional "type" attribute so
   that URIs that might otherwise look the same can be distinguished
   based on their usage.

   For example <uri type="gruu"></uri> or <uri

   An IANA registry is established for defining uri token types, and
   this defined in Section 6.4.

   When the <identifier> element is used the "type" attribute is
   mandatory as it tells the LIS or receiving entity how to interpret
   the identifier.  An IANA registry is established for the central
   repository for recognized identifier types.  The set of initial types
   is provided in Section 6.3.

   A HELD location request sent by a device using the schema shown in
   Figure 2 to provide its identity as a MAC URI would look similar to
   Figure 3.

   <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
     <deviceIdentity xmlns="urn:ietf:params:xml:ns:geopriv:held:id">

                Figure 3: HELD Location Request URI example

   Similarly a Target identifying itself using its DHCP client
   identifier (DHCP option 61 in [RFC2132]) in a location request to a
   LIS would send something similar to Figure 4.

   <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
     <deviceIdentity xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
       <identifier type="dhcpClientId">035552764</identifier>

            Figure 4: HELD Location Request Identifier example

Winterbottom, et al.       Expires May 7, 2009                  [Page 9]

Internet-Draft                HELD Identity                November 2008

4.  Privacy Considerations

   A location configuration protocol has a very simple privacy model.
   Because the requester is also the Target, it can be assumed that
   providing that requester with location information is allowed.  Such
   a policy makes the simple assumption that as the subject of the
   location information, the Target is also permitted access to that
   information.  In effect, an LCP server (that is, the LIS) follows a
   single rule policy that states that the Target is the only authorized
   Location Recipient.

   Note:  HELD explicitly takes the position that the Target is a Device
      and not a person.  For the purpose of the discussion in this
      section, the two are considered one and the same.

   When the identity extensions defined above are used by the Target to
   augment an LCP query, this default "LCP policy" remains the relevant
   policy, and the security and privacy considerations of the base HELD
   protocol [I-D.ietf-geopriv-http-location-delivery] apply.  The only
   augmentation required is that if the LCP policy is to be applied, the
   LIS MUST authenticate that the requested identity is in fact that of
   the requestor, and MUST deny access to location if this
   authentication fails.

   The LCP policy does not allow requests made by third parties.  If a
   LIS permits requests from third parties using identity extensions, it
   assumes the rule of a Location Server (LS).  HELD becomes a more
   general location request protocol--a "using protocol" by the
   definitions in [RFC3693]--and the privacy considerations for using
   protocols apply.  As a Location Server, the LIS MUST explicitly
   authorize requests according to the policies that are provided by
   Rule Makers, including the Target.  This includes authentication of
   requesters where required by the authorization policies.

   An organization that provides a LIS that allows third party requests
   SHOULD provide a means for a Rule Maker to specify authorization
   policies before allowing third party requests for that Target's
   location.  Until an authorization policy is established, the LIS MUST
   reject requests by third parties.

   For a network operator, authorization might be a manual process, an
   explicit part of the terms of service for the network, or an
   automated system that accepts formal authorization policies (see
   [RFC4745], [RFC4825]).  This document does not mandate any particular
   mechanism for establishing an authorization policy.

   When the LIS is operated by the Target's access network, the
   relationship between the Target and the LIS can be transient.

Winterbottom, et al.       Expires May 7, 2009                 [Page 10]

Internet-Draft                HELD Identity                November 2008

   However, the process of establishing network access usually results
   in a form of agreement between the Target and the network provider.
   This process offers a natural vehicle for establishing location
   privacy policies.

Winterbottom, et al.       Expires May 7, 2009                 [Page 11]

Internet-Draft                HELD Identity                November 2008

5.  Security Considerations

   The security considerations in
   [I-D.ietf-geopriv-http-location-delivery] describe the use of TLS for
   server authentication, confidentiality and protection from
   modification.  These protections apply to both LCP requests and the
   requests made by third parties.

5.1.  Location Configuration Protocol Requests

   Requests made by a Device (or Target) in the context of a location
   configuration protocol are covered by the same set of protections
   offered by HELD.  All the security considerations for HELD apply.

   Identity information provided by the Device is private data that
   might be sensitive.  The Device provides this information in the
   expectation that it assists the LIS in providing the Device a
   service.  The LIS MUST NOT use identity information for any other
   purpose other than serving the request that includes that

   Falsification of identification information could be used by
   malicious Devices to gain access to location information for others,
   or to acquire false location information.  For location
   configuration, the LIS MUST ensure that claimed identity information
   belongs to the requester before relying upon it.  If this
   verification cannot be performed, the LIS MUST treat the request as
   if it were a third party request.

   Note:  This might seem to negate much of the advantage provided by
      the inclusion of identity parameters for the LCP case.  However,
      checking that the identity information is correct is generally
      more feasible than acquiring the information in the first place.

   For example, a MAC address provided by a target device can be
   verified by performing a DHCP lease-query ([RFC4388]).  Identity
   extensions such as tel: URIs and hostnames can be validated using
   network services such as the DNS, ENUM, LDAP and SIP registrars.

5.2.  Third Party Requests

   Requests from third parties have the same requirements for server
   authentication, confidentiality and protection from modification as
   LCP requests.  However, because the third party needs to be
   authorized, the requester MUST be authenticated by the LIS.  The LIS
   MUST NOT provide location information to unauthorized requesters.

   A LIS that allows requests from third parties MUST support TLS client

Winterbottom, et al.       Expires May 7, 2009                 [Page 12]

Internet-Draft                HELD Identity                November 2008


   More detail on the privacy implications of third party requests are
   covered in Section 4.

5.3.  Distinguishing LCP Requests from Third Party Requests

   There is a risk that a LIS that supports both LCP requests as well as
   requests from third parties could leak information.  To successfully
   exploit this leak, a third party could convince the server that its
   request is an LCP request and that the identity information it
   provides indeed belongs to it.  This could mean that the third party
   is exempted from the mandatory authorization process.

   A LIS that only provides LCP access to Targets is subject to the same
   attack.  If a Target can provide false identification information
   that is accepted by the LIS, it can effectively act as an authorized
   third party.

   This is limited by the ability of the LIS to detect falsified
   identity information.  Implementations need to take care to verify
   identity information as described in Section 5.1.

   For all requests, the LIS MUST ensure that the requester is
   authorized to receive location information for the specified Target
   before providing that information.

Winterbottom, et al.       Expires May 7, 2009                 [Page 13]

Internet-Draft                HELD Identity                November 2008

6.  IANA Considerations

   This document registers an XML namespace and schema with IANA in
   accordance with guidelines in [RFC3688].  It also creates a new
   registry for device identity types, and stipulates how new types are
   to be added.

6.1.  URN Sub-Namespace Registration for

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in

      URI: urn:ietf:params:xml:ns:geopriv:held:id

      Registrant Contact: IETF, GEOPRIV working group,
      (, James Winterbottom


         <?xml version="1.0"?>
         <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
         <html xmlns="" xml:lang="en">
             <title>HELD Device Identity Extensions</title>
             <h1>Namespace for HELD Device Identity Extensions</h1>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
       with the RFC number for this specification.]]
             <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>

6.2.  XML Schema Registration

   This section registers an XML schema as per the guidelines in

Winterbottom, et al.       Expires May 7, 2009                 [Page 14]

Internet-Draft                HELD Identity                November 2008

   URI:  urn:ietf:params:xml:schema:geopriv:held:id

   Registrant Contact:  IETF, GEOPRIV working group, (,
      James Winterbottom (

   Schema:  The XML for this schema can be found as the entirety of
      Figure 2 of this document.

6.3.  Identifier 'type' Attribute values

   This document requests that the IANA create a new registry for
   identifier 'type' attribute values.  These are text strings that
   clarify how the value identifies the Device.  Referring to [RFC2434]
   this registry operates under the "Expert Review" rule.

   The following identifier types are registered as part of this memo:

   dhcpClientId:  The DHCP client identifier as defined by DHCP option
      61 in [RFC2132]

   msisdn:  The Mobile Station International Subscriber Dial Number.
      This is an E.164 number made up of 6 to 15 digits

   imsi:  The International Mobile Subscriber identifier.  A unique
      identifier for GSM or UMTS mobile terminal made up of 6 to 15
      digits that identify the country code, the network code and

   imei:  The International Mobile Equipment identifier.  This is an
      electronic serial number for a mobile device and is consists of up
      to 15 digits

   min:  Mobile Identification Number.  A unique equipment identifier
      assigned to CDMA handsets.

   mdn:  Mobile Dial Number.  An E.164 number made up of 6 to 15 digits.

   hostname:  The hostname or FQDN of the device.

   directoryNumber:  The directory number of the device.

6.4.  URI Type Attribute Values

   This document requests that the IANA create a new registry for uri
   'type' attribute values.  These are text strings that clarify what a
   URI actually identifies, and MUSt include the URI scheme to which the
   type applies.  Referring to [RFC2434] this registry operates under
   the "Expert Review" rule.

Winterbottom, et al.       Expires May 7, 2009                 [Page 15]

Internet-Draft                HELD Identity                November 2008

   The following identifier types are registered as part of this memo:

   aor:  The SIP address of record as defined [RFC3261].  Applies to
      'sip:', 'sips:', 'pres:'

   gruu:  The Globally Routable User Agent URI (GRUU) as defined in
      [I-D.ietf-sip-gruu].  Applies to 'sip:', 'sips:'

Winterbottom, et al.       Expires May 7, 2009                 [Page 16]

Internet-Draft                HELD Identity                November 2008

7.  Acknowledgements

   The authors wish to thank the NENA VoIP location working group for
   their assistance in the definition of the schema used in this
   document.  Special thanks go to Barbara Stark, Guy Caron, Nadine
   Abbott, Jerome Grenier and Martin Dawson.  Thanks also to Bob Sherry
   for requesting that URI-types be supported which led to the typedURI
   form.  Thanks to Adam Muhlbauer and Eddy Corbett for providing
   further corrections.

Winterbottom, et al.       Expires May 7, 2009                 [Page 17]

Internet-Draft                HELD Identity                November 2008

8.  References

8.1.  Normative references

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

              Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
              "HTTP Enabled Location Delivery (HELD)",
              draft-ietf-geopriv-http-location-delivery-10 (work in
              progress), October 2008.

              Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
              Location Configuration Protocol; Problem Statement and
              Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
              progress), June 2008.

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

              Rosenberg, J., "Obtaining and Using Globally Routable User
              Agent (UA) URIs (GRUU) in the  Session Initiation Protocol
              (SIP)", draft-ietf-sip-gruu-15 (work in progress),
              October 2007.

8.2.  Informative references

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
              J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

Winterbottom, et al.       Expires May 7, 2009                 [Page 18]

Internet-Draft                HELD Identity                November 2008

              Rosen, B. and J. Polk, "Best Current Practice for
              Communications Services in support of Emergency  Calling",
              draft-ietf-ecrit-phonebcp-05 (work in progress),
              July 2008.

              Thomson, M. and J. Winterbottom, "Using Device-provided
              Location-Related Measurements in Location  Configuration
              Protocols", draft-thomson-geopriv-held-measurements-03
              (work in progress), October 2008.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [LLDP]     IEEE, "802.1AB, IEEE Standard for Local and Metropolitan
              area networks, Station and Media Access Control
              Connectivity Discovery", June 2005.

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, January 2001.

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
              RFC 3966, December 2004.

   [RFC4479]  Rosenberg, J., "A Data Model for Presence", RFC 4479,
              July 2006.

   [RFC4388]  Woundy, R. and K. Kinnear, "Dynamic Host Configuration
              Protocol (DHCP) Leasequery", RFC 4388, February 2006.

   [RFC3825]  Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
              Configuration Protocol Option for Coordinate-based
              Location Configuration Information", RFC 3825, July 2004.

   [RFC4825]  Rosenberg, J., "The Extensible Markup Language (XML)
              Configuration Access Protocol (XCAP)", RFC 4825, May 2007.

   [RFC4745]  Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
              Polk, J., and J. Rosenberg, "Common Policy: A Document
              Format for Expressing Privacy Preferences", RFC 4745,
              February 2007.

   [RFC4776]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic Addresses
              Configuration Information", RFC 4776, November 2006.

Winterbottom, et al.       Expires May 7, 2009                 [Page 19]

Internet-Draft                HELD Identity                November 2008

Authors' Addresses

   James Winterbottom
   Andrew Corporation
   PO Box U40
   University of Wollongong, NSW  2500


   Martin Thomson
   Andrew Corporation
   PO Box U40
   University of Wollongong, NSW  2500


   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600

   Phone: +358 (50) 4871445

   Richard Barnes
   BBN Technologies
   9861 Broken Land Pkwy, Suite 400
   Columbia, MD  21046

   Phone: +1 410 290 6169

Winterbottom, et al.       Expires May 7, 2009                 [Page 20]

Internet-Draft                HELD Identity                November 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Winterbottom, et al.       Expires May 7, 2009                 [Page 21]