Subject: [Geopriv] Confused about draft-polk-geopriv-pidf-lo-4-agps-00.txt

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Jul 2008 17:00:14 +0300

I just ran into
http://www.ietf.org/internet-drafts/draft-polk-geopriv-pidf-lo-4-agps-00
.txt and got the impression that this document assumes some sort of
L7LCP based on SIP. 

Maybe I am completely off base here but does someone attempt to work on
another L7 LCP beyond HELD?

Ciao
Hannes

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

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 17 Jul 2008 13:47:52 -0500

>.txt and got the impression that this document assumes some sort of

glad you found it

>another L7 LCP beyond HELD?

In LCPs, both ends (the server and the client) know where the client 
is at the end of the transaction. This is true for each LCP to date.

draft-polk-geopriv-pidf-lo-4-agps-00.txt provides the ability of one 
side to get assistance data from the other in determining where the 
endpoint is.

BTW -- draft-polk-geopriv-pidf-lo-triangulation-00 does the same 
thing, but only the LS (as a LIS) does location determination.

SIP is just used here as a transport, because it alone has the 
ability to have persistent (periodic and triggered state information 
transfer) connections.

Only 2 of the 14 SIP Methods are to be used in this proposal 
(SUBSCRIBE and NOTIFY). There is nothing about voice or video or 
instant messaging in this proposal, so relatively, this is a lite 
implementation of SIP.

So, if this is how you define an LCP, then yes, SIP is being proposed 
as a new one, within this limited usage. If you do not define this as 
an LCP, then no, SIP is not being proposed as a new one.

Either way you define this (as an LCP or not), HTTP lacks the ability 
to have or create persistent connections, which at least one other 
SDO (WiMAX) requires for both triangulation and A-GPS data 
transfers.  SIP has this ability - specified in 2002 in RFC 3265, and 
this poses zero new security or privacy concerns relative to Conveyance.

James

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Jul 2008 22:03:37 +0300

James, 

have you been missing years of discussions around L7 LCPs? Henning even
had a proposal to use SIP, see
http://tools.ietf.org/html/draft-schulzrinne-geopriv-locationref-00

Based on the decisions in Prague the group decided to go for HELD and
there was no need seen to create yet another LCP. Adding yet another
protocol does not make deployment a lot simpler...

I find it amusing that you suddenly switch to a non DHCP based solution
(while some of your co-workers even this week fight for DHCP) :-)

Ciao
Hannes

PS: You write "poses zero new security or privacy concerns relative to
Conveyance." 

Let me give you something to think about: When you change one protocol
name against another one then do you think that the fundamental privacy
& security aspects are suddenly different? 

>-----Original Message-----
>From: ext James M. Polk [mailto:[email-masked]] 
>Sent: 17 July, 2008 21:48
>To: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
>Subject: Re: [Geopriv] Confused about 
>draft-polk-geopriv-pidf-lo-4-agps-00.txt
>
>>http://www.ietf.org/internet-drafts/draft-polk-geopriv-pidf-lo
>-4-agps-0
>>0 .txt and got the impression that this document assumes some sort of 
>>L7LCP based on SIP.
>
>glad you found it
>
>
>In LCPs, both ends (the server and the client) know where the 
>client is at the end of the transaction. This is true for each 
>LCP to date.
>
>draft-polk-geopriv-pidf-lo-4-agps-00.txt provides the ability 
>of one side to get assistance data from the other in 
>determining where the endpoint is.
>
>BTW -- draft-polk-geopriv-pidf-lo-triangulation-00 does the 
>same thing, but only the LS (as a LIS) does location determination.
>
>(SUBSCRIBE and NOTIFY). There is nothing about voice or video 
>or instant messaging in this proposal, so relatively, this is 
>a lite implementation of SIP.
>
>So, if this is how you define an LCP, then yes, SIP is being 
>proposed as a new one, within this limited usage. If you do 
>not define this as an LCP, then no, SIP is not being proposed 
>as a new one.
>
>Either way you define this (as an LCP or not), HTTP lacks the 
>ability to have or create persistent connections, which at 
>least one other SDO (WiMAX) requires for both triangulation 
>and A-GPS data transfers.  SIP has this ability - specified in 
>2002 in RFC 3265, and this poses zero new security or privacy 
>concerns relative to Conveyance.
>
>James
>
>
>>Ciao
>>Hannes
>>
>>
>>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 17 Jul 2008 14:59:37 -0500

