>#22: Resolution does not define Geographic Privacy policy ?
>---------------------------------------+------------------------------------
> Reporter: martin.thomson@andrew.com | Owner:
> jmpolk@cisco.com
> Type: task | Status: new
>
> Priority: minor | Milestone:
> draft-ietf-geopriv-3825bis
>Component: rfc3825bis | Version:
>
> Severity: Active WG
> Document | Resolution:
> Keywords: policy |
>---------------------------------------+------------------------------------
>
>Comment(by bernard_aboba@hotmail.com):
>
> Currently, the document does not discuss privacy policy, so that there
> isn't much context provided. I interpret the statement to imply that
> neither resolution (nor uncertainty) metrics relate to privacy policy. If
> we are to say anything, more explanation is probably required.
>
> Martin's 3825bis document did contain the following paragraph in Section
> 1:
>
> This document only defines the delivery of location information from
> the DHCP server to the client, due to security concerns related to
> using DHCP to update the database. Within the GEOPRIV architecture
> as defined by RFC 3693 [RFC3693], the defined mechanism in this
> document for conveying initial location information is known as a
> "sighting" function. Sighting functions are not required to have
> security capabilities and are only intended to be configured in
> trusted and controlled environments. (A classic example of the
> sighting function is a Global Positioning System wired directly to a
> network node.) Further discussion of the protections that must be
> provided according to RFC 3694 [RFC3694] are in the Security
> Considerations section of this document (Section 4).
this paragraph is sloppy.
"...as defined by RFC 3693 [RFC3693], the defined mechanism in this
document..." talking about two different documents is clumsy.
The above paragraph is also inaccurate. DHCP servers are not sighting
(or are sighters for) anything. Another application residing on the
same entity as the DHCP server can do this sighting function, but has
zero to do with the DHCP server other than the API between the
functions. The DHCP server is further separated from sighting when
the server relies on a backend (i.e., separate) server for location
information for a specific client's request. This communication
would *not* be DHCP at all, which isn't clear from the above paragraph.
This paragraph is also missing the point recently raised that the
security properties of LI delivery of an LCP is based on the protocol
itself, not a function of the server needing to do anything (i.e.,
there is no authorization step or encryption necessary).
In the case of DHCP, the server receives a broadcast message with a
circuit-ID identifier and merely responds with a unicast with the LI.
There is nothing else done.
James
>--
>Ticket URL: <http://wiki.tools.ietf.org/wg/geopriv/trac/ticket/22#comment:1>
>geopriv <http://tools.ietf.org/geopriv/>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
