Subject: Re: [Ecrit] Phone BCP: Multiple Location

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 1 Apr 2008 15:32:38 -0500

Hi Barbara,

I will chop a bunch of stuff out now

<----Snip ------>

My statement on LLDP-MED and DHCP was that the location sent by those
protocols does not arrive at the end device in PIDF-LO format. I was
mentioning that the PIDF rules on prioritizing received PIDF locations
state that they apply to received PIDF locations. LLDP-MED and DHCP
locations are not received by the end device as PIDF locations.
Therefore the rules do not apply. They are also not received "together".
Therefore, the rules do not apply. If recommendations are needed for
handling multiple locations at an end device (and I believe they are),
then I am saying that the PIDF rules are necessary (for multiple PIDF
received together) but insufficient (for multiple locations gotten in a
variety of ways), and that the PIDF document is the wrong place for
comprehensive  recommendations that take into account a variety of
permutations of how devices get location.
Barbara

[AJW]
PIDF-LO profile does say that if you get locations form different sources and you want to construct them into a PIDF-LO, what you need to do to do that, and that you need to put the location you consider best in first, that way the recipient can have a consistent way of interpreting what the originator was trying to tell them. PIDF-LO profile doesn't say how you determined which of these locations from different sources is best, and I don't think it can.
Is it this latter piece of information you are seeking?

Cheers
James

------------------------------------------------------------------------------------------------
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]

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

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 2 Apr 2008 08:14:25 -0400

--- snip -----------
PIDF-LO profile doesn't say how you determined which of these locations
from different sources is best, and I don't think it can.
Is it this latter piece of information you are seeking?
--- end snip -------

Yes. But in the form of a default recommendation that can be used in the
absence of any "real" knowledge. 
Barbara

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 03 Apr 2008 00:30:11 -0500

Barbara

Isn't this a rulemaker decision (i.e., a policy configured in the 
LG/LS as to which to include or merge)?

I think this should be the case.

For example, AT&T (yeah, I'm picking on your company for no 
particular reason) might have a policy to trust any LLDP-MED LCI over 
DHCP LCI.  In this case an AT&T device constructs the PIDF-LO from 
LLDP-MED if it used that LCP.

Conversely, Sprint might have a policy stating that if there is a 
local GPS chip measuring location for the device, construct the 
PIDF-LO from that LI over anything else received.

I think this is domain specific, based on the policy of the 
significant rulemaker (which should have some say so from the user, 
but maybe not in this case - because Joe Citizen doesn't know the 
difference or preference of the underlying network)...

(the other) James

At 07:14 AM 4/2/2008, Stark, Barbara wrote:

>The information transmitted is intended only for the person or 
>entity to which it is addressed and may contain confidential, 
>proprietary, and/or privileged material. Any review, retransmission, 
>dissemination or other use of, or taking of any action in reliance 
>upon this information by persons or entities other than the intended 
>recipient is prohibited. If you received this in error, please 
>contact the sender and delete the material from all computers. GA623
>
>

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 3 Apr 2008 13:25:05 -0700

[snip]
> On Behalf Of Winterbottom, James
> Sent: Monday, March 31, 2008 7:46 PM
...
> I think the correct answer is that it should only try 3 
> methods if the first 2 failed. That is, it tries one method, 
> if that doesn't work, it tries the next one.
[/endsnip]

I agree with you James, this seems practicle... but phonebcp recommends
an opposite approach (along with your suggested approach).

   ED-22/INT-15 Endpoints SHOULD try all LCPs supported by the device in
   any order or in parallel.  The first one that succeeds in supplying
   location can be used. 

I think it would be cleaner if Phonebcp recommended serial queries only
- therefore avoiding most of the worry around choosing among different
locations gotten from parallel requests.

