Subject: [Geopriv] WG2LC: draft-ietf-geopriv-held-identity-extensions-00.txt

From: Alissa Cooper <[email-masked]>
Date: Tue, 15 Sep 2009 11:58:04 -0400

All,

In an effort to generate discussion and progress a bit more  
efficiently in the WG, Richard and I would like to experiment with  
something we're calling "working group second-to-last call" (WG2LC).  
We think the existing structures that set deadlines for comment (WGLC,  
IETF LC, etc.) are rather effective at motivating people to take a  
look at documents of interest, so we'd like to extend that concept a  
bit further. WG2LC is what it sounds like: an informal call for  
comments with a deadline, preceding the issuance of an official WGLC.  
The idea is to air some discussion about a document before it reaches  
the point of being ready for WGLC.

As a first experiment for WG2LC, consider this a working group second- 
to-last call for comments on

draft-ietf-geopriv-held-identity-extensions-00.txt

Please send your comments about this document to the list by 23  
September 2009.

Alissa

---

From: Marc Linsner <[email-masked]>
Date: Tue, 15 Sep 2009 12:48:42 -0400

Alissa,

I would like to first see that comments submitted from the prior requests
are acknowledged by the authors.

I submitted comments to which there was no response:
http://www.ietf.org/mail-archive/web/geopriv/current/msg07804.html

So we have an author that is a chair approving documents without
acknowledging or addressing comments received from a 3-day
solicitation-for-comments by the same.

I think following normal IETF procedure would be a better course of action.
This document should not have been approved as a wg item until all comments
are addressed.

-Marc-

On 9/15/09 11:58 AM, "Alissa Cooper" <[email-masked]> wrote:

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

---

From: Brian Rosen <[email-masked]>
Date: Tue, 15 Sep 2009 13:27:36 -0400

I think we need to progress this document quickly, but I still have many of
the concerns that Marc Linsner raised, especially when these extensions are
used by an endpoint.  When used by a third party ("On Behalf Of"), I think
the document has a lot more maturity.

I think the latter issues are more pressing, so an expedient would be to
progress the OBO aspects first.

In either case, the document needs more text on how trust relationships are
established.

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 15 Sep 2009 15:41:12 -0500

Hi Marc,

A few things. Firstly the HUM was adoption or rejection, your post was non-committal, it wasn't a call for comments, it was a HUM.

Martin posted an explicit email about your comments yesterday.

I would further add my comments to his:

I don't agree with the proposed title change for two reasons. Firstly, the proposed change describes one possible usage of the elements specified in the document. Secondly, the chnage doesn't describe what is actually specified in the document. I believe that if the title "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)" is accurate for what the document describes.

I believe that Bernard Aboba has stated on a number of occasions very clear cases where the device can/must provide an identifier other than its return-routable IP address to the LIS in order to obtain its location. This concept is clearly defined in the L7 LCP requirements document also. If you believe Bernard if wrong in the use cases that he has proposed, then I beseech you to provide a means in the same environment for providing the feature set, without having to use an additional target-provided identifier.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Marc Linsner
Sent: Tue 9/15/2009 11:48 AM
To: Alissa Cooper; GEOPRIV
Subject: Re: [Geopriv] WG2LC: draft-ietf-geopriv-held-identity-extensions-00.txt
 
Alissa,

-Marc-

------------------------------------------------------------------------------------------------
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: Richard Barnes <[email-masked]>
Date: Tue, 15 Sep 2009 17:02:19 -0400

> I don't agree with the proposed title change for two reasons.
> Firstly, the proposed change describes one possible usage of the
> elements specified in the document. Secondly, the chnage doesn't
> describe what is actually specified in the document. I believe that
> if the title "Use of Device Identity in HTTP-Enabled Location
> Delivery (HELD)" is accurate for what the document describes.

Is there an email or something that you could provide as a reference, 
just so we're all on the same page with respect to which scenarios we're 
talking about?

Thanks,
--Richard

---

From: Richard Barnes <[email-masked]>
Date: Tue, 15 Sep 2009 17:16:11 -0400

Sorry, meant to refer to this paragraph:
"
I believe that Bernard Aboba has stated on a number of occasions very 
clear cases where the device can/must provide an identifier other than 
its return-routable IP address to the LIS in order to obtain its location.
"

A description of these occasions would be helpful.
--Richard

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 15 Sep 2009 17:39:45 -0500

I will hunt for them when I get to the office.

Cheers
James

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 15 Sep 2009 18:34:12 -0500

Let's try this one for a start!
http://www.ietf.org/mail-archive/web/geopriv/current/msg06805.html

> Sent: Wednesday, 16 September 2009 7:16 AM
> To: Winterbottom, James
> Subject: Re: [Geopriv] WG2LC:
draft-ietf-geopriv-held-identity-extensions-
> 00.txt

---

From: Ted Hardie <[email-masked]>
Date: Tue, 15 Sep 2009 21:29:14 -0700

Howdy,

I've tried to catch up with the mailing list today, despite knowing that
I wasn't going to make the interim; I probably failed, so please forgive
me if this is answered (sorry, being the new guy at work is taking more
than all of my time).  Has this draft been circulated either to the security
area's advisory group or to apps-discuss?  My guess would be that both
groups would have significant insight/comments to make, and that by
soliciting their comments now, we might avoid getting this all the way
to IETF Last call before getting a chance to consider them.

For what it's worth, I remain in the  "you have the wrong box" minority
on this draft.  I remain personally convinced that the model of allowing
"raw" location information to be delivered using an IP address as identifier
(using return routability as a check) was and should remain a special case.
Extending that model with other identities, rather than presuming that
those identities should be applied as credentials for the receipt of a full-on
location object, is, in my opinion, just the wrong way to go about the whole
process.  I've said this at the mic many times, but without persuading
anyone much.  Call my intractable, but I still believe that if we wouldn't
buy most of these identifiers as valid credentials for the release of
data in a common security context, then their use here is symptomatic
of the application of a model that doesn't actually fit here.