>& security aspects are suddenly different?

"one protocol against another"

huh?

Conveyance already has PIDF-LO within SIP SUBSCRIBE and NOTIFY.

There is nothing new in either of these IDs relative putting a 
PIDF-LO in SUBSCRIBE or NOTIFY.

What do you see that's fundamentally different?

---

From: Richard Barnes <[email-masked]>
Date: Thu, 17 Jul 2008 17:11:05 -0400

I think where Hannes was going is that this document does make a 
meaningful change to the SIP presence system.  It does so by including a 
new type of information, which could introduce different privacy risks.

This extension is analogous to the transition between PIDF and PIDF-LO: 
  You're still just putting a PIDF in SUB/NOT.  There are two separate 
RFCs to deal with that extension (3693/3694).  So even though you're 
just adding something to a PIDF (or PIDF-LO), there might still be cause 
for some security and privacy discussions.

--Richard

James M. Polk wrote:
> There is nothing new in either of these IDs relative putting a PIDF-LO 
> in SUBSCRIBE or NOTIFY.
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 17 Jul 2008 16:12:30 -0500

>(while some of your co-workers even this week fight for DHCP) :-)

Amusing, huh?

(Is this laugh_out_loud amuzing?)

How about the requirements for this new functionality don't make 
sense in DHCP.  Is that a good enough reason?

Do I deny these requirements exist, or turn to a protocol that 
fulfills the requirements, or do I do what you're suggesting and 
force-fit this functionality into DHCP?

What would you do?

(I honestly don't know - the way you've toned this reply, Hannes)

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 17 Jul 2008 16:28:14 -0500

>protocol does not make deployment a lot simpler...

hmmm, let's see...

A decision in Prague means I should know better than to bring it up 
now.  That's interesting in a group that repeatedly DOESN'T follow 
it's own consensus (if it doesn't suit them or a particular author).

Case in point (and just one example of this) is from IETF 69 (that's 
less than 1 year ago), the WG decided "Presence" was the only event 
package to be used for location.

That didn't James Winterbottom and Martin Thomson from writing a new 
SIP event package for THIS IETF proposing a new event package for 
location, nor did it stop the GEOPRV Secretary (Richard Barnes) from 
strongly suggesting and backing the idea of this new event package to 
another SDO last week.

Seriously, if the Geopriv Secretary cannot follow his own WG's 
consensuses, how can we blame authors from following consensuses of 
the WG (i.e., James W and Martin).

Or did everyone NOT pay attention to that consensus when it was taken 
but me (the author of the Conveyance document that is stipulating the 
event package to be used)?

BTW -- regarding SIP and doing LCP-like things -- there is a new 
requirement from another SDO (which I mention by name in the agps and 
triangulation IDs) for persistent connections which look an awful lot 
like a subscription-based dialog -- something HTTP cannot do, nor can 
DHCP.  These IDs are suggesting we revisit the SIP as an LCP 
*because* of this new requirement, and that's the only reason these 
docs were written.

I guess the INTRO needs to be clearer in both IDs as to this 
requirement. I'll fix that in the next rev of both.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 17 Jul 2008 19:52:12 -0400

James,

With respect to the presence event package: The minutes from IETF 69 
reflect agreement that presence should be the only event package used 
for dereference of SIP location URIs:
"
* When asked if geopriv should provide constraints about event packages 
used for location, the room expressed
   - dereferencing may be done with presence
   - dereferencing may be done with other event packages
   - geopriv's recommendations focus on using presence
"

This agreement does not mean that presence is the only event package 
that will ever be used in a GEOPRIV specification.

In particular, my comment in our discussion noted that your proposals 
for using SIP for A-GPS and triangulation are distinct from the 
dereference usage reflected in the consensus above.  Therefore, it may 
be appropriate to use a diferent event package.

Just wanted to clarify that particular side point,
--Richard

