RE: [Geopriv] Draft minutes of the GEOPRIV Interim Meeting of 16-17 May2005

Andy,

Thanks for providing your meeting minutes.
I had a few comments and observations.

The issue of how location information is provided to/acquired by a given
device is touched on at several points (your items 2 and 3).
John Peterson suggested the use of the term "location acquisition," and
I adopted it here (and in the NENA work) because it was clearly distinct
from "location delivery," which is often confused with delivering
location to the called entity, and also from "location conveyance,"
which is used in other IETF documents to refer to the method used to
carry PIDF-LO in a particular signaling protocol, e.g., SIP.)
I had the sense that there was agreement that for some access
architectures (not just wireless, but also architectures where multiple
service providers are involved) it may be necessary to support an
application layer protocol for a device to acquire its location
information, and that it could be distinct from the layer 2 mechanisms
used for location determination.
As you stated in item 3, Allison Mankin cautioned that a layer 7
protocol must implement measures to limit the unintended distribution of
information. But I did get the sense at the meeting that there was
agreement about actively pursuing this in the Geopriv WG--that I do not
see reflected in your notes.
Also as you mentioned in item 3, some participants noted use cases for
emergency services in which a proxy needs to participate in acquiring
location information on behalf of a target. I had the sense that this
was also acknowledged as a neecessary accommodation in the interim until
location determination and acquisition infrastructures are in place.

On the issue of multiple location entities, while the Geopriv WG
referred to the ECRIT WG the problem of determining an algorithm to
select from among multiple locations the most appropriate one (the
Compositor or Selector function), I thought that there was agreement
that there should be only one location provided for emergency calling
and if there are multiple locations, a "Compositor function" should
"select" the most appropriate one (with a caveat that description of a
given location might include both civic address information and
geographic coordinates). At least in the context of supporting
emergency services calling, I came away with the understanding that the
Compositor/Selector function might be performed by the endpoint device
or user, and in some cases by a proxy on their behalf. (This is not
part of the Geopriv WG notes, but I believe that resolution of this
issue was allocated to the ECRIT Policy document being authored by James
W. and Hannes?)

Although you indicated a number of issues that were not actually
resolved in the meeting, I had the sense that there was real progress in
understanding different needs and viewpoints. It was certainly valuable
to me!

Thanks,
Nadine Abbott

-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
Behalf Of Andrew Newton
Sent: Thursday, June 02, 2005 3:38 PM
To: GEOPRIV WG
Subject: [Geopriv] Draft minutes of the GEOPRIV Interim Meeting of 16-17
May2005

Here are the draft minutes of the GEOPRIV interim meeting. Please
send omissions, additions, comments, and change requests to me or the
list no later than June 16.

I'll also note that there are many instances in these minutes were
discussion did not produce consensus and the chair requested
participants to continue the discussion on the mailing list. To
date, I see only one person has done so.

-andy

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 3 Jun 2005 14:02:59 -0400