Since I am currently catching up with the mailing list only a weekly basis,
I'll try to follow any discussion folks want to engage in, but please expect
my responses to be sporadic.  I also think it would be more valuable to
get the security area and general apps area feedback here earlier than it
is to further trying to see whether I'm an outlier in the group on this one.
I think that has been asked and answered.

			regards,
				Ted

At 11:58 AM -0400 9/15/09, Alissa Cooper wrote:
>All,
>
>In an effort to generate discussion and progress a bit more efficiently in the WG, Richard and I would like to experiment with something we're calling "working group second-to-last call" (WG2LC). We think the existing structures that set deadlines for comment (WGLC, IETF LC, etc.) are rather effective at motivating people to take a look at documents of interest, so we'd like to extend that concept a bit further. WG2LC is what it sounds like: an informal call for comments with a deadline, preceding the issuance of an official WGLC. The idea is to air some discussion about a document before it reaches the point of being ready for WGLC.
>
>As a first experiment for WG2LC, consider this a working group second-to-last call for comments on
>
>Please send your comments about this document to the list by 23 September 2009.
>
>Alissa
>
>
>
>
>
>
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 16 Sep 2009 01:52:41 -0500

Hi Ted,

Just to test the water by analogy... if there's a web page wherein you
type in your home address and it gives you the location of the
nearest... say... Ikea, is it a security problem that the web site
doesn't really know if that's your address?

Maybe that's a bad example because it involves "location"; that's not
the salient point. If it's a web page where I can type in my age,
weight, dietary habits etc and obtain an estimate of the probability of
having a heart attack; is it a security problem if the web site doesn't
really know if I'm typing in details that are applicable to me?

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ted Hardie
Sent: Wednesday, 16 September 2009 2:29 PM
To: Alissa Cooper; GEOPRIV
Subject: Re: [Geopriv] WG2LC:
draft-ietf-geopriv-held-identity-extensions-00.txt

Howdy,

than all of my time).  Has this draft been circulated either to the
security

For what it's worth, I remain in the  "you have the wrong box" minority
on this draft.  I remain personally convinced that the model of allowing
"raw" location information to be delivered using an IP address as
identifier
(using return routability as a check) was and should remain a special
case.
Extending that model with other identities, rather than presuming that
those identities should be applied as credentials for the receipt of a
full-on
location object, is, in my opinion, just the wrong way to go about the
whole
process.  I've said this at the mic many times, but without persuading
anyone much.  Call my intractable, but I still believe that if we
wouldn't
buy most of these identifiers as valid credentials for the release of
data in a common security context, then their use here is symptomatic
of the application of a model that doesn't actually fit here.

Since I am currently catching up with the mailing list only a weekly
basis,
I'll try to follow any discussion folks want to engage in, but please
expect
my responses to be sporadic.  I also think it would be more valuable to
get the security area and general apps area feedback here earlier than
it
is to further trying to see whether I'm an outlier in the group on this
one.
I think that has been asked and answered.

			regards,
				Ted

At 11:58 AM -0400 9/15/09, Alissa Cooper wrote:
>All,
>
>In an effort to generate discussion and progress a bit more efficiently
in the WG, Richard and I would like to experiment with something we're
calling "working group second-to-last call" (WG2LC). We think the
existing structures that set deadlines for comment (WGLC, IETF LC, etc.)
are rather effective at motivating people to take a look at documents of
interest, so we'd like to extend that concept a bit further. WG2LC is
what it sounds like: an informal call for comments with a deadline,
preceding the issuance of an official WGLC. The idea is to air some
discussion about a document before it reaches the point of being ready
for WGLC.
September 2009.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Sep 2009 07:42:58 -0700

>really know if I'm typing in details that are applicable to me?

I think the critical point is "doesn't really know".  A web page, obviously,
doesn't know anything.  But it's pretty telling that we use the term identifiers
(or identity extensions) for these bits.  They can be long term identifiers
and they can be used to associate other identities with the information passed.
How that association might work is opaque to the end user up until the point
all their google ad words are about blood thinners and their life insurance rates
go up.

To take a simple example, the geo URI draft has a location example.  The
geo URI has no identity associated with the location--yet the draft notes
in the text that it is the address of one of the authors.  The number of times
it may be possible to bind location to identity is higher than the end user might think,
and it is particularly important to recognize that it happens more easily when
you are keying the location off a long-lived identifier (or identity).

I think that means we would be safer making those distributions pidf-lo,
rather than lci; we'd have the opportunity to use the tools pidf-lo has.
Having made one exception, though, the group seems inclined to make more.
When we made the first one for DHCP, Jon bet me a drink that it would be
the thin edge of the wedge on this issue; I paid off long ago, but it's probably
time to pay up again.  He's been shown to be right on this one again and again.

regards,

Ted

---

From: Marc Linsner <[email-masked]>
Date: Wed, 16 Sep 2009 13:57:34 -0400

James,

In-line.....

On 9/15/09 4:41 PM, "Winterbottom, James" <[email-masked]>
wrote:

> Hi Marc,
> 
> 
> 
> A few things. Firstly the HUM was adoption or rejection, your post was
> non-committal, it wasn't a call for comments, it was a HUM.

Correct, there never was a call for comments on version 10 of the draft.
Normal IETF procedure is for a new version of an individual draft to be
announced to the WG mail list to solicit comments prior to any HUM asking if
it's ready to be elevated to a WG document.  Since version 10 of the
individual draft was never announced to the GeoPriv list, my comments were
appropriate and coincide with my comments for several of the previous
versions.

