Subject: [Geopriv] Offered Text into PIDF-LO ID

From: "James M. Polk" <[email-masked]>
Date: Tue, 23 Mar 2004 18:18:43 -0600

Below are two offered sections of text to cover the 2 additional fields
several want included in the PIDF-LO ID, plus some text in the IANA
section. I will send the author an attachment with proper txt formatting
in case this doesn't render very well via email.

This is an effort written by Henning and myself, with comments from Brian 
Rosen, John Morris, Keith Drage, Hannes Tschofenig, and Nadine Abbott.

The (sent)text covers the following:

    1. by what mechanism did the UAC receive its LI from (.11, GPS,
       manual entry, Triangulation, DHCP, etc) by name, not number

    2. what organization was that LI field value provided by (in the
       form of a URI)

New Section:
X.X  Method of Location determination

    The <method> element describes the way that the location information
    in the location object was derived. An example of this element is:

       <method>gps</method>

    Others will be IANA Registered later in this document for methods
    such as DHCP and 802.11 to name two.

    This <method> element MAY be included within the PIDF-LO in
    location conveyance.  Inclusion might provide more information than
    a user wants to reveal to the recipient if the sender is otherwise
    providing less precise civil or coordinate location information. An
    example of this is when a LO is transmitted with DHCP as the
    <method>, but only the precision of the city. The recipient might
    not like that the sender didn't reveal more precision when they
    apparently might have known more.

    Control of the inclusion of the <method> element within the PIDF-LO
    SHOULD be the Rule Maker's in every non-emergency case.

    This <method> element MUST be included within the PIDF-LO in
    location conveyance to emergency call centers (ECC).

New Section:
X.X  Provider of Location determination

    The <provided-by> element describes the organization that supplied
    the location information in the <method> element in the location
    object. An example of such element is:

       <provided-by>sip:[email-masked]</provided-by>

    The <provided-by> element MUST be included in location objects
    related to emergency calls and MAY be included in other location
    objects.

    The <provided-by> element allows the recipient to diagnose error
    conditions when the location information is found to be wrong.
    Current North American emergency calling systems contain this
    information.

    Users should be aware that this information can inadvertently
    provide additional information to the receiver, increasing the
    effective resolution of the geospatial or civil information. For
    example, if the LO includes only state-level information, including
    that the location information was provided by Columbia University
    provides a strong indication that the Target is actually located in
    a four-block area in Manhattan.

    Control of the inclusion of the <provided-by> element within the
    PIDF-LO SHOULD be the Rule Maker's in every non-emergency case.

    [The point made above should be incorporated - not necessarily
     repeated - into the Security Considerations section as well]

[Below Added to IANA Section]

6.X Location Method Registration

    This section registers 7 new <method/> tokens from section X.X.X
    [put in the section the text was added above in]:

       GPS: Global Positioning System

       A-GPS: GPS with assistance

       Manual: entered manually by an operator or user, e.g., based on
               subscriber billing or service location information

       DHCP: provided by DHCP [geo, civil]

       Triangulation: triangulated from time-of-arrival, signal strength
                      or similar measurements

       Cell: location of the cellular radio antenna

       802.11: 802.11 access point

===============

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: John Morris <[email-masked]>
Date: Wed, 24 Mar 2004 21:51:19 -0500

Let me offer my 2 cents on the language that James is proposing:

  -- There appears to be strong desire/demand/need within the 
emergency services community for the two additional pieces of info 
proposed to be enabled within the PIDF-LO (in large part to 
facilitate troubleshooting and further emergency followup in the 
event the initially transmitted location proves to be wrong).  I 
personally would argue that there is significant value to Geopriv in 
meeting this demand in terms of increased likelihood of deployment 
and acceptance of the working group's work product.  Although I 
realize that this is not ordinarily a large factor in IETF decisions, 
I fear that if Geopriv does not achieve broad deployment, a great 
opportunity to promote privacy protection will be missed.

  -- Having convinced myself that there is value in including these 
two pieces of data (and making them MUSTs for emergency calls), I am 
concerned about the flip-side -- I worry that lazy implementors will 
say "I  have to send these data to ECCs, so I might as well send them 
always".  Thus the proposed language saying that the sending of these 
data should be under Rulemaker/user control.  I would be perfectly 
happy with even stronger language (.... MUST NOT ....) but I've been 
convinced that in practice SHOULD is pretty strong language.

John

At 6:18 PM -0600 3/23/04, James M. Polk wrote:
>This is an effort written by Henning and myself, with comments from 
>Brian Rosen, John Morris, Keith Drage, Hannes Tschofenig, and Nadine 
>Abbott.
>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 25 Mar 2004 11:05:43 -0500

>    a four-block area in Manhattan.