-roger. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Winterbottom, James
> Sent: Monday, March 31, 2008 7:46 PM
> To: Stark, Barbara; Hannes Tschofenig; [email-masked]
> Subject: Re: [Ecrit] Phone BCP: Multiple Location
> 
> Hi Barbara,
> 
> Having re-read your email I think I misunderstood what you 
> were saying.
> I think what you are saying is that if a device engages all 
> three LCPs and gets a different location for each of them, 
> what does it do?
> 
> I think the correct answer is that it should only try 3 
> methods if the first 2 failed. That is, it tries one method, 
> if that doesn't work, it tries the next one.
> 
> In the HELD routing/dispatch example I hope that we can say 
> always use dispatch since the dispatch location kind of needs 
> to fall into the catchment of the routing area to make any sense.
> 
> I think we should avoid trying to get as many different 
> locations as we can.
> 
> As for DHCP and LLDP-MED I am not sure that I understand your 
> last sentence in the first paragraph. I am not aware that we 
> considering sending a literal location in any form other than 
> a PIDF-LO with the sos message.
> 
> Cheers
> James
>   
> 
> > -----Original Message-----
> > From: Stark, Barbara [mailto:[email-masked]]
> > Sent: Tuesday, 1 April 2008 1:30 PM
> > To: Winterbottom, James; Hannes Tschofenig; [email-masked]
> > Subject: RE: [Ecrit] Phone BCP: Multiple Location
> > 
> > Key words are "Where multiple PIDF documents can be sent or 
> received 
> > together". When a device has a configured location, a location from 
> > LLDP-MED, one from DHCP, and one or two (routing and dispatch) from 
> > HELD, I think that the quoted language has no relevance on the order
> in
> > which these are then included in an "sos" message. These different 
> > locations were not received together. LLDP-MED and DHCP 
> locations are 
> > not received as PIDF documents.
> > 
> > This language does apply to the PSAP when it receives all of these 
> > locations. They arrive together, and all in PIDF format.
> > Barbara
> > 
> > -----Original Message-----
> > From: Winterbottom, James [mailto:[email-masked]]
> > Sent: Monday, March 31, 2008 4:29 PM
> > To: Stark, Barbara; Hannes Tschofenig; [email-masked]
> > Subject: RE: [Ecrit] Phone BCP: Multiple Location
> > 
> > Nope.
> > 
> > This is from PIDF-LO Profile
> > 
> > " Rule #9:  Where multiple PIDF documents can be sent or received
> >       together, say in a multi-part MIME body, and current location
> >       information is required by the recipient, then document
> selection
> >       SHOULD be based on document order, with the first document 
> > considered first."
> > 
> > Cheers
> > James
> > 
> > 
> > 
> > -----Original Message-----
> > From: Stark, Barbara [mailto:[email-masked]]
> > Sent: Mon 3/31/2008 8:05 AM
> > To: Winterbottom, James; Hannes Tschofenig; [email-masked]
> > Subject: RE: [Ecrit] Phone BCP: Multiple Location
> > 
> > It's my understanding that PIDF-LO only describes multiple location 
> > precedence within a single message. It doesn't describe how to 
> > prioritize multiple locations received from various  
> sources, received 
> > in multiple messages (or statically configured) at various times.
> > 
> > I did include that sort of logic in my latest DSLF draft. 
> If there is
> a
> > desire to have some of this in phonebcp, I'm fine with that.
> > Barbara
> > 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Winterbottom, James
> > Sent: Sunday, March 30, 2008 4:36 PM
> > To: Hannes Tschofenig; [email-masked]
> > Subject: Re: [Ecrit] Phone BCP: Multiple Location
> > 
> > PIDF-LO profile describes how to choose the correct location for
> exactly
> > this purpose.
> > That is the application form which the original requirements were
> drawn.
> > 
> > 
> > -----Original Message-----
> > From: [email-masked] on behalf of Hannes Tschofenig
> > Sent: Sun 3/30/2008 2:55 PM
> > To: [email-masked]
> > Subject: [Ecrit] Phone BCP: Multiple Location
> > 
> > "
> >    ED-39 If a UA has more than one location available to it, it MUST
> >    choose one location to route the call towards the PSAP.
> > 
> >    SP-16 If a proxy inserts location on behalf of an 
> endpoint, and it
> >    has multiple locations available for the endpoint it MUST choose
> one
> >    location to use to route the call towards the PSAP.
> > "
> > 
> > I could imagine that someone might ask how to make a decision.
> > So, how does the decision making look like?
> > 
> --------------------------------------------------------------
> ----------
> > ------------------------
> > 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.
> >
> --------------------------------------------------------------
> ----------
> > ------------------------
> > [mf2]
> > 
> --------------------------------------------------------------
> ----------
> > ------------------------
> > 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.
> >
> --------------------------------------------------------------
> ----------
> > ------------------------
> > [mf2]
> > 
> > 
> > *****
> > 
> > The information transmitted is intended only for the person 
> or entity
> to
> > which it is addressed and may contain confidential, proprietary,
> and/or
> > privileged material. Any review, retransmission, dissemination or
> other
> > use of, or taking of any action in reliance upon this 
> information by 
> > persons or entities other than the intended recipient is prohibited.
> If
> > you received this in error, please contact the sender and 
> delete the 
> > material from all computers. GA622
> > 
> > 
> 

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 3 Apr 2008 16:37:50 -0400

Roger, James,