> Martin posted an explicit email about your comments yesterday.

Interesting, email must be in some strange time-warp problem.  Martin's
email showed up 5 hours after yours.

-Marc-

snip.................

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 16 Sep 2009 17:10:27 -0500

I think the reason that it's perceived as a "thin edge of the wedge" is
that it sets up a set of criteria that are ideologically driven and sees
them eroded under the pressure of pragmatism; a pressure that ultimately
wins out.

I'm not sure if you missed my point on the analogies. Your concern
appeared to be that the provision of the "identities" shouldn't be
regarded as trustable for the release of the location information. i.e:

<TED> "I still believe that if we wouldn't buy most of these identifiers
as valid credentials for the release of data in a common security
context, then their use here is symptomatic of the application of a
model that doesn't actually fit here."

My point is that there are plenty of practical situations where the LIS
doesn't need to care whether the device is providing data related to
itself or not. OBO (the term seems to be sticking) isn't an example of
this because the LIS explicitly authenticates the trust relationship
with the third party requester. The specific example is where the
population of devices in the network and the LIS that serves them simply
have no trust issues as far as whether they are providing their own
identity values or not. This is, in fact, a trust relationship between
the LIS and the devices. As with the web pages in the analogy, you can
characterize it as a "We don't care" trust relationship or as a "It's up
to the device what it wants" trust relationship but, nevertheless, the
LIS implementer can be in a position to make that judgement. An
enterprise network is a reasonable example.

Obviously an environment where a LIS cannot but should trust the
identity extensions is not a good environment in which to implement
those identity extensions in the LIS. Obviously a HELD client that
doesn't have an a-priori trust relationship with the LIS shouldn't send
identity information that is considered sensitive. I don't think this is
any different to typical security advice; it's similarly not a good idea
to send genuine authentication details to an FTP server if you're not
sure it's the FTP server to which those details apply.

Cheers,
Martin

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Thursday, 17 September 2009 12:43 AM
To: Dawson, Martin; Alissa Cooper; GEOPRIV
Subject: RE: [Geopriv] WG2LC:

>really know if I'm typing in details that are applicable to me?

I think the critical point is "doesn't really know".  A web page,
obviously,
doesn't know anything.  But it's pretty telling that we use the term
identifiers
(or identity extensions) for these bits.  They can be long term
identifiers
and they can be used to associate other identities with the information
passed.
How that association might work is opaque to the end user up until the
point
all their google ad words are about blood thinners and their life
insurance rates
go up.

To take a simple example, the geo URI draft has a location example.  The
geo URI has no identity associated with the location--yet the draft
notes
in the text that it is the address of one of the authors.  The number of
times
it may be possible to bind location to identity is higher than the end
user might think,
and it is particularly important to recognize that it happens more
easily when
you are keying the location off a long-lived identifier (or identity).

I think that means we would be safer making those distributions pidf-lo,
rather than lci; we'd have the opportunity to use the tools pidf-lo has.
Having made one exception, though, the group seems inclined to make
more.
When we made the first one for DHCP, Jon bet me a drink that it would be
the thin edge of the wedge on this issue; I paid off long ago, but it's
probably
time to pay up again.  He's been shown to be right on this one again and
again.

regards,

Ted

---

From: Richard Barnes <[email-masked]>
Date: Wed, 16 Sep 2009 21:20:38 -0400

(Reposting under the correct thread)

<individual-hat xmlns="urn:ietf:params:xml:ns:hats">

I'm going to try to frame this debate a little bit.

Let's start from the assumption that identity extensions are necessary 
for third-party/OBO queries.  My impression is that people are OK with 
the case where identifiers are included in queries from specific, 
authenticated, authorized entities (e.g., public safety authorities).

Now, we want to make sure that these extensions are not abused to gain 
unauthorized access to location.  So if we were to put forward a 
document defining identity extensions for third-party queries.  We would 
then have two options:
1. Forbid the use of identifiers in LCP requests, or
2. Assume that LCP usage is inevitable and require verification

Consider case (2) first.  The recommendation that we would want to make 
is for the LS to verify that the identifier actually corresponds to the 
target.  However, the identifiers in question will necessarily not be 
IP-layer identifiers (or else there would be no problem).  That means 
that we can't define an Internet-standard mechanism for this 
verification -- mechanisms will have to be network-specific.  So we're 
left making a vague statement that has to be re-interpreted for each 
network (or type of network).  Not very satisfying, but basically all 
that can be done.

Now, in case (1), we have to come up with some standards language to 
accomplish this prohibition.  Following our general goal, we would want 
something like, "The LS MUST authenticate requestors and apply 
authorization policy to requests containing identity extensions." 
However, what I've been calling the LCP Policy -- "For every location 
object, the Target of that LO is authorized" -- is a valid policy.  (You 
might even be able to express it in common-policy, if you had one entry 
per LO.)  And that puts us back into case (2).

This argument seems to me to imply that if we are to enable support for 
the third party requests that the emergency services community is 
requesting, then we will be stuck with the LCP usage as well, for which 
we can write recommendations that are unsatisfactory, but possibly clear 
enough for implementors to understand.  If one accepts this implication, 
we're left with a choice:
1. Provide support for third party requests and do our best on LCP use
2. Do nothing at all

My impression is that if we follow course (2) and do nothing, then the 
parties that are asking for us to do something (NENA, NICC, etc.) will 
invent something anyway.  Following course (1) would then not create 
anything that wouldn't be created anyway, and it would have the 
potential benefits of increasing interoperability and allowing this 
group to have some say over the privacy constraints.

So, to sum all that up, I think we should aim for some recommendations 
and privacy constraints on LCP usage of identifiers and move on.

