Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information
draft-ietf-geopriv-dhcp-lci-option-03

As a co-chair of the geopriv WG, I saw strong consensus of the WG (which seemed also to reflect a technical direction of the larger community) for the capability this spec provides, despite the fact that the confidentiality from the DHCP server to the client is not there and that the client provided with its location information by DHCP does not yet have specified geopriv location object privacy to protect the use from there on.  It is good that there is scrutiny of this issue, but I think there are two issues:  DHCP security is an ongoing issue for the IETF, not only geopriv's issue.  And uneven progress by WGs is temporary so support for the privacy of the location information by the user who has received it from DHCP under the present protocol is not far off.

Nits (can probablty be handled by RFC-Editor)
- missing IPR section

$ /bin/checkpage.awk < drafts/draft-ietf-geopriv-dhcp-lci-option-02.txt
Long page at 59
Long line at 120 with 152 chars
Bad chars at 235
-: 1 lines containing non-US-ASCII characters
-: 1 lines longer than 72 characters, max 152
-: 1 pages longer than 58 lines, max 853 lines

As a participant in the geopriv work, I remain troubled by the disparity between the security requirements we levy on the transmission of location information for "configuration purposes" versus those we levy on the use of geopriv objects over the Internet at large. I continue to fear that DHCP will be used to configure hosts in insecure environments with location information. However, I believe this solution represents a reasonable compromise between the pressing need to provide hosts with location information and the risks of the inadvertant disclosure of this information.

The acronym GEOPRIV is never defined.

The IANA considerations section could be much clearer.  If I
were responsible for doing the IANA allocations for this 
document, I'm not sure that I'd understand what to do.

Nits:

   No IPR boilerplate in any of the documents
   References not split into normative and informative groups
     in dhcp-lci-option

I'll leave it to the security folks to register any actual discuss
votes here, but I'm concerned about the security considerations given
in draft-ietf-geopriv-dhcp-lci-option-02.txt aren't adequate. In particular
while the possibility of eavesdropping on LCI information returned to clients
is mentioned, there's no reference given to the discussion of the possible
threats such exposure causes given in draft-ietf-geopriv-threat-analysis-01.txt.

The security considerations section also doesn't discuss the fact that it
provides information about the "last plug" but nothing beyond that. I often
see wireless equipment attached to those plugs, which can make an LCI that says
"she's at her desk" pretty much a lie. For example, I sometimes use my laptop
in my dentist's office, which as it happens is one floor above me and manages
to be able to see the wireless base station next to my desk.

New IANA in version 03 is better, but could still be tweaked. Suggested 
revision of IANA consideration section (to make it read better):

4.  IANA Considerations

   IANA has assigned a DHCP option code of TBD for the GeoLoc option 
   defined in this document. 

   The GeoLoc Option defines two fields for which IANA is to maintain
   a registry: The Altitude (AT) field (see Section 2) and the Datum
   field (see Section 2).  New values for the Altitude (AT) field are
   assigned through "Standards Action" [RFC 2434]. The initial values
   of the Altitude registry are as follows:

   AT = 1  meters of Altitude defined by the vertical datum 
           specified. 

   AT = 2  building Floors of Altitude. 

   Any additional LCI datum(s) to be defined for use via this DHC
   Option are assigned through a Standards Track RFC. The datum
   indicator MUST include specification of both horizontal and
   vertical datum. The initial values of the Datum registry are as
   follows:

   Datum = 1 denotes the vertical datum WGS 84 as defined by the 
           EPSG as their CRS Code 4327; CRS Code 4327 also specifies 
           WGS 84 as the vertical datum
	   
   Datum = 2 denotes the vertical datum NAD83 as defined by the 
           EPSG as their CRS Code 4269; North American Vertical Datum 
           of 1988 (NAVD88) is the associated vertical datum for NAD83

   Datum = 3 denotes the vertical datum NAD83 as defined by the 
           EPSG as their CRS Code 4269; Mean Lower Low Water (MLLW) is 
           the associated vertical datum for NAD83