James M. Polk wrote:
> now.  That's interesting in a group that repeatedly DOESN'T follow it's 
> own consensus (if it doesn't suit them or a particular author).
> 
> That didn't James Winterbottom and Martin Thomson from writing a new SIP 
> event package for THIS IETF proposing a new event package for location, 
> nor did it stop the GEOPRV Secretary (Richard Barnes) from strongly 
> suggesting and backing the idea of this new event package to another SDO 
> last week.
> 
> consensuses, how can we blame authors from following consensuses of the 
> WG (i.e., James W and Martin).
> 
> DHCP.  These IDs are suggesting we revisit the SIP as an LCP *because* 
> of this new requirement, and that's the only reason these docs were 
> written.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 18 Jul 2008 08:47:30 +0300

You mentioned the presence event package vs. the location event package: 
When trying to implement some of the features we couldn't figure out how 
to accomplish the semantic with SIP presence. Maybe a lack of 
misunderstanding on how SIP presence works or maybe a real issue. Don't 
know yet.

I don't understand your persistent connection requirement.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 18 Jul 2008 09:19:52 +0300

In the past when a requirement came up that couldn't be fulfilled by 
DHCP then a few folks just declared it as a non-valid requirement.
Example: Existing deployment of installed DSL routers not being able to 
forward DHCP options....

I just couldn't resist to highlight the inconsistent line of 
argumentation that lead us to create design teams and to spend a huge 
amount of time arguing why DHCP is not sufficient for all deployment 
environments. Now, when convenient for you then there is suddenly a 
requirement out there where DHCP couldn't be use and everything is fine. 
I really wish you could apply the same easy thinking when other people 
discover requirements for features that cannot be fulfilled with the 
existing solutions.

Just something to think about.

More a comment on the style of working rather than technical.

James M. Polk wrote:
> How about the requirements for this new functionality don't make sense 
> in DHCP.  Is that a good enough reason?
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 18 Jul 2008 16:31:29 -0500

At 04:11 PM 7/17/2008, Richard Barnes wrote:
>meaningful change to the SIP presence system.  It does so by 
>including a new type of information, which could introduce different 
>privacy risks.
>
>This extension is analogous to the transition between PIDF and 
>PIDF-LO:  You're still just putting a PIDF in SUB/NOT.  There are 
>two separate RFCs to deal with that extension (3693/3694).  So even 
>though you're just adding something to a PIDF (or PIDF-LO), there 
>might still be cause for some security and privacy discussions.

ok, so let me get this straight - and this goes directly to the firm 
comment you made on the WiMAX call Monday -- you claimed then that 
every single change in PIDF forces PIDF-LO to go back through the 
gauntlet of re-qualifying SIP as a "Using Protocol". Are you serious?

Where's the requirement for the snapshot of PIDF information that 
marks the point in time that Presence achieved this status (as a 
"Using Protocol"), with the understanding that for EVERY single 
extension to Presence from that moment forward it rescinds that 
status until some magical requalification takes place (from a new 
snapshot of Presence)?

You're proposing that any extension to PIDF, regardless of what SIP 
or SIPPING or SIMPLE does int he future - MUST require a new 
re-qualification of SIP to carry this PIDF as a message body.

How many others on this list agree with this undertaking?

I think we're making this out to be a bigger deal than it really 
is.  I think the "sniff test" should be all that's required, with 
things that smell odd getting a more thorough look at.

James

---

From: Richard Barnes <[email-masked]>
Date: Sat, 19 Jul 2008 21:49:35 -0400

James,

Not proposing that there's some sort of "gauntlet" that SIP/PIDF 
extensions need to run.  Just that we need to acknowledge the 
possibility of incremental privacy risks that they might introduce and 
consider how those risks should be mitigated.

All this is really saying is that using SIP presence doesn't give you a 
free pass for security and privacy considerations.  (SECDIR wouldn't let 
you have that pass anyway.)

--Richard

James M. Polk wrote:
>> meaningful change to the SIP presence system.  It does so by including 
>> a new type of information, which could introduce different privacy risks.
>>
>> PIDF-LO:  You're still just putting a PIDF in SUB/NOT.  There are two 
>> separate RFCs to deal with that extension (3693/3694).  So even though 
>> you're just adding something to a PIDF (or PIDF-LO), there might still 
>> be cause for some security and privacy discussions.
> 
> comment you made on the WiMAX call Monday -- you claimed then that every 
> single change in PIDF forces PIDF-LO to go back through the gauntlet of 
> re-qualifying SIP as a "Using Protocol". Are you serious?
> 
> Where's the requirement for the snapshot of PIDF information that marks 
> the point in time that Presence achieved this status (as a "Using 
> Protocol"), with the understanding that for EVERY single extension to 
> Presence from that moment forward it rescinds that status until some 
> magical requalification takes place (from a new snapshot of Presence)?
> 
> You're proposing that any extension to PIDF, regardless of what SIP or 
> SIPPING or SIMPLE does int he future - MUST require a new 
> I think we're making this out to be a bigger deal than it really is.  I 
> think the "sniff test" should be all that's required, with things that 
> smell odd getting a more thorough look at.
> 
> James
> 
> 
>> --Richard
>>
>> James M. Polk wrote:

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 20 Jul 2008 22:16:39 +0300

I believe the discussion we should have is
* do we want to define the term "Using Protocol" in a way that it is 
more precise OR
* we get rid of it.

We had many discussions around this "Using Protocol" term already and 
many of us just got confused by the terminology created by RFC 3693. 
Maybe the work on draft-barnes-geopriv-lo-sec 
<http://tools.ietf.org/id/draft-barnes-geopriv-lo-sec-03.txt> is a good 
opportunity to finally clean some things up.

Ciao
Hannes

PS: Note that this has nothing todo specifically with the documents 
James submitted recently. This is a more generic aspect.

James M. Polk wrote:
>> separate RFCs to deal with that extension (3693/3694).  So even 
> extension to Presence from that moment forward it rescinds that status 
> until some magical requalification takes place (from a new snapshot of 
> Presence)?
>
> I think we're making this out to be a bigger deal than it really is.  
> I think the "sniff test" should be all that's required, with things 
> that smell odd getting a more thorough look at.
>
> James
>
>
>> --Richard
>>
>> James M. Polk wrote:

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 22 Jul 2008 13:11:31 -0500

>* do we want to define the term "Using Protocol" in a way that it is 

I think a more concise definition is warranted, given Richard's 
comments that *any* change to any existing protocol that introduces 
new information requires a re-confirmation that this existing 
protocol has to run the gauntlet again (to being validated as a 
"Using Protocol").

That's a reeeeally high bar, and is absolutely not planned for in 
practice (i.e., in any charter). For example, where's the snapshot of 
SIP and SIMPLE that Location Conveyance will be judged against? What 
happens when SIP or SIMPLE extend themselves with a new PS RFC? Does 
that mean the snapshot Conveyance was determined against is no longer 
valid?  This is consisted with what Richard said to WiMAX last week.

(I understand few others heard that call, which is why I brought that 
discussion to this list)

I do believe we agree that DHCP and LLDP-MED are not Using Protocols, 
because of the lack of identifying information in the payload of the message.

At the same time, I currently don't trust any consensus reached by 
this WG, as it doesn't seem to matter to anyone (or enough folks)...

>We had many discussions around this "Using Protocol" term already 
>and many of us just got confused by the terminology created by RFC 
>3693. Maybe the work on draft-barnes-geopriv-lo-sec 
><http://tools.ietf.org/id/draft-barnes-geopriv-lo-sec-03.txt> is a 
>good opportunity to finally clean some things up.
>
>Ciao
>Hannes
>
>>>including a new type of information, which could introduce 
>>>different privacy risks.
>>>
>>>two separate RFCs to deal with that extension (3693/3694).  So 
>>>even though you're just adding something to a PIDF (or PIDF-LO), 
>>>there might still be cause for some security and privacy discussions.
>>
>>ok, so let me get this straight - and this goes directly to the 
>>firm comment you made on the WiMAX call Monday -- you claimed then 
>>that every single change in PIDF forces PIDF-LO to go back through 
>>the gauntlet of re-qualifying SIP as a "Using Protocol". Are you serious?
>>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 22 Jul 2008 13:24:57 -0500

At 06:52 PM 7/17/2008, Richard Barnes wrote:
>reflect agreement that presence should be the only event package 
>used for dereference of SIP location URIs:
>"
>* When asked if geopriv should provide constraints about event 
>packages used for location, the room expressed

if you have a copy of my presentation, and look at the notes, you'll 
see that the notes do *not* quite capture what the room said about 
the vote that was taken.

The choice was specifically
- to have presence do it
- let another event package do it
- let both do it

The room chose presence will be the one to do it, and not let the 
"location" event package be used to subscribe for location 
information (in a PIDF-LO).

I have the original preso; do you want to see it?

>In particular, my comment in our discussion noted that your 
>proposals for using SIP for A-GPS and triangulation are distinct 
>from the dereference usage reflected in the consensus 
>above.  Therefore, it may be appropriate to use a diferent event package.

I disagree. You have since moved to that position, but it isn't 
supported by any WG consensus, and should be said that way.

>>Case in point (and just one example of this) is from IETF 69 
>>(that's less than 1 year ago), the WG decided "Presence" was the 
>>only event package to be used for location.
>>That didn't James Winterbottom and Martin Thomson from writing a 
>>new SIP event package for THIS IETF proposing a new event package 
>>for location, nor did it stop the GEOPRV Secretary (Richard Barnes) 
>>from strongly suggesting and backing the idea of this new event 
>>package to another SDO last week.
>>Or did everyone NOT pay attention to that consensus when it was 
>>taken but me (the author of the Conveyance document that is 
>>stipulating the event package to be used)?
>>requirement from another SDO (which I mention by name in the agps 
>>and triangulation IDs) for persistent connections which look an 
>>awful lot like a subscription-based dialog -- something HTTP cannot 
>>do, nor can DHCP.  These IDs are suggesting we revisit the SIP as 
>>an LCP *because* of this new requirement, and that's the only 
>>reason these docs were written.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 22 Jul 2008 13:55:55 -0500

At 12:47 AM 7/18/2008, Hannes Tschofenig wrote:
>You mentioned the presence event package vs. the location event 
>package: When trying to implement some of the features we couldn't 
>figure out how to accomplish the semantic with SIP presence. Maybe a 
>lack of misunderstanding on how SIP presence works or maybe a real 
>issue. Don't know yet.
>
>

take my triangulation draft for a second, because it is easier to 
explain this one;

imagine an endpoint that sees multiple radio signals over a 
navigational system, be this a set of GPS satellites, or cell towers, 
or WiMAX towers.

The endpoint has this positioning information of each of the sources 
it can see (direction, angle, time, source identifier, etc), but in 
some very real cases, the endpoint isn't the one that runs the 
location determination algorithm, a location server (of some form) 
does this calculation.

Option#1 - The endpoint could send the server this information every 
single instance it moves, taking the bandwidth necessary to send this 
information to this server

or

Option#2 - this server could ask for a poll from the endpoint, 
attempting to either guess when the endpoint moves or just requesting 
an update a some interval in time

or

Option#3 - the location server could subscribe to the endpoint, state 
in that subscription what constitutes movement (i.e., defines it), 
and asked that the endpoint give an initial location plus an update 
every time it moves at least as far as the server said to look 
for.  This could be the server clearly defining to the endpoint "I 
don't want an update unless either 3 minutes passes, or you've moved 
more than 50 feet since the last update to me".

To me, it's clear that Option#3 is the most efficient, and requires 
the least amount of state at the server (because it is passively 
waiting for an answer whenever it has told the endpoint to update, it 
is not actively running timers - other for how long the subscription is for).

This is a persistent connection, as mentioned in both drafts, and in 
my messages on this list.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 22 Jul 2008 14:06:39 -0500

At 08:49 PM 7/19/2008, Richard Barnes wrote:
>possibility of incremental privacy risks that they might introduce 
>and consider how those risks should be mitigated.

This seems to me to be something your ID can talk about, as long as 
it's a look at the new information in the extension to SIP/Presence. 
But where do we record this"look" as being 'ok' or 'not ok' with the 
privacy concerns to Geopriv? I'm concerned about the formality of 
this, yet sympathetic to where I think you're going.

>All this is really saying is that using SIP presence doesn't give 
>you a free pass for security and privacy considerations.  (SECDIR 
>wouldn't let you have that pass anyway.)

yeah but... I'm wondering if SECDIR will have the awareness that a 
particular new feature/function breaks Geopriv privacy concerns - 
especially if a particular extension has nothing originally to do 
with location...

I agree in concept that there shouldn't be any free pass - but how do 
you propose monitoring occur that has a chance of success?

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 22 Jul 2008 17:54:37 -0500

One of my concerns with this is that there isn't enough detail in the document to be able to decide either way if this is even feasible.  For instance, how would you articulate a filter on GPS pseudoranges that would result in a meaningful result?  That is, what filter would you use that would be equivalent to a zone trigger, a distance-moved trigger, or a speed trigger?  The level of sophistication required is, to be quite honest, beyond what I've seen in either of your drafts.

Cheers,
Martin

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James M. Polk
> Sent: Wednesday, 23 July 2008 4:56 AM
> To: Hannes Tschofenig
> Cc: [email-masked]; Tschofenig,Hannes (NSN - FI/Espoo)
> Subject: Re: [Geopriv] Confused about draft-polk-geopriv-pidf-lo-4-
> agps-00.txt
> 

------------------------------------------------------------------------------------------------
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]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 22 Jul 2008 19:02:20 -0500

Hi James,

I don't understand the point of your option 3.
In your lead up to the options you indicate that the end-point doesn't
do the location determination, it does the measurement processing. In
options 1 and 2 this is fine. 

In option 3 however you have the end-point knowing how far it has moved,
and hence can know where it is. Why in this case would it report
measurements?

The other things that bothers me a bit with this approach is that in
WiMAX you will, in quite a number of cases, requires quite a few
measurement sets from the Target in order to do the location
determination, and the Target won't know ahead of time how many to
provide. Doing this with a subscription is going to be hard unless you
plan on timestamping all measurements since the last time you reported
and sending the whole lot to the LIS for consumption. At this point the
LIS will need to work out which ones to throw away, and which ones to
keep. The problem with this is two fold, information overload to the
LIS, and excessive battery drain on the Target. The latter problem comes
into play because making mobile scanning reports is not even close to
free.

A far better approach, is to go with option 2. Let the server poll when
it requires location, so measurement collection occurs when needed. If
the server doesn't get enough measurements, then it polls again until
such time as it either gives up, or gets what it needs.

Even if you go with option 3, you will still need to support option 2 in
order to ensure that the LIS can obtain sufficient measurements to
determine the location of the Target.

Cheers
James

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of James M. Polk
draft-polk-geopriv-pidf-lo-4-agps-
> 00.txt
> is not actively running timers - other for how long the subscription
is
> for).

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 24 Jul 2008 01:02:50 -0500

James

>and hence can know where it is. Why in this case would it report

in option #3 I state that the endpoint understands that at least one 
of its measurements is different by at least a set amount it was told 
to in the subscription. This doesn't mean the endpoint does the 
calculation to determine where it is.

>provide.

In the WiMAX example, it will more likely be the case that 
triangulation isn't used from the server, but A-GPS is used. In that 
case, the endpoint initiates the subscription, providing the A-GPS 
information to the server and asking that it provide back enough 
information that the endpoint can determine where it is (with the aid 
of knowing what the on-board) GPS knows.  Do you see this to be the 
more likely case in WiMAX?

>Doing this with a subscription is going to be hard unless you

If the LIS is only providing the get-over-the-hump information to the 
endpoint, the endpoint does its own calculation, in the A-GPS example, correct?

>such time as it either gives up, or gets what it needs.

With A-GPS, this can occur because the endpoint is in charge of the 
subscription, it can update its subscription as it sees fit, in the 
process, getting updates from the LIS when it needs it.

With A-GPS, I see the SUBSCRIBE going from the endpoint to the LIS 
(that means the NOTIFYs go from the LIS to the endpoint, with the 
endpoint knowing it needs
more information, and sending a new SUBSCRIBE within the same dialog).

With triangulation, the reverse is clearly more advantageous - which 
has the LIS subscribing to the endpoint, wanting to understand (get a 
NOTIFY) every time the endpoint detects it has moved.  Now, this 
realistically can have 100 updates a second - because one or more 
measurements changed, so the LIS needs to clarify what constitues 
"movement", by defining how much 1 or any measurement changes since 
the last update before sending a new NOTIFY with "hey, I just crossed 
the magic number of fractions of a degree (or feet or meters), here's 
a new measurement of all the signals I can see".  This method has the 
LIS doing the location determination of the endpoint, which doesn't 
know its own location throughout this set of transactions.

If in another, separate transaction, perhaps an LCP, sent the 
endpoint its LbyR, then all the endpoint does is either dereference 
that locationURI or hand out the LbyR to inform another entity where it is.

The Rulemaker exchange between the endpoint and the LIS (or Location 
Service - meaning this could be only to a Presence server) occurs 
through another transaction, most likely, and this occurs once, or 
anytime the rules change.  In the case that ihis is to a Presence 
server, the rules and the locationURI (or PIDF-LO if there has been a 
dereference already) would be sent in a SIP PUBLISH 
transaction.  This PUBLISH could have the AAA token in it, allowing 
the Presence server to interact with the LIS to have authorization to 
dereference the locationURI, so it has this information when asked by 
a watcher (that is, if the wartcher is authorized to get this information).

These are all separate transactions because they are doing separate things.

>determine the location of the Target.

I agree, but I believe strongly that these two options (2 and 3) are 
separate transactions, be that independent subscriptions, if these 
need to overlap in time.

James

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 24 Jul 2008 01:53:15 -0500

Martin

I agree the details regarding the filters within my 2 drafts here are 
still evolving, and I hadn't considered a speed trigger, which I 
think could be the most difficult of the 3 you listed below.

At 05:54 PM 7/22/2008, Thomson, Martin wrote:
>One of my concerns with this is that there isn't enough detail in 
>the document to be able to decide either way if this is even 
>feasible.  For instance, how would you articulate a filter on GPS 
>pseudoranges that would result in a meaningful result?  That is, 
>what filter would you use that would be equivalent to a zone 
>trigger, a distance-moved trigger, or a speed trigger?  The level of 
>sophistication required is, to be quite honest, beyond what I've 
>seen in either of your drafts.
>
>Cheers,
>Martin
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 28 Jul 2008 01:23:03 -0500

Hi James,

My responses are inline, and I have nipped bits not of interest.

> calculation to determine where it is.

[AJW] The problem is that almost all end-points don't work like this.
They know the distance they have moved because they have the start and
end-locations.

> more likely case in WiMAX?

[AJW] Not necessarily no, and if we are talking about inside then
certainly not. I think it very likely that I will have a NIC card in my
laptop that supports 802.16, much as I do for 802.11 today. I therefore
expect that card to be capable of measuring and reporting 802.16
scanning reports, I don't necessarily also expect it to have an A-GPS
chip in it, though it may. Since I must implement a pull for the
measurements (we agree to this below), why not simply always do this? 

> endpoint, the endpoint does its own calculation, in the A-GPS example,

[AJW] MSRs can only be combined with A-GPS measurements to arrive at
location in the LIS. You seem to be muddling what MSRs give you, and
where they can be used, and how they can be combined with other
measurements. 

A-GPS is one technology and it is totally independent of MSRs. Depending
on the information requested, A-GPS data can remain good for hours, or
using some extensions, even days. Subscribing to data that is good for
that long, over simply requesting it when needed seems a totally
unnecessary overhead and I remain totally unconvinced that you obtain
any economies of scale by subscribing for this information, in fact I
would argue you waste resources on the LIS with this approach. 
 
> process, getting updates from the LIS when it needs it.

[AJW] But we are back to the old request response paradigm that we have
already had in the forum at least 3 times.

> know its own location throughout this set of transactions.

[AJW] Okay let me try again. The types of measurements you are talking
about are not free, they require the SS to specifically turn on and
engage with additional base stations. They don't do this all the time,
they do it as required because it is a significant drain on the battery
of the device. So there is a fundamental flaw in your logic here. The
device should only do this when the server asks it to do it, and that
should only be when an application requires that update. Subscription is
one way to do the timing, but it can equally well be done on an as needs
basis by the application polling for it, and this latter solution works
in all cases.

> These are all separate transactions because they are doing separate
things.

[AJW] I am suffering from Mondayitis, I am not sure what you are getting
at here.
 
> separate transactions, be that independent subscriptions, if these

[AJW] I guess I see the overhead of a subscription and associated
session as unwarranted when a poll will do everything you want.

> > > >>>have you been missing years of discussions around L7 LCPs?
Henning
> >even
> > > >>>Based on the decisions in Prague the group decided to go for
HELD
> >and
>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------