--Richard

</individual-hat>

---

From: Marc Linsner <[email-masked]>
Date: Thu, 17 Sep 2009 11:20:09 -0400

Richard,

In the context of identity-extensions, for the use case of a target
discovering it's location (TDIL), which is a better descriptor than LCP, the
same functions of authenticate and authorize MUST be deployed before the
release of location information as is employed with the third-party or OBO
use cases.  The actual mechanism for authentication might differ, but none
the less, just because the TDIL policy is clear and well-understood does not
negate the need to authenticate the requestor, no matter how difficult that
task may be.  You can't apply policy until you know who you are talking to.
IOW, from a trust relationship pov, the LS/LIS is simply stating, 'Sure Mr.
Target, you can have your location information as soon as I verify you are
indeed Mr. Target'.

To create any mechanism with a lesser degree of authentication/authorization
is sacrificing the security of the privacy for the end-user that this work
group was created to protect.

I also find zero motivation to solve these issues with threats that if we
don't do it someone else will.  This threat has always existed.

I'm also not sure that NENA is asking for third-party/OBO, I believe it's
SPs asking for it.  NENA simply wants location included with call setup.

-Marc-

---

From: "Dan Mongrain" <[email-masked]>
Date: Thu, 17 Sep 2009 12:00:35 -0400

I have just read RFC 5606 regarding using <retransmission-allowed> and have a question when used in an emergency calling situation.

An emergency call is made and the PSAP answering the call is operated by the police department.  It is determined that police, fire and ambulance are required to be dispatched.  The fire department and the ambulance company can be deemed as separate parties from the police department (the ambulance company can be a private company).

1. If the <retransmission-allowed> flag is set to no, is forwarding the PIDF-LO onto both fire and ambulance a breach of the use of the flag?
2. The RFC implies that the LR must respect the flag only if it has a legal obligation to do so.  Can it be assume that because a caller has no reasonable expectation to privacy when making an emergency call (at least in North America) then forwarding of the PIDF-LO is allowed?

Thanx,

Dan Mongrain, ing.
Ingénieur système
Systems Engineer

[email-masked]
 
75 boul. de la Technologie
Gatineau, QC J8Z 3G4
OFFICE      819.778.2053
DIRECT      819.776.7906
FAX           819.772.8905
MOBILE     819.712.0491
www.plantcml.com

---

From: [email-masked]
Date: Thu, 17 Sep 2009 17:05:09 +0100

> SPs asking for it.  NENA simply wants location included with call setup.

Getting location included with call setup requires software and/or 
firmware updates to every (mobile) SIP device on the planet.

NICC therefore wants OBO, because in the short-to-medium term it's the 
only way to get location without requiring those device updates.

OBO can work now, with the only pre-requisite being deployment of LIS's on 
each IP access network.  Those LIS's will be required for first party 
queries anyway, for those devices that don't have GPS capablity.

Ray

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Sep 2009 19:28:24 +0300

Here is my take on this: 

The emergency caller indicates that the intended recipient of the communication is the Service URN (e.g., urn:service.sos in the US since there is no differentiation between the individual services). Hence, the retransmission-allowed attribute would allow you to consume location between the respective PSAPs. The case would be different if the call is specifically targeted to urn:service.sos.police. 

This is the technical side and I am sure there are folks who would disagree with my view since this intented recipient story never got well document in the SIP location conveyance document (see http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance-01). 

>From the legal side emergency services in most jurisdictions you are allowed to share location information with the other PSAPs. I have to dig out some regulatory text to support that statement. However, there are complications as well. Example: PSAPs being in different countries. Then, there are restrictions since you cannot use location information, caller-id, medical records, etc. for whatever you like. 

Ciao
Hannes

PS: Please note that there are differences between location and caller-id information as well (from a technical and legal point of view). 

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Dan Mongrain
>Sent: 17 September, 2009 19:01
>To: GEOPRIV
>Subject: [Geopriv] Question regarding <retransmission-allowed> 
>and calltransfers
>
>I have just read RFC 5606 regarding using 
><retransmission-allowed> and have a question when used in an 
>emergency calling situation.
>
>An emergency call is made and the PSAP answering the call is 
>operated by the police department.  It is determined that 
>police, fire and ambulance are required to be dispatched.  The 
>fire department and the ambulance company can be deemed as 
>separate parties from the police department (the ambulance 
>company can be a private company).
>
>1. If the <retransmission-allowed> flag is set to no, is 
>forwarding the PIDF-LO onto both fire and ambulance a breach 
>of the use of the flag?
>2. The RFC implies that the LR must respect the flag only if 
>it has a legal obligation to do so.  Can it be assume that 
>because a caller has no reasonable expectation to privacy when 
>making an emergency call (at least in North America) then 
>forwarding of the PIDF-LO is allowed?
>
>Thanx,
>
>Dan Mongrain, ing.
>Ingénieur système
>Systems Engineer
>
>[email-masked]
>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 17 Sep 2009 12:31:29 -0400

NENA has a use case for identity extensions.

When a legacy TDM wireline network is transitioned to an IP based, ecrit
compatible emergency response systems (we call that an Emergency Services IP
network or ESInet), the identifier for location remains as it is today, a
telephone number.  The LIS stores location keyed by telephone number, and
the emergency call specific function of the gateway that connects the legacy
wireline network to the ESInet must query the LIS using the telephone number
to get location to put on the SIP call following the rules in -phonebcp.
The gateway is a trusted entity, it is the UA (although it's not really the
target) and this is the emergency case, so the ruleset doesn't apply.

Brian

---

From: Marc Linsner <[email-masked]>
Date: Thu, 17 Sep 2009 12:36:01 -0400