I consider this a red flag.  The purpose of this group is to consider 
privacy in the sending of location information, and this simply ignores 
the issue.  That is not to say that I disfavor this idea.  I simply 
think it requires much more thought.

For instance, what purpose does the URI serve?  Does an emergency 
response center actually do lookups in whois based on the domain name 
in a URI?  Is sip:[email-masked] really going to help me during a 911 
call?  I think not.  It will more likely go unanswered, as is common 
when most people attempt to contact my ISP via any other means than 
email or their web-based complaint form.  In this case, all that has 
been done is that the privacy constraints have been ignored.

I think something more than a URI is needed for this to be useful.

Again, I do not have any objection to hammering out this idea.  I just 
don't believe we have thought it through with enough detail to include 
it in the base PIDF-LO spec.

So, can this be done as an extension?

-andy

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 25 Mar 2004 11:18:29 -0600

At 11:05 AM 3/25/2004 -0500, Andrew Newton wrote:

>the issue.  That is not to say that I disfavor this idea.  I simply think 
>it requires much more thought.
>
>For instance, what purpose does the URI serve?  Does an emergency response 
>center actually do lookups in whois based on the domain name in a URI?  Is 
>sip:[email-masked] really going to help me during a 911 call?  I think not.

And you would be right.

ECCs in North America want a type of "validation" that the location 
provided is a good address, and not some wild goose chase into the middle 
of the Hudson river. In the legacy world, they knew that a wire-pair laid 
by a certain company was connected to a certain address - this was that 
validation. Wireless made that much more grey (or didn't provide anything - 
which wasn't good), and they have instituted several means of validations 
including triangulation for certain types of infrastructures (where the 
"degree of certainty" came from that we have chosen *not* to do this phase 
within Geopriv). But this doesn't apply to all 911 calls (in NA), and the 
lawmakers aren't happy this technological capability can't be solved yet.

We've all heard about cases where a cellphone user calls 911 (or some other 
locally appropriate sequence) and told the ECC incorrect location 
information which resulted in the police/fire going to the wrong location 
and the person died because they didn't get "immediate" attention. The 
sound-bite recently was: "he would have lived if the <police/fire> would 
have shown up 5 minutes sooner". It made national news here in the states.

>It will more likely go unanswered,

nope, it will be answered

>as is common when most people attempt to contact my ISP via any other 
>means than email or their web-based complaint form.  In this case, all 
>that has been done is that the privacy constraints have been ignored.

But in the emergency case, it provides benefit - which John has agreed to. 
He is worried that implementors will get lazy for the user to user location 
conveyance situation - and I don't disagree with him. This should be added 
to the Security Considerations section as something implementors adhere to.

>I think something more than a URI is needed for this to be useful.

This is intended to be a URI from the company that owns the location 
providing device that the Target or Location server got the LI from. This 
is primarily for after the fact troubleshooting and I'm not aware of the 
intention to use it real-time (but I don't know everything). If the 
location provided was wrong in a particular case, then the organization at 
the URI can be contacted and told this to try and correct whatever problems 
there were with it for future usage; ensuring if sos@ were used again from 
that Target/UA, they would provide correct LI at that time.

It is a kinda slippery slope for usage, I agree. NENA is adamant they get 
something, and this seems to be enough for them at this time.

>don't believe we have thought it through with enough detail to include it 
>in the base PIDF-LO spec.
>

Based on what I've written, is this more palatable now?

cheers,
James

                                *******************

---

From: Andrew Newton <[email-masked]>
Date: Thu, 25 Mar 2004 13:21:41 -0500

Instead of responding to each person, I think it would be better if I 
just attempted a summary.

What I see here is that all the requirements for this, especially 
<provided-by>, have not been fully baked (Nadine said as much in her 
email).  So the general thought is that a URI will be used as an 
extension mechanism for that future functionality because it leaves 
open the possibility for almost anything.  If you think this a good 
thing, I invite you to step into the world of RFC 954 (apropos when 
talking about privacy).

As John has pointed out, a huge downside is the lazy implementer.  I 
actually wouldn't call them lazy.  A better description is that they 
are not fully aware of the ramifications of simply inserting a URI with 
regard to impact on privacy.  I do not think it is far fetched to 
envision an implementation that always inserts an http URI for the 
hostname of the location server (or even an http URI to the vendor as a 
misinterpretation of "provided-by").  Even worse, what about the techie 
in the field who must provide this information?

There are certainly better mechanisms available for extensibility, the 
best candidate being the syntax defining PIDF-LO itself, XML.

So if NENA wants NENA identifiers, why not:

   <provided-by> <nena> abc-123 </nena> </provided-by>

This makes it much clearer what information is being passed, what 
information the implementation needs to have, and what information the 
server operator needs to provide.  Leaving this field up to the 
imagination of the vendor or the tech guy in the field only invites 
trouble and will likely not provide an ECC with useful information.

-andy