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

[Ballot comment]
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

[Ballot comment]
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

During the IESG review of  draft-ietf-geopriv-dhcp-lci-option-02.txt,
there were two major issues raised.  The first is that the IANA considerations
section needs to be clearer about what registries are needed.  Thomas Narten
has suggested the following text as one take on how to get that done:

The GeoLoc Option defines a 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:

[then include the intitial values... then have analagous text for the
Datum field.]

The other issue relates to how to get the best possible privacy
results when this option is in use.  Steve Bellovin is concerned
that the transmission of this information, even for the purpose of
construction a GeoPriv Location Object, represents some risk
to the client.  Given the current state of things in DHCP, some of
the obvious responses to that concern aren't really possible at
the moment.  He suggests, though, that requiring the DHCP server
to omit this option unless the client has made a specific request
for it will result in the data only being sent when the client needs it. 
As it stands, the IESG expects a new draft to address
these issues.  For the IANA considerations section, we may want
to confirm with IANA that they understand the rules prior to
re-submitting the draft.  If the working group agrees with Steve's
point of view, then text describing this is needed; if it disagrees,
then text on how it sees the problem and any alternate approach
should be drafted.

[Ballot comment]
>    An important feature of this specification is that location
>    information is completely under control of the end device rather
>    than stored in an outside service for retrieval by the end device.

Above doesn't  really seem right. Is the following what is really
meant:

  An important feature of this specification is that after the
  relevant DHC exchanges have taken place, the location information
  is stored on the end device rather than somewhere else, where
  retrieving it might be difficult in practice.

References not split.

[Ballot discuss]
>    Any additional Geopriv Altitude Types(s) to be defined for use via
>    this DHC Option MUST be done through a Standards Track RFC.

This should be moved to the IANA considerations.

Also, in the IANA considerations section needs to be clearer:

> 5.  IANA Considerations
>
>    The DHCP option code for the GeoLoc option is TBD.

Better:

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

>    This document calls for the IANA registration of the following:

better:

The GeoLoc Option defines a 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:

[then include the intitial values... then have analagous text for the
Datum field.]

[Ballot discuss]
Nit: the title is wrong.  This isn't a DHCP option "for" geopriv; rather, it's a geopriv-compatible DHCP option.

Nit: the text describing how to add new datum types should use rfc 2434 langauge, and cite it.

Not as much of a nit:  a pass by a copy editor is needed; the writing is bad enough, in places, to obscure the meaning.

major objection:  I wonder if the philosophy of this option is, in fact, geopriv-compatible.  The location information is indeed obfuscatable, but the amount of the obfuscation is controlled by the DHCP server, not the end system.  I would think that the DHCP client should supply the maximum precision in the DHCP request, rather than relying on the server.  If that can't be accomdated, the text should say that the server MUST NOT send lci unless requested by the client.

An applicability statement should be added, noting that it is only useful for known, wired jacks, and not in the case of, say, randomly-added wireless access points.

[Ballot comment]
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.

[Ballot comment]
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

[Ballot comment]
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.

[Ballot comment]
>    An important feature of this specification is that location
>    information is completely under control of the end device rather
>    than stored in an outside service for retrieval by the end device.

Above doesn't  really seem right. Is the following what is really
meant:

  An important feature of this specification is that after the
  relevant DHC exchanges have taken place, the location information
  is stored on the end device rather than somewhere else, where
  retrieving it might be difficult in practice.

>    Any additional Geopriv Altitude Types(s) to be defined for use via
>    this DHC Option MUST be done through a Standards Track RFC.

This should be moved to the IANA considerations (or refered to from
that section)

References not split.

[Ballot discuss]
Nit: the title is wrong.  This isn't a DHCP option "for" geopriv; rather, it's a geopriv-compatible DHCP option.

Nit: the text describing how to add new datum types should use rfc 2434 langauge, and cite it.

Not as much of a nit:  a pass by a copy editor is needed; the writing is bad enough, in places, to obscure the meaning.

major objection:  I wonder if the philosophy of this option is, in fact, geopriv-compatible.  The location information is indeed obfuscatable, but the amount of the obfuscation is controlled by the DHCP server, not the end system.  I would think that the DHCP client should supply the maximum precision in the DHCP request, rather than relying on the server.  If that can't be accomdated, the text should say that the server MUST NOT send lci unless requested by the client.

[Ballot discuss]
Nit: the title is wrong.  This isn't a DHCP option "for" geopriv; rather, it's a geopriv-compatible DHCP option.

Nit: the text describing how to add new datum types should use rfc 2434 langauge, and cite it.

Not as much of a nit:  a pass by a copy editor is needed; the writing is bad enough, in places, to obscure the meaning.

major objection:  I wonder if the philosophy of this option is, in fact, geopriv-compatible.  The location information is indeed obfuscatable, but the amount of the obfuscation is controlled by the DHCP server, not the end system.  I would think that the DHCP client should supply the maximum precision in the DHCP request, rather than relying on the server.

[Ballot discuss]
Nit:  the title is wrong.  This isn't a DHCP option "for" geopriv; rather, it's a geopriv-compatible DHCP option.

Not as much of a nit:  a pass by a copy editor is needed; the writing is bad enough, in places, to obscure the meaning.

major objection:  I wonder if the philosophy of this option is, in fact, geopriv-compatible.  The location information is indeed obfuscatable, but the amount of the obfuscation is controlled by the DHCP server, not the end system.  I would think that the DHCP client should supply the maximum precision in the DHCP request, rather than relying on the server.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.