Ray,

You won¹t find too much sympathy in the IETF for not wanting to upgrade.
We¹re talking about computing devices, not too many deployed that don¹t
require upgrades.  I believe the black-jack game on my iPhone has been
upgraded at least 4 times in the 8 month life of the phone (and the OS at
least 3 times).

OBO is, IMO, from an end-user pov, a privacy disaster waiting to happen.
But, with proper authentication and authorization it might be doable within
the constraints of GeoPriv.

-Marc-

On 9/17/09 12:05 PM, "[email-masked]" <[email-masked]>
wrote:

> Getting location included with call setup requires software and/or firmware
> updates to every (mobile) SIP device on the planet.
> 
> NICC therefore wants OBO, because in the short-to-medium term it's the only
> way to get location without requiring those device updates.
> 
> each IP access network.  Those LIS's will be required for first party queries
> anyway, for those devices that don't have GPS capablity.
> 
> Ray 
> 
> 
> 
>

---

From: Marc Linsner <[email-masked]>
Date: Thu, 17 Sep 2009 12:39:55 -0400

That doesn't necessarily require identity extensions.  A subscribe/notify to
[email-masked] will provide the same function.

-Marc-

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Sep 2009 19:43:00 +0300

Well. Think about all the work that is going on in the IETF when it
comes to transition architectures and considering not-updated devices. I
believe that there is now in the IETF more interest to meet the
expectations of the deployment rather than designing clean-slate
architectures. 
 
Example to support my statement: Proxy Mobile IP, IPv4/IPv6 transition
 
Ciao
Hannes
 
PS: I very strongly believe that we have to care about the intermediate
deployment stages as well since we otherwise will never get to the final
stage either. 

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of ext Marc Linsner
	Sent: 17 September, 2009 19:36
	To: [email-masked]
	Cc: GEOPRIV
	Subject: Re: [Geopriv] WG2LC:
draft-ietf-geopriv-held-identity-extensions-00.txt

	Ray,
	
	You won't find too much sympathy in the IETF for not wanting to
upgrade.  We're talking about computing devices, not too many deployed
that don't require upgrades.  I believe the black-jack game on my iPhone
has been upgraded at least 4 times in the 8 month life of the phone (and
the OS at least 3 times).
	
	OBO is, IMO, from an end-user pov, a privacy disaster waiting to
happen.  But, with proper authentication and authorization it might be
doable within the constraints of GeoPriv.
	
	-Marc-
	
	On 9/17/09 12:05 PM, "[email-masked]"
<[email-masked]> wrote:

		> SPs asking for it.  NENA simply wants location
included with call setup.
		
		Getting location included with call setup requires
software and/or firmware updates to every (mobile) SIP device on the
planet. 
		
		NICC therefore wants OBO, because in the short-to-medium
term it's the only way to get location without requiring those device
updates. 
		
		OBO can work now, with the only pre-requisite being
deployment of LIS's on each IP access network.  Those LIS's will be
required for first party queries anyway, for those devices that don't
have GPS capablity. 
		
		Ray

---

From: Marc Linsner <[email-masked]>
Date: Thu, 17 Sep 2009 12:51:30 -0400

Hannes,

I didn't say it wasn't possible.  Your examples don't sacrifice the overall
goal/characteristics of the 'next-generation' technology and neither will we
sacrifice the end-user's security of privacy to location information the
group was created to work on.

In hindsight, some transition mechanisms have caused many problems.
Remember the gray-beards screaming about NATs?

-Marc-

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Sep 2009 20:00:22 +0300

>Hannes,
>
>I didn't say it wasn't possible.  Your examples don't 
>sacrifice the overall goal/characteristics of the 
>'next-generation' technology and neither will we sacrifice the 
>end-user's security of privacy to location information the 

We don't sacrifice the privacy of the Target if the security mechanisms
described in the document are applied.

>Remember the gray-beards screaming about NATs?

Actually, this is a very good example where the industry just did
something because the IETF did not react to the practical needs.
Protocol design requires more than just technical requirements but also
insight into the properly shared responsibilities and incentives. 

Ciao
Hannes

>> comes to transition architectures and considering 
>not-updated devices. 
>> I believe that there is now in the IETF more interest to meet the 
>> PS: I very strongly believe that we have to care about the 
>> intermediate deployment stages as well since we otherwise will never 
>> get to the final stage either.
>> 
>>  
>> 
>> Behalf Of ext Marc Linsner
>> that don't require upgrades.  I believe the black-jack game on my 
>> iPhone has been upgraded at least 4 times in the 8 month life of the 
>> phone (and the OS at least 3 times).
>> 
>term it's the 
>> OBO can work now, with the only pre-requisite being deployment of 
>> LIS's on each IP access network.  Those LIS's will be required for 
>> first party queries anyway, for those devices that don't have GPS 
>> capablity.
>> 
>> Ray
>> 
>> 
>> 
>> 
>> 
>> 
>
>
>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 17 Sep 2009 13:15:23 -0400

Correct.  They would be needed if the LIS wished to use HELD as opposed to
presence.

Presence is a good example of OBO with appropriate privacy considerations
handled.  The presence server is an LS, it requires appropriate
authentication and it must enforce the rules.  The resulting PIDF would
include the rules.

Brian

---

From: Marc Linsner <[email-masked]>
Date: Thu, 17 Sep 2009 13:29:01 -0400

So, this begs the question.  Has NENA examined which protocol is suitable
for their task and made a choice?

-Marc-

---

From: Marc Linsner <[email-masked]>
Date: Thu, 17 Sep 2009 13:56:49 -0400

Hannes,

In-line.....

> described in the document are applied.

Not sure I agree. An excerpt from the document (section 5):

