Fwd: [Geopriv] Document Action: 'Threat Analysis of the geopriv Protocol' to Informational RFC

[hardie@qualcomm.com]

This is the wrong write-up.  This document was originally in the same
document set as the DHCP option described below.  I asked that
they be split into separate documents before the relevant telechat, because
I was concerned about them being considered together.  They were
split, but apparently the original write-up stayed with all of them.
Please re-issue this one with the write-up that is now in the tracker,
and hold draft-ietf-geopriv-reqs until you've reviewed the write-up
with me.
			thanks,
				Ted


>X-test-idtracker: no
>From: The IESG <iesg-secretary@ietf.org>
>To: IETF-Announce:;
>Cc: Internet Architecture Board <iab@iab.org>,
>        RFC Editor <rfc-editor@rfc-editor.org>, <geopriv@ietf.org>
>Date: Mon, 03 Nov 2003 16:44:19 -0500
>Subject: [Geopriv] Document Action: 'Threat Analysis of the geopriv Protocol'
> to Informational RFC
>Sender: geopriv-admin@ietf.org
>X-BeenThere: geopriv@ietf.org
>X-Mailman-Version: 2.0.12
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>,
>	<mailto:geopriv-request@ietf.org?subject=unsubscribe>
>List-Id: Geographic Location/Privacy <geopriv.ietf.org>
>List-Post: <mailto:geopriv@ietf.org>
>List-Help: <mailto:geopriv-request@ietf.org?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>,
>	<mailto:geopriv-request@ietf.org?subject=subscribe>
>
>The IESG has approved following document:
>
>- 'Threat Analysis of the geopriv Protocol '
>   <draft-ietf-geopriv-threat-analysis-01.txt> as an Informational RFC
>
>This document is the product of the Geographic Location/Privacy Working Group.
>
>The IESG contact persons are Ted Hardie and Ned Freed.
>
>Technical Summary
> 
>This document specifies a Dynamic Host Configuration Protocol
>Option for the geographic location of the client, to be provided by
> the server.    The goal of this option is to enable a wired Ethernet host
>to provide its location (to an emergency responder, as one example).
>Wireless hosts can utilize this option to gain knowledge of the
>location of the radio access point used during host configuration,
>but will need other mechanisms, such as GPS,  to gain full knowledge
>of their locations.
> 
>Working Group Summary
> 
>There was significant discussion within the working group about how
>this work related to the privacy mechanisms proposed by geopriv's
>requirements document.
>
>This discussion eventually yielded consensus that this work was
>inherently about populating a location object using dhcp, rather
>than passing a location object with a using protocol.  Once this
>consensus was reached, working group discussion on the details
>of the protocol and how it fit into the geopriv framework were
>without significant dissent.
>
>Protocol Quality
> 
>This document was reviewed for the IESG by Ted Hardie
>
>
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www1.ietf.org/mailman/listinfo/geopriv