Subject: [Ecrit] Joint Meeting with the 3GPP

From: <[email-masked]>
Date: Tue, 13 May 2008 09:58:56 +0300

Hi all, 

We would like to inform you that we are currently planning to organize a
meeting with the 3GPP around August 2008. The main topic for our
discussion is the harmonization of the 3GPP and the IETF emergency
services architecture. 

We will distribute more details as soon as they are available.  

Ciao
Hannes & Marc

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Francois Menard <[email-masked]>
Date: Tue, 13 May 2008 07:13:18 -0400

So that we may come prepared to this meeting, could you provide links  
to the latest specs, particularly the transmission of location by  
value from the end-point to the PSAP.

F.

On 13-May-08, at 2:58 AM, <[email-masked]> <[email-masked] 
 > wrote:

--
Francois Menard
[email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Tue, 13 May 2008 07:39:19 -0400

Francois,

I don't have a complete list, but to answer your specific question, 
location is transmitted by value from the endpoint to the PSAP in the 
SIP INVITE message using the mechanism described in 
draft-ietf-sip-location-conveyance.

--Richard

---

From: <[email-masked]>
Date: Tue, 13 May 2008 14:45:02 +0300

Thanks Richard for responding. 

Additionally, I think a good start for the overall picture is the ECRIT
framework and Phone BCP documents: 
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-05.txt

I will ask Hannu to provide us with the latest 3GPP specifications. 

Ciao
Hannes

>-----Original Message-----
>From: ext Richard Barnes [mailto:[email-masked]] 
>Sent: 13 May, 2008 14:39
>To: Francois Menard
>Cc: Tschofenig Hannes (NSN - FI/Espoo); [email-masked]
>Subject: Re: [Ecrit] Joint Meeting with the 3GPP
>
>Francois,
>
>I don't have a complete list, but to answer your specific 
>question, location is transmitted by value from the endpoint 
>to the PSAP in the SIP INVITE message using the mechanism 
>described in draft-ietf-sip-location-conveyance.
>
>--Richard
>
>
>
>Francois Menard wrote:
>> On 13-May-08, at 2:58 AM, <[email-masked]> 
>> <[email-masked]  > wrote:
>> 
>>> Hi all,
>>>
>>> We would like to inform you that we are currently planning to 
>>> organize a meeting with the 3GPP around August 2008. The main topic 
>>> for our discussion is the harmonization of the 3GPP and the IETF 
>>> emergency services architecture.
>>>

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 13 May 2008 14:50:10 +0300

Since Dan Romascanu asked me, I should also mention the following few
things. 

There was already a joint meeting with the 3GPP in July 2006. That
meeting was labeled as "information sharing activity", i.e., it was not
an official IETF meeting and hence the note well statement did not
apply. The meeting was open to everyone. Meeting minutes, presentations
etc. were made available to everyone (and they are still available).

Based on what was discussed so far the upcoming meeting will have the
same style but will be attached to a 3GPP meeting. 

I hope that this clarifies a bit.

Ciao
Hannes

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext [email-masked]
>Sent: 13 May, 2008 09:59
>To: [email-masked]
>Subject: [Ecrit] Joint Meeting with the 3GPP
>
>Hi all, 
>
>organize a meeting with the 3GPP around August 2008. The main 
>topic for our discussion is the harmonization of the 3GPP and 
>the IETF emergency services architecture. 
>

---

From: "Francois Menard" <[email-masked]>
Date: Tue, 13 May 2008 09:43:19 -0400

Does the spec calls for digitally signing the LbyV by the PSAP, such that
the PSAP can recognize an LbyV as being signed by itself as dispatch-able
(i.e. MSAG-VALID), msag=master street address guide.

F.

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: 13 mai 2008 07:39
To: Francois Menard
Cc: <[email-masked]>; [email-masked]
Subject: Re: [Ecrit] Joint Meeting with the 3GPP

Francois,

--Richard

> On 13-May-08, at 2:58 AM, <[email-masked]>
<[email-masked] 
>> organize a

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 13 May 2008 09:50:41 -0500

>same style but will be attached to a 3GPP meeting.

"attached to a 3GPP meeting" sounds like you have a date and place in 
mind for the meeting. Care to share that with us (please)?  Many of 
us have travel restrictions or limited budgets, and need to plan accordingly.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 13 May 2008 09:57:44 -0500

>(i.e. MSAG-VALID), msag=master street address guide.

no, there is no MSAG component or element within the LbyV.

Location will become more than an emergency calling feature, and 
shouldn't be held up or bound to MSAG validation (and costs) for 
every location usage.

Location can be transmitted by 12 of the 14 SIP request methods, 
including the INVITE, per
http://tools.ietf.org/wg/sip/draft-ietf-sip-location-conveyance/

---

From: Richard Barnes <[email-masked]>
Date: Tue, 13 May 2008 13:36:45 -0400

Francois,

Let me answer your question in three parts:

1. The spec allows the LbyV to be digitally signed.  The location is 
carried as a MIME body in the SIP message, and thus can also be included 
in S/MIME form, signed, encrypted, or both.  See Appendix B of 
draft-ietf-sip-location-conveyance-10 for an example.
<http://tools.ietf.org/html/draft-ietf-sip-location-conveyance-10#appendix-B>

2. The signer does not necessarily have to be the PSAP (though this is 
definitely allowed).  In the model described in framework/phonebcp, the 
endpoint gets its location from a server in the access network to which 
it's connected, so when we talk about location signing, I usually 
imagine that it's signed by the access network's location server. 
However, if a PSAP wanted to, it could provide signed location objects 
to access networks in its jurisdiction that could then be handed out to 
endpoints, who would then send them back to the PSAP:

+------------+
|    PSAP    |<------(3)--------+
+------------+                  |
       |                         |
      (1)                        |
       |                         |
       V                         |
+------------+             +----------+
| Access Net |----(2)----->| Endpoint |
+------------+             +----------+

3. The IETF has not defined anything directly analogous to the MSAG, in 
the sense of a consolidated database (in fact, I believe that the NENA 
i3 architecture does away with the MSAG entirely).  However, there is a 
location validation function provided by the LoST protocol:
<http://tools.ietf.org/html/draft-ietf-ecrit-lost-09#section-8.3.5>
There is no current standard way for a location to be marked as valid 
(this could be hard, since notions of validity vary from place to 
place), but a PSAP could easily verify that a location is valid using LoST.

Cheers,
--Richard

---

From: <[email-masked]>
Date: Tue, 13 May 2008 22:17:23 +0300

Actually, Hannu Hietalahti promised to discuss this with other 3GPP
folks during the next 2 weeks. 
Then, he will tell us. 

Ciao
Hannes

>On Behalf Of ext James M. Polk
>Sent: 13 May, 2008 17:51
>To: [email-masked]
>"attached to a 3GPP meeting" sounds like you have a date and 
>place in mind for the meeting. Care to share that with us 
>(please)?  Many of us have travel restrictions or limited 
>budgets, and need to plan accordingly.
>
>

---

From: <[email-masked]>
Date: Tue, 13 May 2008 22:45:20 +0300

We did not agree todo anything close to (2).  

>Sent: 13 May, 2008 20:37
>To: [email-masked]
>1. The spec allows the LbyV to be digitally signed.  The 
>location is carried as a MIME body in the SIP message, and 
>thus can also be included in S/MIME form, signed, encrypted, 
>or both.  See Appendix B of 
>2. The signer does not necessarily have to be the PSAP (though 
>this is definitely allowed).  In the model described in 
>framework/phonebcp, the endpoint gets its location from a 
>server in the access network to which it's connected, so when 
>we talk about location signing, I usually imagine that it's 
>signed by the access network's location server. 
>However, if a PSAP wanted to, it could provide signed location 
>objects to access networks in its jurisdiction that could then 
>be handed out to endpoints, who would then send them back to the PSAP:
>
>+------------+
>3. The IETF has not defined anything directly analogous to the 
>MSAG, in the sense of a consolidated database (in fact, I 
>believe that the NENA
>i3 architecture does away with the MSAG entirely).  However, 
>there is a location validation function provided by the LoST protocol:
>There is no current standard way for a location to be marked 
>as valid (this could be hard, since notions of validity vary 
>from place to place), but a PSAP could easily verify that a 
>location is valid using LoST.
>
>Cheers,
>--Richard
>
>
>
>
>
>
>
>Francois Menard wrote:
>> Does the spec calls for digitally signing the LbyV by the PSAP, such 
>> that the PSAP can recognize an LbyV as being signed by itself as 
>> dispatch-able (i.e. MSAG-VALID), msag=master street address guide.
>> 
>> F.
>>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 13 May 2008 21:35:35 -0400

Certainly.  I wasn't claiming that that was the recommendation of the
IETF in any way, just that it was allowed.  Using signed location in
that way is not inconsistent with either location-conveyance or
framework/phonebcp; it's one option that a jurisdiction could employ to
assure the validity of static civic location information.

--RLB

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 13 May 2008 20:46:15 -0500

Though - to be clear - "validity" of the address is ultimately confirmed
by a successful LoST lookup. The purpose of "validation" is to
pre-ensure that the lookup will succeed. Having the PSAP sign the
location isn't necessary for this - and it's not obvious to me that it
actually helps. The LIS operator has the same onus to ensure valid
locations are provided either way. Once a location object is
"validated", there's no control over what real location that object
actually gets used from.

In terms of "location integrity" - i.e. ensuring that the caller isn't
lying about their location - is a different issue. I don't think having
location signed by the PSAP helps with this either. It's the access
network operator that can evaluate the correlation between the point of
connection used by the caller and the provided location.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Richard Barnes
Sent: Wednesday, 14 May 2008 11:36 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ecrit] Joint Meeting with the 3GPP