" When Device identity is used, the "LCP policy" is only applicable if
   the LR and Target are the same entity.  If they are the same, the
   security and privacy considerations of the base HELD protocol
   [I-D.ietf-geopriv-http-location-delivery
<http://tools.ietf.org/html/draft-ietf-geopriv-held-identity-extensions-00#r
ef-I-D.ietf-geopriv-http-location-delivery> ] MAY be applied by a LIS.
   The usage of the additional identifiers defined in this document by
   the LR MAY cause the LIS to perform additional security verifications
   to take place."

I have yet to find where you describe the 'additional security verifications
to take place' and the mechanisms required to accomplish such.

How does the LIS verify that the identifier belongs to the target and not
someone else?

> something because the IETF did not react to the practical needs.

Hmm... The 'excuse' for NATs was IPv4 address exhaustion.  But IPv6 was
first published 1995 and updated in 1998.  I would not consider this the
IETF not reacting!  And my comment about the gray-beards was the IETF
forewarning the problems NATs would cause, which in hindsight, have proven
to be true and have cost far more $$ than simply upgrading to IPv6 way back
when.

> insight into the properly shared responsibilities and incentives.

And protection of the Internet Architecture model.

-Marc-

---

From: Brian Rosen <[email-masked]>
Date: Thu, 17 Sep 2009 14:03:39 -0400

It says clients must do both, servers can do either.

Brian

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 17 Sep 2009 13:28:34 -0700

> verification -- mechanisms will have to be network-specific. 
> So we're left making a vague statement that has to be re-interpreted for each
> network (or type of network).  Not very satisfying, but basically all that can be done.

I don't think that it's necessary for us to restrict ourselves to vague statements in
all cases.  For some types of identifiers (such as MAC addresses, NAIs, telephone #s),
we can probably give quite specific recommendations about verification procedures.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 17 Sep 2009 18:17:30 -0400

Of course.  There are cases where we can make specific recommendations 
(please provide text!), but we can't cover all the identifiers out 
there.  Maybe a compromise approach would be to only include identifiers 
where such text can be written?

--Richard

---

From: John Morris <[email-masked]>
Date: Thu, 17 Sep 2009 18:32:55 -0400

That strikes me as a reasonable approach:

1) make a broad general statement calling for strong authentication,  
etc.
2) provide a number of instances where we can make specific  
recommendations (or refer to specific docs from other standards bodies)
3) and include language that says "for other instances not covered by  
these examples, one must use comparably strong techniques"

But I have to say, it is not clear to me from this thread if there is  
even agreement on exactly what problem needs to be solved (or whether,  
for example, NENA and others need a particular thing solved).  I would  
hope in coming up with text for 2) that we would all come to greater  
clarity on the exact types of use cases when the extensions will be  
used.

John

On Sep 17, 2009, at 6:17 PM, Richard Barnes wrote:

> Of course.  There are cases where we can make specific  
> recommendations (please provide text!), but we can't cover all the  
> identifiers out there.  Maybe a compromise approach would be to only  
> include identifiers where such text can be written?
>
> --Richard
>
>
>
> Bernard Aboba wrote:
>>> verification -- mechanisms will have to be network-specific. So  
>>> we're left making a vague statement that has to be re-interpreted  
>>> for each

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 17 Sep 2009 18:37:06 -0500

Dan

To you #1 - it's hard to argue this isn't a 
breach, given the scenario you define. This is a 
bit of a sticky spot IMO, wrt this spec, if it is 
answered by a true destination, and not just a 
clearing house such as a PSAP that dispatches 
each of these different responders.

I do not believe it is a problem for practical 
matters, because you want the caller's PIDF-LO to 
be sent to all responders necessary - which goes 
to your #2, not exactly that there is no 
expectation of privacy, but that the caller is 
freely asking for someone to listen to the 
information (including their location) they are providing in a time of need.

James

At 11:00 AM 9/17/2009, Dan Mongrain wrote:
><retransmission-allowed> and have a question 
>when used in an emergency calling situation.
>
>An emergency call is made and the PSAP answering 
>the call is operated by the police 
>department.  It is determined that police, fire 
>and ambulance are required to be 
>dispatched.  The fire department and the 
>ambulance company can be deemed as separate 
>parties from the police department (the 
>ambulance company can be a private company).
>
>1. If the <retransmission-allowed> flag is set 
>to no, is forwarding the PIDF-LO onto both fire 
>and ambulance a breach of the use of the flag?
>2. The RFC implies that the LR must respect the 
>flag only if it has a legal obligation to do 
>so.  Can it be assume that because a caller has 
>no reasonable expectation to privacy when making 
>an emergency call (at least in North America) 
>then forwarding of the PIDF-LO is allowed?
>
>Thanx,
>
>Dan Mongrain, ing.
>Ingénieur système
>Systems Engineer
>
>[email-masked]
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 17 Sep 2009 18:44:37 -0500

At 11:28 AM 9/17/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

>This is the technical side and I am sure there 
>are folks who would disagree with my view since 
>this intented recipient story never got well 
>document in the SIP location conveyance document 
>(see http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance-01).

Hannes

Please remind me what this "intented recipient" 
story is that Conveyance has failed to capture. 
I'm drawing a blank on this point at the moment, and working on -02 at the now.

Thanks

James

>Ciao
>Hannes
>
>PS: Please note that there are differences 
>between location and caller-id information as 
>well (from a technical and legal point of view).
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 17 Sep 2009 21:05:44 -0500

masterful change of subject

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Marc Linsner
Sent: Friday, 18 September 2009 3:29 AM
To: Brian Rosen
Cc: GEOPRIV
Subject: Re: [Geopriv] WG2LC:
draft-ietf-geopriv-held-identity-extensions-00.txt