You are simply moving the problem.  You are stating you don't want to tax
the target by making it chose between multiple locations, but you are asking
the target to chose between multiple LCP mechanisms.   I don't see any
difference in the algorithm between choosing between multiple locations or
choosing between multiple LCPs.

Am I missing something?

-Marc-  

> methods if the 
> > first 2 failed. That is, it tries one method, if that 
> doesn't work, it 
> > tries the next one.
> [/endsnip]
> 
> I agree with you James, this seems practicle... but phonebcp 
> recommends an opposite approach (along with your suggested approach).
> 
> - therefore avoiding most of the worry around choosing among 
> different locations gotten from parallel requests.
> 
> -roger. 
> 
> > Having re-read your email I think I misunderstood what you were 
> > saying.
> three LCPs 
> > and gets a different location for each of them, what does it do?
> > 
> methods if the 
> > first 2 failed. That is, it tries one method, if that 
> doesn't work, it 
> > tries the next one.
> > 
> always use 
> > dispatch since the dispatch location kind of needs to fall into the 
> > catchment of the routing area to make any sense.
> > 
> locations as 
> > we can.
> > As for DHCP and LLDP-MED I am not sure that I understand your last 
> > sentence in the first paragraph. I am not aware that we considering 
> > sending a literal location in any form other than a PIDF-LO 
> with the 
> > sos message.
> > 
> > Cheers
> > James
> >   
> > 
> > ----------------------------------
> > ----------------------------------
> > [mf2]
> > 
> CONFIDENTIALITY NOTICE: The information contained in this 
> message may be privileged and/or confidential. If you are not 
> the intended recipient, or responsible for delivering this 
> message to the intended recipient, any review, forwarding, 
> dissemination, distribution or copying of this communication 
> or any attachment(s) is strictly prohibited. If you have 
> received this message in error, please notify the sender 
> immediately, and delete it and all attachments from your 
> computer and network.
>

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 4 Apr 2008 12:34:15 -0700

My objection is to a written *recommendation* that directs the client to
act serially OR act in parallel - as opposed to what, (guessing, since
not stated) recommending an ordered list of configuration protocol
candidates?  

Better to recommend one thing to do, allow another.

-roger.

> From: Marc Linsner [mailto:[email-masked]] 
> Sent: Thursday, April 03, 2008 1:38 PM
> To: Roger Marshall; 'Winterbottom, James'; [email-masked]
> You are simply moving the problem.  You are stating you don't 
> want to tax the target by making it chose between multiple 
> locations, but you are asking
> difference in the algorithm between choosing between multiple 
> locations or choosing between multiple LCPs.
> 
> Am I missing something?
> 
> -Marc-  
> 
> > 
> > [snip]
> >    ED-22/INT-15 Endpoints SHOULD try all LCPs supported by 
> the device 
> > in
> message may 
> > be privileged and/or confidential. If you are not the intended 
> > recipient, or responsible for delivering this message to 
> the intended 
> > recipient, any review, forwarding, dissemination, distribution or 
> > copying of this communication or any attachment(s) is strictly 
> > prohibited. If you have received this message in error, 
> please notify 
> > the sender immediately, and delete it and all attachments from your 
> > computer and network.
> >

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 4 Apr 2008 16:37:51 -0400

Roger,

How would you evaluate which LCP to try first?  I assume that you would
recommend the host stop trying if any resemblance of LCI was returned?

I agree that receiving multiple LCIs is a problem, but I don't see how you
can predetermine which LCP is going to return the 'best' information.  I
think you must try them all, if you get multiples, they have to be
evaluated, even if that means presenting them to the user.

-Marc-

> 
> My objection is to a written *recommendation* that directs 
> the client to act serially OR act in parallel - as opposed to 
> what, (guessing, since not stated) recommending an ordered 
> list of configuration protocol candidates?  
> 
> > You are simply moving the problem.  You are stating you 
> don't want to 
> > tax the target by making it chose between multiple 
> locations, but you 
> > are asking
> > > I think it would be cleaner if Phonebcp recommended 
> serial queries 
> > > only

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 4 Apr 2008 14:21:18 -0700

Marc:
I would imagine that some service providers would have more confidence
(no pun intended) in one method vs. another, but acknowledge would be a
problem on a level playing field.

I didn't see any 'best practice' as to,
1. how a device picks one of three potential locations, or
2. picks from 3 potentially different SIP URIs returned by LoST based on
multiple locations input

I guess we could dream something up - somebody will have to... We could,