--RLB

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Francois Menard <[email-masked]>
Date: Tue, 13 May 2008 23:12:57 -0400

Let's assume the most pragmatic manual provisioning model, where I get  
a DHCP Option 82 with a MAC address tied to another MAC address that  
is tied to a given Civic.  I configure my DHCP server to relay a PSAP- 
digitally-signed LbyV to an IP Phone.  If the IP Phone dials SOS, he  
regurgitates a signed LbyV it has learned via DHCP LOC.

No LIS,

A Happy PSAP assigning MSAG valid entries to the service provider

Low cost

Privately negotiatable between a municipality an a VoIP service provider

No ILEC in the picture.

No LIS

No LIS

No LoST

No Server that can fail

What's the problem in this architecture?

F.

--
Francois Menard
[email-masked]

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 14 May 2008 00:24:08 -0500

Not possible using anything I have seen to date!

-----Original Message-----
From: [email-masked] on behalf of Francois Menard
Sent: Tue 5/13/2008 10:12 PM
To: Dawson, Martin
Cc: [email-masked]; [email-masked]
Subject: Re: [Ecrit] Joint Meeting with the 3GPP

No LIS,

Low cost

No ILEC in the picture.

No LIS

No LIS

No LoST

No Server that can fail

F.

--
Francois Menard
[email-masked]

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 14 May 2008 10:15:17 +0300