So, this begs the question.  Has NENA examined which protocol is
suitable
for their task and made a choice?

-Marc-

On 9/17/09 1:15 PM, "Brian Rosen" <[email-masked]> wrote:

>>>> discovering it's location (TDIL), which is a better descriptor than
LCP,
>>>> the
>>>> the less, just because the TDIL policy is clear and well-understood
does
>>>> not
we're
>>>>>> In an effort to generate discussion and progress a bit more
efficiently

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 18 Sep 2009 09:20:52 +0300

James, 

>Dan
>
>To you #1 - it's hard to argue this isn't a breach, given the 
>scenario you define. This is a bit of a sticky spot IMO, wrt 
>this spec, if it is answered by a true destination, and not 
>just a clearing house such as a PSAP that dispatches each of 
>these different responders.

So, what is your answer: With retransmission-allowed being set to 'no' is entity X allowed to forward it to entity Y? (ignoring the legal aspects for a moment)

Based on what criteria should a computer program make the distinction. 

Ciao
Hannes

>
>I do not believe it is a problem for practical matters, 
>because you want the caller's PIDF-LO to be sent to all 
>responders necessary - which goes to your #2, not exactly that 
>there is no expectation of privacy, but that the caller is 
>freely asking for someone to listen to the information 
>(including their location) they are providing in a time of need.
>
>James
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 18 Sep 2009 09:22:36 +0300

Hi James, 
 
>>This is the technical side and I am sure there are folks who would 
>>disagree with my view since this intented recipient story never got 
>>well document in the SIP location conveyance document (see 
>>http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance-01).
>
>Hannes
>

I noted that in my mail to Dan. Still, I believe there are aspects in the entire retransmission-allowed story unanswered (and Martin raised those as well). 

>I'm drawing a blank on this point at the moment, and working 
You should have responded to the comments a long, long time ago already (given that folks are waiting for the document). 

Ciao
Hannes

>Thanks
>
>James
>
>
>>Ciao
>>Hannes
>>
>>PS: Please note that there are differences between location and 
>>caller-id information as well (from a technical and legal point of 
>>view).
>>
>> >Subject: [Geopriv] Question regarding <retransmission-allowed> and 
>> >calltransfers
>> >
>> >I have just read RFC 5606 regarding using <retransmission-allowed> 
>> >and have a question when used in an emergency calling situation.
>> >
>> >An emergency call is made and the PSAP answering the call 
>is operated 
>> >by the police department.  It is determined that police, fire and 
>> >ambulance are required to be dispatched.  The fire 
>department and the 
>> >ambulance company can be deemed as separate parties from the police 
>> >department (the ambulance company can be a private company).
>> >
>> >1. If the <retransmission-allowed> flag is set to no, is forwarding 
>> >the PIDF-LO onto both fire and ambulance a breach of the use of the 
>> >flag?
>> >2. The RFC implies that the LR must respect the flag only 
>if it has a 
>> >legal obligation to do so.  Can it be assume that because a caller 
>> >has no reasonable expectation to privacy when making an emergency 
>> >call (at least in North America) then forwarding of the PIDF-LO is 
>> >allowed?
>> >
>> >Thanx,
>> >
>> >Dan Mongrain, ing.
>> >Ingénieur système
>> >Systems Engineer
>> >
>> >[email-masked]
>> >

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 18 Sep 2009 01:55:59 -0500

At 01:22 AM 9/18/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>I noted that in my mail to Dan. Still, I believe 
>there are aspects in the entire 
>retransmission-allowed story unanswered (and Martin raised those as well).
>
>You should have responded to the comments a 
>long, long time ago already (given that folks are waiting for the document).

SIP has a Request-URI value, a To: and a Route: 
header value. Leaving aside the idea that 
intermediary servers are valid Location 
Recipients, if none of these SIP values identify 
the intended (destination) recipient, then 
who/what is the SIP message (carrying location) intended for?

The PIDF-LO has no element or attribute 
indicating the intended recipient - therefore, 
saying a doc fails to expand on, explain or 
describe something it perhaps should isn't a good 
reason for not answering my query now - in a different WG..

You remind me of a girlfriend saying "if you 
don't know what you did wrong, then I'm not going to tell you now!"  geez...

That attitude only guarantees you will never get 
what you want in the doc, which is sad - given that it isn't an RFC yet.

For the record, in SIP:
- Alice can tell Bob her location;
- Alice can tell any intermediary between her and Bob her location;
- Alice can deny any intermediary between her and 
Bob from learning her location;
- Alice can even tell Bob about Carol's location, 
if Alice knows Carol's location *and* Carol's 
retransmission-allowed was set to yes when Alice received it.

Each of the above scenarios are independent of 
the PIDF-LO or location URI conveyance choice.

What SIP *cannot* do is have Alice instruct Bob 
to tell Carol about Alice's location  -- with or 
without Alice's retransmission-allowed set to yes or no.

James

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 18 Sep 2009 10:58:05 +0300

Hi James, 

>>I noted that in my mail to Dan. Still, I believe there are aspects in 
>>the entire retransmission-allowed story unanswered (and Martin raised 
>>those as well).
>>
>>You should have responded to the comments a long, long time 
>ago already 
>>(given that folks are waiting for the document).
>
>header value. Leaving aside the idea that intermediary servers 
>are valid Location Recipients, if none of these SIP values 
>identify the intended (destination) recipient, then who/what 
>is the SIP message (carrying location) intended for?

BUT none of the specifications say that there is a relationship between these fields and the location object. (If I recall it correctly then Keith or John had some questions about the entity element in the PIDF-LO as well.)

If this would be so clear to everyone then Dan would have not asked the question on the list. 

See also the comment Martin has raised about the relationship between the basic policy and the extended policy rules. 

