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-09.txt> as a Proposed Standard This document is the product of the Geographic Location/Privacy Working Group. The IESG contact person is Ted Hardie. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-09.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. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