Hi Francois, 

I guess you have missed several years of discussion. You might want to
take a brief look at my tutorial slide set: 
http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/EswAgenda2007/
IETF-Emergency-Services-Tutorial.ppt

Ciao
Hannes

>From: ext Winterbottom, James [mailto:[email-masked]] 
>Sent: 14 May, 2008 08:24
>To: Francois Menard; Dawson, Martin
>Subject: RE: [Ecrit] Joint Meeting with the 3GPP
>
>
>Let's assume the most pragmatic manual provisioning model, 
>where I get a DHCP Option 82 with a MAC address tied to 
>another MAC address that is tied to a given Civic.  I 
>configure my DHCP server to relay a PSAP- digitally-signed 
>LbyV to an IP Phone.  If the IP Phone dials SOS, he 
>> Though - to be clear - "validity" of the address is ultimately 
>> confirmed by a successful LoST lookup. The purpose of 
>"validation" is 
>> to pre-ensure that the lookup will succeed. Having the PSAP sign the 
>> lying about their location - is a different issue. I don't think 
>> having location signed by the PSAP helps with this either. It's the 
>> access network operator that can evaluate the correlation 
>between the 
>> point of connection used by the caller and the provided location.
>>
>> Cheers,
>> Martin
>>
>On Behalf 
>> framework/phonebcp; it's one option that a jurisdiction could employ 
>> to assure the validity of static civic location information.
>>
>> --RLB
>>
>>
>>
>location is 
>>>> carried as a MIME body in the SIP message, and thus can also be 
>>>> included in S/MIME form, signed, encrypted, or both.  See 
>Appendix B 
>>>> of draft-ietf-sip-location-conveyance-10 for an example.
>>>> 2. The signer does not necessarily have to be the PSAP 
>(though this 
>>>> is definitely allowed).  In the model described in 
>server in 
>>>> the access network to which it's connected, so when we talk about 
>>>> location signing, I usually imagine that it's signed by the access 
>>>> network's location server.
>>>> objects to access networks in its jurisdiction that could then be 
>>>> handed out to endpoints, who would then send them back to the
>> PSAP:
>>>>
>>>> +------------+
>>>> 3. The IETF has not defined anything directly analogous to 
>the MSAG, 
>>>> in the sense of a consolidated database (in fact, I 
>believe that the 
>>>> NENA
>>>> i3 architecture does away with the MSAG entirely).  However, there 
>>>> is a location validation function provided by the LoST
>> protocol:
>>>> There is no current standard way for a location to be marked as 
>>>> valid (this could be hard, since notions of validity vary 
>from place 
>>>> to place), but a PSAP could easily verify that a location is valid 
>>>> using LoST.
>>>>
>>>> Cheers,
>>>> --Richard
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Francois Menard wrote:
>question, 
>----------------------------------------------------------------------
>> -------------------------- This message is for the designated 
>> recipient only and may contain privileged, proprietary, or otherwise 
>> private information.
>immediately 
>> and delete the original.  Any unauthorized use of this email is 
>> prohibited.
>>

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 14 May 2008 02:25:22 -0500

