Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information
RFC 4676

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: 'Dynamic Host Configuration Protocol 
         (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 
         Information' to Proposed Standard 

The IESG has approved the following document:

- 'Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for 
   Civic Addresses Configuration Information '
   <draft-ietf-geopriv-dhcp-civil-10.txt> as a Proposed Standard

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

The IESG contact persons are Ted Hardie and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-10.txt

Technical Summary
 
This document specifies a Dynamic Host Configuration Protocol (DHCPv4
 and DHCPv6) option containing the civic location of the client or the
 DHCP server.  The Location Configuration Information (LCI) includes
 information about the country, administrative units such as states,
 provinces and cities, as well as street addresses, postal community
 names and building information.  The option allows multiple
 renditions of the same address in different scripts and languages.
 Geolocation data is carried in another option, specified in RFC 3825.

 
Working Group Summary
 
The working group came to consensus on this document.  There was
a Last Call comment raised asking for clarification of whether this
option would ever be sent from host to server; this was discussed
at the GEOPRIV interim meeting and this document reflect the agreed
resolution.

 
Protocol Quality
 
This document was reviewed according to the PROTO process and
the write-up submitted by Andy Newton; it was reviewed for the IESG by Ted
Hardie.

RFC Editor Note
 
In Section 2.

OLD

   A related document [18] describes a DHCPv4 [2] option for conveying
   geospatial information to a device.  This draft describes how DHCPv4
   and DHCPv6 [6] can be used to convey the civic and postal address to
   devices.  Both geospatial and civic formats be used simultaneously,
   increasing the chance to deliver accurate and timely location
   information to emergency responders.
 

NEW

   A related document [18] describes a DHCPv4 [2] option for conveying
   geospatial information to a device.  This draft describes how DHCPv4
   and DHCPv6 [6] can be used to convey the civic and postal address to
   devices.  Both geospatial and civic formats be used simultaneously,
   increasing the chance to deliver accurate and timely location
   information to emergency responders. The reader should also be familiar
   with the concepts in [14], as many of the protocol elements below are
   designed to dovetail with PIDF-LO elements.

In Section 2 

OLD:

       After initial location information has been introduced, it MUST be
      afforded the protections defined in RFC 3694 [12].  Therefore,
      location information SHOULD NOT be sent from a DHCP client to a DHCP
      server.  If a client decides to send location information to the 
       server, it is implicitly granting that server unlimited retention and
       distribution permissions.

NEW:
      Further discussion of the protections which must be provided according
      to RFC 3694 [12] are in the Security Considerations (Section 6).    
    

In Section 3.4
OLD:

  STS: STS designates a street suffix or type.  In the United States
      (US), the abbreviations recommended by the United States Postal
      Service Publication 28 [20], Appendix C, SHOULD be used.

HNS: HNS ("house number") is a modifier to a street address; it does
      not identify parts of a street address.

NEW:

STS: STS designates a street suffix or type.  In the United States
      (US), the abbreviations recommended by the United States Postal
      Service Publication 28 [20], Appendix C, SHOULD be used.

OLD:
 LMK: While a landmark (LMK, CAtype 21) can indicate a complex of
      buildings, 'building' (CAtype 25) conveys the name of a single
      building if the street address includes more than one building or
      the building name is helpful in identifying the location. 

NEW:
 building: While a landmark (LMK, CAtype 21) can indicate a complex of
      buildings, 'building' (CAtype 25) conveys the name of a single
      building if the street address includes more than one building or
      if the building name is helpful in identifying the location. 

In Section 6

OLD:
   To minimize the unintended exposure of location information, the
   GEOCONF_CIVIC option SHOULD be returned by DHCPv4 servers only when
   the DHCPv4 client has included this option in its 'parameter request
   list' (RFC 2131 [2], Section 3.5).  Similarly, the
   OPTION_GEOCONF_CIVIC option SHOULD be returned by DHCPv6 servers only
   when the DHCPv6 client has included this option in its OPTION_ORO.


NEW:

   To minimize the unintended exposure of location information, the
   GEOCONF_CIVIC option SHOULD be returned by DHCPv4 servers only when
   the DHCPv4 client has included this option in its 'parameter request
   list' (RFC 2131 [2], Section 3.5).  Similarly, the
   OPTION_GEOCONF_CIVIC option SHOULD be returned by DHCPv6 servers only
   when the DHCPv6 client has included this option in its OPTION_ORO.

    After initial location information has been introduced, it MUST be
    afforded the protections defined in RFC 3694 [12].  Therefore,
    location information SHOULD NOT be sent from a DHCP client to a DHCP
    server.  If a client decides to send location information to the 
    server, it is implicitly granting that server unlimited retention and
    distribution permissions.

 

In Section 3.1

OLD

 N: The length of this option is variable.  The minimum length is 3.

NEW

 N: The length of this option is variable.  The minimum length is 3 octets.

In Section 3.2

OLD

option-len: Length of the Countrycode, 'what' and civic address
      elements.

option-len: Length of the Countrycode, 'what' and civic address
      elements in octets

In Section 7.

OLD

  The initial list of registrations is contained in.

NEW

  The initial list of registrations is contained in Section 3.4.

OLD :

  This document calls for various operational decisions.  For example,
  an administrator has to decide when to provide the location of the
  DHCP server or other network elements even if these may be a good
  distance away from the client.  The administrator must also consider
  whether to include both civic and geospatial information if these may
  differ.  The document does not specify the criteria to be used in
  making these choices, as these choices are likely to depend strongly
  on local circumstances and need to be based on local, human
  knowledge

NEW:
 
  This document calls for various operational decisions.  For example,
  an administrator has to decide when to provide the location of the
  DHCP server or other network elements even if these may be a good
  distance away from the client.  The administrator must also consider
  whether to include both civic and geospatial information if these may
  differ.  The document does not specify the criteria to be used in
  making these choices, as these choices are likely to depend strongly
  on local circumstances and need to be based on local, human
  knowledge

  A system that works with location information configured by DHCP is
  dependent that the administrators of the DHCP systems are careful
  enough on a number of fronts, such as:

  - if information about one location is provided in multiple
    forms (e.g. in multiple languages), is it consistent?

  - is the administrator certain that location information
    is configured only to systems to which it applies (e.g.
    not to systems topologically near, but geographically far)?

  - if the location configured is not that of the target 
    but that of a 'nearby' network node or the DHCP server, 
    despite the recommendation against this practice in
    in Section 3.1, is the administrator certain that this
    configuration is geographically valid?

  There are many other considerations in ensuring that location
  information is handled safely and promptly for an emergency service in
  particular. Those are in the province of the applications which make
  use of the configured location information, and they are beyond the
  scope of this document. DHCP configuration SHOULD NOT be used for
  emergency services without guidelines on these considerations. Work on
  these is under way in the IETF ECRIT working group at the time of
  publication of this document.

OLD:
  If a network provides civic location information via both DHCPv4 and
  DHCPv6, the information conveyed by two protocols MUST be the same.

NEW:
  In addition, if a network provides civic location information via both DHCPv4
and
  DHCPv6, the information conveyed by two protocols MUST be the same.



Section 7

OLD:
   This document establishes a new IANA registry for CAtypes designating
   civic address components.  According to RFC 2434 [17], this registry
   operates under the "Specification Required" rules.
NEW:
   This document establishes a new IANA registry for CAtypes
   designating civic address components.  Referring to RFC 2434 [17],
   this registry operates under both "Expert Review" and
   "Specification Required" rules.  The IESG will appoint an Expert
   Reviewer who will advise IANA promptly on each request for a new or 
   updated CAtype.

3. 

Section 3.4  Civic Address Components

OLD:
Mappings and considerations for additional countries should be
written up in documents titled "Civic Addresses for [Country] (XY)",
where "XY" represents the two-letter country code, e.g., "Civic
Address Considerations for France (FR)".

NEW:
Mappings and considerations for additional countries may be
informally gathered from time to time by independent documents
which the IETF publishes which will have similar information to 
the examples given here.  These are non-normative, purely
descriptive, and do not purport to speak with authority for 
a country, but rather are offered as an informational base
which may provide others with benefit.  The use of a
country code to label a collection does not preclude its
reuse in a future collection.