>
>The PIDF-LO has no element or attribute indicating the 
>intended recipient - therefore, saying a doc fails to expand 
>on, explain or describe something it perhaps should isn't a 
>good reason for not answering my query now - in a different WG..

I am insisting to have a separate field but somewhere in the documents someone has to say that these fields serve a special purpose in the entire privacy policy rule evaluation. 

>
>You remind me of a girlfriend saying "if you don't know what 
>you did wrong, then I'm not going to tell you now!"  geez...
>
>That attitude only guarantees you will never get what you want 
>in the doc, which is sad - given that it isn't an RFC yet.
>
>For the record, in SIP:
>- Alice can deny any intermediary between her and Bob from 
>learning her location;
>- Alice can even tell Bob about Carol's location, if Alice 
>knows Carol's location *and* Carol's retransmission-allowed 
>was set to yes when Alice received it.
>
>Each of the above scenarios are independent of the PIDF-LO or 
>location URI conveyance choice.
>
>What SIP *cannot* do is have Alice instruct Bob to tell Carol 
>about Alice's location  -- with or without Alice's 
>retransmission-allowed set to yes or no.

These examples are the reasons why some of the policy is in practice difficult to understand since we always talk about "Alice" and "Bob" and not about Request-URI value, 
a To: and a Route:  header value and the scenarios that are important to us. 

To come back to Dan's example: Am I allowed (only from a technical point of view) to forward a call that arrived at a police.example.com to fire.example.com when the call was targeted at urn:service.sos? What about the case where the call was sent to urn:service.sos.police? What about the case where the call was targeted to urn:service.sos.police but that service does not exist and only urn:service.sos is available? What happens if the end host uses LoST and determines that it has to send the emergency call to esrp.example.com but then the call gets send to a bridge inside the ESINet where police.example.com and fire.example.com is connected to? 

Instead of always talking about "MUST adhere to the privacy policy" it might be useful to indicate to the reader what that actually means. 

Ciao
Hannes

><retransmission-allowed> 
>> >> >ambulance company can be deemed as separate parties from the 
>> >> >police department (the ambulance company can be a 
>private company).
>> >> >
>> >> >forwarding the PIDF-LO onto both fire and ambulance a breach of 
>> >> >the use of the flag?

---

From: Brian Rosen <[email-masked]>
Date: Fri, 18 Sep 2009 09:14:29 -0400

Could we use an example other than the emergency case?  In emergencies,
retransmission-allowed is going to be ignored in countries where there are
explicit regulations on handling location. In the example given, all of the
responders will get location regardless of the state of retransmission
allowed.  It will also be logged.

A better example is a call for pizza, which is forwarded to the closest
pizza shop.  If retransmision-allowed is set to no, the pizza shop won't get
location.

Brian 

On 9/18/09 2:20 AM, "Tschofenig, Hannes (NSN - FI/Espoo)"
<[email-masked]> wrote:

> So, what is your answer: With retransmission-allowed being set to 'no' is
> entity X allowed to forward it to entity Y? (ignoring the legal aspects for a
> moment)
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 18 Sep 2009 17:27:40 -0500

At 02:58 AM 9/18/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>BUT none of the specifications say that there is 
>a relationship between these fields and the 
>location object. (If I recall it correctly then 
>Keith or John had some questions about the 
>entity element in the PIDF-LO as well.)

Hannes - you are confusing the linkage between 
the SIP request/PIDF-LO with the "intended 
recipient" comment you made above. How exactly is 
the "intended recipient" affected by the entity element?

>If this would be so clear to everyone then Dan 
>would have not asked the question on the list.

you are missing Dan's question completely. Dan 
asked if - once a SIP INVITE is received at the 
police calltaker, would that calltaker be allowed 
to forward the caller's location on to a another 
organization (such as hospital for ambulance 
dispatch, which he gave as a scenario).  This has 
zero to do with the entity attribute discussion.

>See also the comment Martin has raised about the 
>relationship between the basic policy and the extended policy rules.
>
> >
>I am insisting to have a separate field

to indicate what - that this Location is intended for the police only?

That plays right into what Dan asked.

Linking the PIDF-LO entity attribute to the SIP 
request does *nothing* to indicate who is the 
intended LR of this PIDF-LO (which is the point 
you appear to want explicitly identified).

>but somewhere in the documents someone has to 
>say that these fields serve a special purpose in 
>the entire privacy policy rule evaluation.

What are "these fields" in the above sentence referring to?

The ones in SIP?

or the ones in the PIDF-LO?

We need to understand what you are wanting before 
we go any further with this discussion.

James

>These examples are the reasons why some of the 
>policy is in practice difficult to understand 
>since we always talk about "Alice" and "Bob" and not about Request-URI value,
>To come back to Dan's example: Am I allowed 
>(only from a technical point of view) to forward 
>a call that arrived at a police.example.com to 
>fire.example.com when the call was targeted at 
>urn:service.sos? What about the case where the 
>call was sent to urn:service.sos.police? What 
>about the case where the call was targeted to 
>urn:service.sos.police but that service does not 
>exist and only urn:service.sos is available? 
>What happens if the end host uses LoST and 
>determines that it has to send the emergency 
>call to esrp.example.com but then the call gets 
>send to a bridge inside the ESINet where 
>police.example.com and fire.example.com is connected to?
>
>Instead of always talking about "MUST adhere to 
>the privacy policy" it might be useful to 
>indicate to the reader what that actually means.
>
>Ciao
>Hannes
>
> >
> >James
> >
> >
> >>Ciao
> >>Hannes
> >>
> >>
> >> >Thanks
> >> >
> >> >James
> >> >
> >> >
> >> >>Ciao
> >> >>Hannes
> >> >>