Well - the "DHCP" operator (let's call it a location server; the label
used isn't important and we can also ignore the question of how option
82 is "signed") is the one that knows the end point location - and is
providing the infrastructure to deliver the end point location. The PSAP
doesn't tell them what the end point location is.

"No LoST"? So how does the IP phone know where to send the call? The
location is that of the phone - and not the place to route the call
after all. Are you suggesting that the PSAP route is also encoded in
this "signature"? If so, it means the routing boundaries have to remain
fixed - if they moved (as they do), the location in the location server
would "encode" the wrong destination.

Assuming LoST is part of the picture, the operator cares that the
location information is "valid" in the sense that it will result in a
correct LoST lookup. They need to ask the "PSAP" (the emergency network
in some incarnation) whether the location they are provisioning is
"valid". The "PSAP" can provide a validation service for that location
without subsequently signing it.

What is the value of the signature? Where would the signature be
"checked"? What would be the result of the signature not verifying when
it is checked?

Cheers,
Martin

-----Original Message-----
From: Francois Menard [mailto:[email-masked]] 
Sent: Wednesday, 14 May 2008 1:13 PM
To: Dawson, Martin
Cc: Richard Barnes; [email-masked]; [email-masked]
Subject: Re: [Ecrit] Joint Meeting with the 3GPP

No LIS,

Low cost

No ILEC in the picture.

No LIS

No LIS

No LoST

No Server that can fail

F.

On 13-May-08, at 9:46 PM, Dawson, Martin wrote:

> confirmed
> having
> to
------------------------------------------------------------------------
------------------------
> this email is prohibited.
------------------------------------------------------------------------
------------------------

--
Francois Menard
[email-masked]

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 14 May 2008 19:04:37 -0500

>assure the validity of static civic location information.

I believe you are advocating (explicit) in your solution here to only 
that which disallows the UAC to modify a single XML element within 
the PIDF-LO message body.  Though, at the moment I don't believe 
location-conveyance says this must be possible, I believe this is 
likely mandatory (at least in spirit of Geopriv docs) but for the 
mere fact that the owner of the UAC (i.e., the target) needs to be a 
rulemaker (but not necessarily the only one) and set/enter/include 
some of the elements (at least) such as <method>, 
<retransmission-allowed>, and <retention-expiry> - each of which 
wouldn't be allowed if the whole PIDF-LO had a signature covering it. 
Yet, these are not necessarily, and often cannot be known to the LIS 
or PSAP at the time of the LCP response initially sending the PIDF-LO 
to the UAC (DHCP client in this case).

What am I missing?