-- pick civic based on uncertainty (whoops, civic doesn't have
uncertainty)
-- pick between '125 River Rd.', '125 River Rd. E' and '125 River Rd. W'
(any of the 3 may be valid, could even be on different sides of the
river)
-- two civics and a geo (e.g., from agps) - does the majority win out,
or precise locations trump all others?
-- manually provisioned (given) civic vs. CellSectorID civic?
-- three geo's with increasing uncertainty - do you pick the one w/the
smallest or largest uncertainty value (safer to err on the side of
conservativeness)?

To differentiate multiple LoST responses, we could go with, choose best
2 out of 3, what happens if all 3 are not the same?

Lots of scenarios exist.  More important than, 'where do we move the
problem', I think that there needs to be some discussion on best
practices for 'how to choose'.

-roger marshall.

> Sent: Friday, April 04, 2008 1:38 PM
> To: Roger Marshall; [email-masked]
> How would you evaluate which LCP to try first?  I assume that 
> you would recommend the host stop trying if any resemblance 
> of LCI was returned?
> 
> I agree that receiving multiple LCIs is a problem, but I 
> don't see how you can predetermine which LCP is going to 
> return the 'best' information.  I think you must try them 
> all, if you get multiples, they have to be evaluated, even if 
> that means presenting them to the user.
> 
> -Marc-
> 
>  
> 
> > 
> the client 
> > to act serially OR act in parallel - as opposed to what, (guessing, 
> > since not stated) recommending an ordered list of configuration 
> > protocol candidates?
> >

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 4 Apr 2008 17:50:12 -0400

First of all, I thought we started by trying LCPs until we got an answer.

Then I think our advice is that an LCP returns it's most precise location if
I has more than one, and never converts.  A LIS should never leave a user
with a choice.  It chooses.

Then, if the endpoint has more than one anyway, it has to choose.

If a proxy is inserting, and it has more than one, it has to choose.

While I could imagine a complex set of rules designed to choose the best
based on civic vs geo and confidence/uncertainty, I think we need a very
simple tiebreaker.  I think that we should work towards never being in this
situation rather than trying to optimize what we do when we are in it.

So, I think the best answer is, if you really have more than one, and you
don't have any basis to choose, make a random choice.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roger Marshall
Sent: Friday, April 04, 2008 5:21 PM
To: Marc Linsner; [email-masked]
Subject: Re: [Ecrit] Phone BCP: Multiple Location

Marc:

-roger marshall.

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 5 Apr 2008 00:27:17 -0500

Actually, if a LIS has more than one answer it may provide more than one answer, but it MUST return the PIDF-LO based on PIDF-LO profile, so there is no ambiguity as which location to send to LoST. This problem is less of an issue for DHCP, as they specifications already say that the user must explicitly ask it, so that should take care of the multiple problem to some extent.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Brian Rosen
Sent: Fri 4/4/2008 4:50 PM
To: 'Roger Marshall'; 'Marc Linsner'; [email-masked]
Subject: Re: [Ecrit] Phone BCP: Multiple Location

Brian

-----Original Message-----

Marc:

-roger marshall.

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 5 Apr 2008 09:29:30 -0400

I'm not arguing that a LIS may not, under any circumstances, provide more
than one answer.  I'm saying that for emergency services, it should not do
that.  In the case we're describing, the LIS is closer to the origin of the
data, and has a much better idea than any downstream entity what is the most
appropriate answer.  It should return the best answer, within the
constraints of the protocol and what the user specified.

I don't see this as a really practical problem, because it's pretty hard to
imagine the circumstance where it exists.  If the LCP is DHCP or LLDP-MED,
as you say, you only return what was asked for.  In HELD, for emergency use,
the client would specify the purpose, and the LIS would only have one
answer.

Nevertheless, we have to say what happens if you do get more than one.
Order when it comes from a PIDF is fine.  Random when you don't have order
to assist you is also fine.

Brian

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Saturday, April 05, 2008 1:27 AM
To: Brian Rosen; Roger Marshall; Marc Linsner; [email-masked]
Subject: RE: [Ecrit] Phone BCP: Multiple Location

Actually, if a LIS has more than one answer it may provide more than one
answer, but it MUST return the PIDF-LO based on PIDF-LO profile, so there is
no ambiguity as which location to send to LoST. This problem is less of an
issue for DHCP, as they specifications already say that the user must
explicitly ask it, so that should take care of the multiple problem to some
extent.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of Brian Rosen
Sent: Fri 4/4/2008 4:50 PM
To: 'Roger Marshall'; 'Marc Linsner'; [email-masked]
Subject: Re: [Ecrit] Phone BCP: Multiple Location

Brian

-----Original Message-----

Marc:

-roger marshall.

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------
[mf2]