> <http://tools.ietf.org/html/draft-ietf-sip-location-conveyance->> 
> 10#appendix-B>
> >>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 14 May 2008 19:23:41 -0500

I think it depends on precisely what is trying to be secured.
I have indicated several times what I believe needs to be secured at
least by the location provider, and I include the method parameter in
this. The <retention-expires> and <retransmission-allowed> elements are
policy that are ultimately set by the Target and not by the LIS, though
the LIS can provide guidance, consequently I don't see these as needing
to be included in the validation component of the location information
itself.

At this point I have only seen one proposal on the table for location
signing, so I can't comment on what other proposals may be capable of
addressing.

Cheers
James

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> James M. Polk
> Sent: Thursday, 15 May 2008 10:05 AM
> To: [email-masked]
to
question,

---

From: Richard Barnes <[email-masked]>
Date: Wed, 14 May 2008 22:41:34 -0400

James,

(Let me note that I'm not advocating a solution, just saying that it's 
one way you could do things that's allowed by the specs.  I don't really 
think it's a particularly good one, since it doesn't offer a significant 
advantage over just using LoST validation when necessary.  In fact, LoST 
is probably faster in a lot of cases than cert validation!)

I agree that signing a whole LO is a clumsy way of providing assurance 
about LI; it would be much preferable to have a selective signature over 
just the <location-info>, or even just a signed GML document.  However, 
the concept of signed location is not inimical to the GEOPRIV model. 
Let me try to clarify a few misconceptions:

First, there is not a requirement in 3693 that the Target be a Rule 
Maker, only that the Location Server respect the rules specified by the 
Location Generator (in the Location Object) and by the RM.  In the 
scenario where a PSAP is handing out signed LOs, there wouldn't even 
really be an RM in the distribution process.  The PSAP would be the LG, 
the access network would be the LS, and the endpoint would be the LR.

Second, in the PSAP-signed-location scenario, it's OK that there's no 
access controls, because the signed LOs are "raw" LOs -- they don't have 
any identity information, since the PSAP doesn't know who the LS is 
going to send them to.  And it's a long-held GEOPRIV tenet that location 
information by itself (without identity) doesn't need the protections 
provided by privacy rules.

Third, the RM is not necessarily an entity that specifies elements in a 
PIDF-LO.  Rules are propagated in two ways in the 3693 model, within the 
PIDF-LO (from the LG), and directly from the RM to the LS.  So the RM 
(or the Target acting as an RM) could specify access controls on a 
signed LO, but could not specify rules that would modify the LO returned.

Fourth, the Target can always use the signed LO to create a new LO with 
whatever location and privacy rules it wants -- it just can't then claim 
that the results were signed just because the original LO was signed. 
This is the correct result, since the new LO actually wasn't signed by 
the PSAP!

Cheers,
--Richard

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 15 May 2008 12:33:40 -0500

Richard

]I want to first say this isn't an attack on you, and I have no 
internal tone in this, or past, responses.  Just to be clear]

comments in-line below

At 09:41 PM 5/14/2008, Richard Barnes wrote:
>James,
>
>(Let me note that I'm not advocating a solution, just saying that 
>it's one way you could do things that's allowed by the specs.  I 
>don't really think it's a particularly good one, since it doesn't 
>offer a significant advantage over just using LoST validation when 
>necessary.  In fact, LoST is probably faster in a lot of cases than 
>cert validation!)
>
>I agree that signing a whole LO is a clumsy way of providing 
>assurance about LI; it would be much preferable to have a selective 
>signature over just the <location-info>,

to me, it would be preferable to have a PKI and there be a trust 
relationship between the PSAP and the LG, but that's another leap of faith  ;-)

Just doing this over the <location-info> is better than over the 
PIDF-LO, but this has the problem of deciding for the Target (which 
is at least involved in the RM process) which <location-info> 
elements are included in the message.  There are frequently going to 
be times where where the LG/Target doesn't include <location-info> 
elements it knows (i.e., could have included) for various 
reasons.  Perhaps the Target didn't want to include the seat number 
it was at in the cube it was in, but include the floor on up...

>or even just a signed GML document.  However, the concept of signed 
>location is not inimical to the GEOPRIV model. Let me try to clarify 
>a few misconceptions:
>
>Maker, only that the Location Server respect the rules specified by 
>the Location Generator (in the Location Object) and by the RM.

In the LbyV delivery of location, nearly all of the time, I believe 
the UAC to be the LG

>In the scenario where a PSAP is handing out signed LOs, there 
>wouldn't even really be an RM in the distribution process.

I think that is violating the 3693 process, one in which the RM makes 
the policy decisions as to who gets what <location-info> about a 
Target.  What you describe here is a scenario in which both the 
Target *and* the SP are not the RM. This was not envisioned in 3693.

>The PSAP would be the LG, the access network would be the LS, and 
>the endpoint would be the LR.

I think this makes the PSAP the tail that wags the location dog for 
all location usages.  Do you agree?

>Second, in the PSAP-signed-location scenario, it's OK that there's 
>no access controls, because the signed LOs are "raw" LOs -- they 
>don't have any identity information, since the PSAP doesn't know who 
>the LS is going to send them to.  And it's a long-held GEOPRIV tenet 
>that location information by itself (without identity) doesn't need 
>the protections provided by privacy rules.

I'm not sure what you mean by ""raw" LOs", unless you mean raw 
<location-info> for a given Target. To me that's just another form of 
LI, making the delivery system to the Target another LCP (which is 
not defined yet).

>Third, the RM is not necessarily an entity that specifies elements 
>in a PIDF-LO.

oh, I think it is.

The RM decides who gets what location from an LG (on behalf of a 
Target, if the Target is not the LG itself). I think this is the 
short definition for an RM.

>Rules are propagated in two ways in the 3693 model, within the 
>PIDF-LO (from the LG), and directly from the RM to the LS.

I think you're missing the part where the RM gets to decide the 
policy of whether or not the Location Seeker even gets a response 
(i.e., who gets location at all, and if a Seeker gets location, which 
parts of the Target's location do they get).  I think you are leaving 
this (important) part out in your analysis.

>So the RM (or the Target acting as an RM) could specify access 
>controls on a signed LO, but could not specify rules that would 
>modify the LO returned.

This is broken IMO. The Target was and is always part of the RM 
process, although they might not have final say over all the pieces 
of the RM process.

In other words, there might be a SP rule that nothing below 
street/street number be allowed in any location given out by the LG 
(because that entity might not want too precise a location given out 
for whatever reason). Yet, the SP generally wouldn't have a clue 
about any individuals the Target has blacklisted.  Both of these are 
RM policies, yet I read that you don't want the RM to be either the 
Target or SP (or enterprise?)...

I don't happen to agree with that model.  It places complete control 
for all location in the hands of PSAPs, and omits how large the 
location universe will be that doesn't involve emergency services.'

Again, PSAPs shouldn't wag the location dog, IMO.

>Fourth, the Target can always use the signed LO to create a new LO 
>with whatever location and privacy rules it wants -- it just can't 
>then claim that the results were signed just because the original LO 
>was signed.

I'm not sure yet what you mean by "it just can't then claim that the 
results were signed", because in all scenarios other than what you're 
talking about here, no one would be making any such claim - 
principally because there's no means of informing in a SIP or PIDF-LO 
element or header.  This <claiming-to-be-valid> element doesn't exist 
in the PIDF-LO, and it isn't defined in any SIP header either.

>This is the correct result, since the new LO actually wasn't signed 
>by the PSAP!

But they aren't signed in any architecture either...

color me confused by your message

>>I believe you are advocating (explicit) in your solution here to 
>>only that which disallows the UAC to modify a single XML element 
>>within the PIDF-LO message body.  Though, at the moment I don't 
>>believe location-conveyance says this must be possible, I believe 
>>this is likely mandatory (at least in spirit of Geopriv docs) but 
>>for the mere fact that the owner of the UAC (i.e., the target) 
>>needs to be a rulemaker (but not necessarily the only one) and 
>>set/enter/include some of the elements (at least) such as <method>, 
>>wouldn't be allowed if the whole PIDF-LO had a signature covering 
>>it. Yet, these are not necessarily, and often cannot be known to 
>>the LIS or PSAP at the time of the LCP response initially sending 
>>the PIDF-LO to the UAC (DHCP client in this case).
>>What am I missing?
>>
>>>--RLB
>>>
>>>
>>>