Subject: [Ecrit] multiple location sources

From: "Karl Heinz Wolf" <[email-masked]>
Date: Mon, 24 Sep 2007 11:49:08 +0200

Hi,
I'm working on a prototype SIP client that should be able to determine
its location by DHCP, HELD and LLDP-MED. The PIDF-LO document is
included in the SIP INVITE body. I have several questions about what
to do when there is more than one location source available.

draft-ietf-sip-location-conveyance-08 recommends that there is only
one location. Of course, all ways of location determination should
give the same location. But how can one verify if the same location
was received via HELD and DHCP since a different format is used?

Or when one gets two DHCP civic location messages via two different
interfaces and some of the CAvalues are the same, but some not (e.g.
one has an additional location information, the other has a building
CAType). Is this the same location?

Or think of the following situation. One gets a DHCP location
information via a wired connection (the location of the DHCP server in
this building) and a LLDP-MED frame via WLAN of an access point in the
next building (the location of the access point is announced).
draft-ietf-geopriv-pdif-lo-profile-08 gives some rules for multiple
location information, but how can the device know which information is
more adequate to get the right order?

rfc4776 has a table with a mapping of CATypes and PIDF. When conveying
location information in SIP messages, a PIDF document is needed. So,
what to do with CATypes that have no mapping to PIDF?

LLDP-MED has a "what" element, describing if the location of the
client itself, of the DHCP server or of the network element closest to
the client is provided. This seems to be useful information, but where
to put this in a PIDF document?

I'm looking forward to your comments and suggestions.

Ciao
Karl Heinz

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 24 Sep 2007 05:10:19 -0500

Hi Karl,

Please see my comments inline.

Cheers

James

> -----Original Message-----

> From: Karl Heinz Wolf [mailto:[email-masked]]

> Sent: Monday, 24 September 2007 7:49 PM

> To: ecrit

> Subject: [Ecrit] multiple location sources

[AJW] My first question is why are you using more than one acquisition
protocol. My thoughts would be use one, if it fails, pick a different
one. Never invoke both at the same time so you have this problem of
choice.

> CAType). Is this the same location?

[AJW] Your device will generally favour one net connection over another.
For example my PC has both WiFi and wired Ethernet, if I have access to
wired Ethernet it uses that. But regardless your SIP client should use
the location provided to it over the link it plans to initiate the call
over.

[AJW] See above, I think this is the same solution.

[AJW] Revised Civic should have taken care of any problems here. If you
have a CAType that is not addressed by revised civic speak now please.

[AJW] You can use the Device or Person fields in PIDF for this I think.
Though we may need to define URN for them.

> https://www1.ietf.org/mailman/listinfo/ecrit

------------------------------------------------------------------------------------------------
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://www1.ietf.org/mailman/listinfo/ecrit

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Sep 2007 12:27:56 +0200

Hi Karl Heinz,

a quick response below:

Karl Heinz Wolf wrote:
> one location. 

I believe (and I stated it already many times) that the SIP Location 
Conveyance document should point to the PIDF-LO profile draft and should 
be silent about this issue since it only leads to confusion. Still, that 
has not been done ....

> Of course, all ways of location determination should
There are a couple of issues:
* The encoding is different
* The mapping might lead to a different location (see the recent 
discussion in GEOPRIV and some of the mappping attempts in PIDF-LO profile)
* The data might not be in sync between the HELD server and the 
information that is returned via DHCP.

Hence, I agree with you that you might receive location information 
describing the same location but looking differently. Depending on the 
application (e.g., emergency services) I believe the client should not 
attempt to figure out whether the obtained location information is 
actually pointing to the same location.
For some other applications you might just show it to the user on a map 
and they will easily be able to figure out which one is the most 
accurate one.
> CAType). Is this the same location?
Typically, it will refer to the same location. However, there is 
obviously the chance that the received information is different since 
the different interfaces might refer to different link layer 
technologies (e.g., Ethernet and UMTS) and hence the location format, 
the shapes and the location determination technology could be different.

> more adequate to get the right order?
As I mentioned for some applications the best approach is to just put 
everything into the PIDF-LO and indicate how the info was obtained 
(using the method element). For others it might be useful todo some

What application are you looking at?

> what to do with CATypes that have no mapping to PIDF?
Have you looked at the revised civic document: 
http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-revised-civic-lo/
This document also provides a table of the CATypes and the elements used 
in XML

There should be no CAType where no corresponding element exists.

> to put this in a PIDF document?
The "what" element describes to which element the location refers to. In 
a PIDF-LO the entity element is actually the place where the identity 
information of the element is that the location refers to. I would put 
the MAC address of the access point (or whatever it is) in there.

I believe that this is the right way. Unfortunately, the entity element 
expects a URN but I haven't found a URN scheme that is allowed to carry 
MAC addresses or  IP addresses. James, Henning and myself are still 
looking at this issue.

> I'm looking forward to your comments and suggestions.
Thanks for your feedback.

Ciao
Hannes

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Mon, 24 Sep 2007 14:16:09 +0200

On 9/24/07, Winterbottom, James <[email-masked]> wrote:
> protocol. My thoughts would be use one, if it fails, pick a different one.
> Never invoke both at the same time so you have this problem of choice.
>

So just try each method and take only the first result?

[AJW] Revised Civic should have taken care of any problems here. If you have
> a CAType that is not addressed by revised civic speak now please.
>

thanks for pointing me to this document, I have overlooked it completely.

> Though we may need to define URN for them.
Is this already mentioned in any document? I couldn't find anything.

thanks for your comment.

Cheers
karl heinz

---

From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <[email-masked]>
Date: Mon, 24 Sep 2007 14:28:23 +0200

Hi James, 
Hi Karl Heinz, 

Quick comments below (marked as [hannes]):

________________________________

	Von: ext Winterbottom, James
[mailto:[email-masked]] 
	Gesendet: Montag, 24. September 2007 12:10
	An: Karl Heinz Wolf; ecrit
	Betreff: RE: [Ecrit] multiple location sources

	Hi Karl,

	Cheers

	James

	[AJW] My first question is why are you using more than one
acquisition protocol. My thoughts would be use one, if it fails, pick a
different one. Never invoke both at the same time so you have this
problem of choice.

[hannes]
	That's certainly a good question. Still, you might use different
protocols on different physical interfaces. 

	> CAType). Is this the same location?

	[AJW] Your device will generally favour one net connection over
another. For example my PC has both WiFi and wired Ethernet, if I have
access to wired Ethernet it uses that. But regardless your SIP client
should use the location provided to it over the link it plans to
initiate the call over.

[hannes] There is no document that states such an assumption. 

	 

	[AJW] Revised Civic should have taken care of any problems here.
If you have a CAType that is not addressed by revised civic speak now
please.

	[AJW] You can use the Device or Person fields in PIDF for this I
think. Though we may need to define URN for them.

[hannes] 

	James is referring to the 'entity' attribute inside the
<presence> element, see Section 4.1.1 of
http://www.ietf.org/rfc/rfc3863.txt

	Ciao
	Hannes

	 

	> https://www1.ietf.org/mailman/listinfo/ecrit

	
------------------------------------------------------------------------
------------------------
	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: "Stark, Barbara" <[email-masked]>
Date: Mon, 24 Sep 2007 08:42:21 -0400

Some of these are questions I was trying to address in the draft
document liaised from the DSL Forum to IETF 
(see http://www1.ietf.org/mail-archive/web/geopriv/current/msg04297.html
for link to documents), because I hadn't seen them addressed elsewhere.
I'd be curious to hear if you find the flows in that document at all
useful. I suggest in there that, in the absence of real intelligence for
selecting one location from multiple, that locations received from lower
layers should be given preference over locations received from higher
layers. When multiple locations are received using the same protocol,
then the first received should be used. But this is for a particular
physical interface. 

In the case of multiple physical interfaces, I suggest that the device
should keep its location per physical interface. A call that goes out
over a particular interface, should use the location associated with
that interface.

Again, this is suggested for the case where there is nothing on which to
base an informed decision.
Barbara

-----Original Message-----
From: Karl Heinz Wolf [mailto:[email-masked]] 
Sent: Monday, September 24, 2007 5:49 AM
To: ecrit
Subject: [Ecrit] multiple location sources

Hi,

Ciao
Karl Heinz

*****

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. GA621

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 24 Sep 2007 08:48:51 -0400

It's not always desirable to wait for a protocol to time-out, before
launching the next protocol. Specifically, if a device is configured to
do DHCP for IP address configuration, it should launch its DHCP
discovery ASAP, with options, instead of waiting the 4 or 5 seconds for
LLDP-MED to time out. This prevents unnecessary delays in the bootstrap
process. It should be easy enough for the device to use a received
LLDP-MED location, even if it arrives after the DHCP response.
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: "Karl Heinz Wolf" <[email-masked]>
Date: Mon, 24 Sep 2007 14:50:39 +0200

hi Hannes

thanks for your answer.

> (using the method element). For others it might be useful todo some

todo some ??? I think the rest of the sentence is missing here.

> What application are you looking at?

Emergency Calls.

> This document also provides a table of the CATypes and the elements used

no, I haven't looked at this table, thanks for reminding me of that.

> MAC addresses or  IP addresses. James, Henning and myself are still

I think there should be a way for the receiver of the location
information to distinguish a PIDF-LO document describing the location
of the client itself form a PIDF containing the location of a nearby
network element.

So you would rather collect the date from all methods of location
determination on all interfaces? But create a seperate PIDF-LO
document for each or put all in one?

cheers
Karl Heinz

---

From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <[email-masked]>
Date: Mon, 24 Sep 2007 14:50:55 +0200

Barbara, that's a very good hint to look at that document. 

It might, however, matter only to a large extend when Karl Heinz is focusing on emergency services since a lot of the text is indeed emergency service specific; isn't it.

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: ext Stark, Barbara [mailto:[email-masked]] 
> Gesendet: Montag, 24. September 2007 14:42
> (see 
> http://www1.ietf.org/mail-archive/web/geopriv/current/msg04297.html
> 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. GA621
> 
> 
>

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 24 Sep 2007 08:57:40 -0400

True. Fortunately, he responded to you saying that he *is* looking at emergency services. :-)
My guess is, that other applications will either need to have data for that informed decision that I mention in my email, or they'll decide to use the same logic as for emergency service location.
Barbara 

-----Original Message-----
From: Tschofenig, Hannes (NSN - DE/Germany - MiniMD) [mailto:[email-masked]] 
Sent: Monday, September 24, 2007 8:51 AM
To: Stark, Barbara; Karl Heinz Wolf; ecrit
Subject: AW: [Ecrit] multiple location sources

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 24 Sep 2007 09:13:18 -0400

I have addressed this in -phonebcp, where it now says:
ED-22 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.

AN-13 Access networks that support more than one LCP MUST reply with the
same location information (within the limits of the data format for the
specific LCP) for all LCPs it supports.ED-35 If a UA has more than one
location available to it, it MUST choose one location to use to route the
call towards the PSAP.

SP-15 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.

SP-16 If a proxy is attempting to assert location but the UA conveyed a
location to it, the proxy must use the UA?s location for routing and MUST
convey that location towards the PSAP. It MAY also include what it believes
the location to be.

SP-17 All location objects received by a proxy MUST be delivered to the
PSAP.

ED-36/SP-18 Location objects MUST contain information about the method by
which the location was determined, such as GPS, manually entered, or based
on access network topology included in a PIDF- LO ?method? element. In
addition, the source of the location information MUST be included in a
PIDF-LO "provided-by" element.

ED-37/SP-19 The "used-for-routing" parameter MUST be set to the location
that was used to query LoST.

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Monday, September 24, 2007 8:58 AM
> To: Tschofenig,Hannes (NSN - DE/Germany - MiniMD); Karl Heinz Wolf; ecrit
> Subject: RE: [Ecrit] multiple location sources
> 
> My guess is, that other applications will either need to have data for
> that informed decision that I mention in my email, or they'll decide to
> use the same logic as for emergency service location.
> Barbara
> 
> It might, however, matter only to a large extend when Karl Heinz is
> focusing on emergency services since a lot of the text is indeed emergency
> service specific; isn't it.
> 
> Ciao
> Hannes
> 
>

---

From: [email-masked]
Date: Mon, 24 Sep 2007 12:48:45 -0400

Hi,
I agree that the DSL Forum document makes a very good starting point for 
orderly acquisition of location at startup, accounting for all 3 methods. 
I also believe it points to a preference order, if there are multiple 
answers coming back, which is LLDP-MED --> DHCP --> HELD.  Reasoning for 
this order (my opinion) is that it progresses from "least moving parts" / 
most reliable (LLDP-MED) to most, and also follows the natural layering of 
the overall system (L2 --> L2.5 --> L7).   In the end, only ONE method 
should ever be selected, as the sequence diagram shows. 

Your point below, that the methods can and should progress in parallel is 
valid.  However there are constraints to this, notably: 

o If LLDP-MED is being used to autoconfigure voice VLAN ID, then the 
device should wait to see if that stage succeeds before contacting DHCP. 
Otherwise, the device may get an IP address on the default VLAN, only to 
have to drop it and try again on the voice VLAN.  If it had started to use 
this address for something already (say for HELD), then ongoing 
interaction would be dropped and confusion would likely ensue. 

o Before HELD can work, an IP address is needed. 

I think these constraints are really just a reflection of the natural 
layering in the end. 

IMHO, orderly startup beats the few extra seconds delay incurred in making 
sure the constraints are not broken.   We are only talking about a very 
few seconds here after all. 

-- Peter 

"Stark, Barbara" <[email-masked]>
24.09.07 08:48
 
        To:     "Winterbottom, James" <[email-masked]>, 
"Karl Heinz Wolf" <[email-masked]>, "ecrit" <[email-masked]>
        cc: 
        Subject:        RE: [Ecrit] multiple location sources

It's not always desirable to wait for a protocol to time-out, before 
launching the next protocol. Specifically, if a device is configured to do 
DHCP for IP address configuration, it should launch its DHCP discovery 
ASAP, with options, instead of waiting the 4 or 5 seconds for LLDP-MED to 
time out. This prevents unnecessary delays in the bootstrap process. It 
should be easy enough for the device to use a received LLDP-MED location, 
even if it arrives after the DHCP response.
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
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 24 Sep 2007 16:22:01 -0400

I'm not sure how you decided that LLDP-MED has fewer moving parts or is more
reliable than DHCP.  I think likely it's the other way right now.  

Certainly, if your are autoconfiguring with LLDP, you will want that to
complete before you do DHCP.  I don't think we have to say that, but we can
if we need to.  

I agree you need an IP address before you can invoke HELD.  I don't think we
have to say that.

This MIGHT lead to an implied ordering, but I don't think it's even useful
to say that.  I'm not sure why it matters.

Brian

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, September 24, 2007 12:49 PM
To: Stark, Barbara
Cc: ecrit
Subject: RE: [Ecrit] multiple location sources

Hi, 
I agree that the DSL Forum document makes a very good starting point for
orderly acquisition of location at startup, accounting for all 3 methods.  I
also believe it points to a preference order, if there are multiple answers
coming back, which is LLDP-MED --> DHCP --> HELD.  Reasoning for this order
(my opinion) is that it progresses from "least moving parts" / most reliable
(LLDP-MED) to most, and also follows the natural layering of the overall
system (L2 --> L2.5 --> L7).   In the end, only ONE method should ever be
selected, as the sequence diagram shows.   

o If LLDP-MED is being used to autoconfigure voice VLAN ID, then the device
should wait to see if that stage succeeds before contacting DHCP.
Otherwise, the device may get an IP address on the default VLAN, only to
have to drop it and try again on the voice VLAN.  If it had started to use
this address for something already (say for HELD), then ongoing interaction
would be dropped and confusion would likely ensue.   

IMHO, orderly startup beats the few extra seconds delay incurred in making
sure the constraints are not broken.   We are only talking about a very few
seconds here after all.   

-- Peter 

24.09.07 08:48 

It's not always desirable to wait for a protocol to time-out, before
launching the next protocol. Specifically, if a device is configured to do
DHCP for IP address configuration, it should launch its DHCP discovery ASAP,
with options, instead of waiting the 4 or 5 seconds for LLDP-MED to time
out. This prevents unnecessary delays in the bootstrap process. It should be
easy enough for the device to use a received LLDP-MED location, even if it
arrives after the DHCP response. 
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_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: [email-masked]
Date: Mon, 24 Sep 2007 16:35:16 -0400

> I’m not sure how you decided that LLDP-MED has fewer moving parts or is 
more reliable than DHCP
LLDP is running at the other end of the physical wire the device in 
question is plugged into.  (In the case of wireless, it is likely at the 
access point, or just behind it.)  In that sense, there are only 2 moving 
parts that have to be operating correctly -- the phone itself, and the L2 
access switch it is plugged into.  Even with DHCP there is at least the 
network infrastructure, a server somewhere, and often DHCP relay to set up 
to get it all working.  HELD has a bunch more mechanics that all must be 
working correctly on top of that. 

> MIGHT lead to an implied ordering, but I don’t think it’s even useful to 
say that.  I’m not sure why it matters.
I terms of the phone bcp, you are probably right, since other MUSTs make 
sure that there is always exactly one answer anyway.  However, device 
developers will certainly care -- getting startup sequence right is 
important and will not be immediately obvious to many not deep in the 
details of each piece.  The DSL Forum doc is really helpful  from that 
perspective. 

-- Peter

"Brian Rosen" <[email-masked]>
24.09.07 16:22
 
        To:     <[email-masked]>, "'Stark, Barbara'" 
<[email-masked]>
        cc:     "'ecrit'" <[email-masked]>
        Subject:        RE: [Ecrit] multiple location sources

I’m not sure how you decided that LLDP-MED has fewer moving parts or is 
more reliable than DHCP.  I think likely it’s the other way right now. 
 
Certainly, if your are autoconfiguring with LLDP, you will want that to 
complete before you do DHCP.  I don’t think we have to say that, but we 
can if we need to. 
 
I agree you need an IP address before you can invoke HELD.  I don’t think 
we have to say that.
 
This MIGHT lead to an implied ordering, but I don’t think it’s even useful 
to say that.  I’m not sure why it matters.
 
Brian

Hi, 

-- Peter 

        

-------------------- 
 
*****

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 24 Sep 2007 16:43:25 -0400

I understand the "moving parts" now.  Clearly, DHCP is much more mature and
likely to work today than LLDP-MED is.

I think the emergency call documentation is not the place to educate device
developers of how startup sequences involving LLDP, DHCP and HTTP based
protocols could best be done.

Brian

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, September 24, 2007 4:35 PM
To: Brian Rosen
Cc: 'Stark, Barbara'; 'ecrit'
Subject: RE: [Ecrit] multiple location sources

> I'm not sure how you decided that LLDP-MED has fewer moving parts or is
more reliable than DHCP 
LLDP is running at the other end of the physical wire the device in question
is plugged into.  (In the case of wireless, it is likely at the access
point, or just behind it.)  In that sense, there are only 2 moving parts
that have to be operating correctly -- the phone itself, and the L2 access
switch it is plugged into.  Even with DHCP there is at least the network
infrastructure, a server somewhere, and often DHCP relay to set up to get it
all working.  HELD has a bunch more mechanics that all must be working
correctly on top of that.   

> MIGHT lead to an implied ordering, but I don't think it's even useful to
say that.  I'm not sure why it matters. 

-- Peter 

24.09.07 16:22 

  

  
Brian 

  _____  

Hi, 

-- Peter 

24.09.07 08:48 

 
-------------------- 

*****

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 24 Sep 2007 17:34:32 -0500

An important caveat to document is that LLDP-MED doesn’t always provide the host location.  An 802.11 AP might only be able to provide its own location, which, if it is in the next building, isn’t much use.

From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, 25 September 2007 6:43 AM
To: [email-masked]
Cc: 'ecrit'
Subject: RE: [Ecrit] multiple location sources

I understand the “moving parts” now.  Clearly, DHCP is much more mature and likely to work today than LLDP-MED is.

I think the emergency call documentation is not the place to educate device developers of how startup sequences involving LLDP, DHCP and HTTP based protocols could best be done.

Brian

> I’m not sure how you decided that LLDP-MED has fewer moving parts or is more reliable than DHCP 
LLDP is running at the other end of the physical wire the device in question is plugged into.  (In the case of wireless, it is likely at the access point, or just behind it.)  In that sense, there are only 2 moving parts that have to be operating correctly -- the phone itself, and the L2 access switch it is plugged into.  Even with DHCP there is at least the network infrastructure, a server somewhere, and often DHCP relay to set up to get it all working.  HELD has a bunch more mechanics that all must be working correctly on top of that.   

> MIGHT lead to an implied ordering, but I don’t think it’s even useful to say that.  I’m not sure why it matters. 
I terms of the phone bcp, you are probably right, since other MUSTs make sure that there is always exactly one answer anyway.  However, device developers will certainly care -- getting startup sequence right is important and will not be immediately obvious to many not deep in the details of each piece.  The DSL Forum doc is really helpful  from that perspective.   

-- Peter 

24.09.07 16:22 

        To:        <[email-masked]>, "'Stark, Barbara'" <[email-masked]> 
        cc:        "'ecrit'" <[email-masked]> 
        Subject:        RE: [Ecrit] multiple location sources

I’m not sure how you decided that LLDP-MED has fewer moving parts or is more reliable than DHCP.  I think likely it’s the other way right now.   
  
Certainly, if your are autoconfiguring with LLDP, you will want that to complete before you do DHCP.  I don’t think we have to say that, but we can if we need to.   
  
I agree you need an IP address before you can invoke HELD.  I don’t think we have to say that. 
  
This MIGHT lead to an implied ordering, but I don’t think it’s even useful to say that.  I’m not sure why it matters. 
  
Brian 

Hi, 
I agree that the DSL Forum document makes a very good starting point for orderly acquisition of location at startup, accounting for all 3 methods.  I also believe it points to a preference order, if there are multiple answers coming back, which is LLDP-MED --> DHCP --> HELD.  Reasoning for this order (my opinion) is that it progresses from "least moving parts" / most reliable (LLDP-MED) to most, and also follows the natural layering of the overall system (L2 --> L2.5 --> L7).   In the end, only ONE method should ever be selected, as the sequence diagram shows.   

Your point below, that the methods can and should progress in parallel is valid.  However there are constraints to this, notably: 

o If LLDP-MED is being used to autoconfigure voice VLAN ID, then the device should wait to see if that stage succeeds before contacting DHCP.  Otherwise, the device may get an IP address on the default VLAN, only to have to drop it and try again on the voice VLAN.  If it had started to use this address for something already (say for HELD), then ongoing interaction would be dropped and confusion would likely ensue.   

I think these constraints are really just a reflection of the natural layering in the end.   

IMHO, orderly startup beats the few extra seconds delay incurred in making sure the constraints are not broken.   We are only talking about a very few seconds here after all.   

-- Peter 

24.09.07 08:48 

       To:        "Winterbottom, James" <[email-masked]>, "Karl Heinz Wolf" <[email-masked]>, "ecrit" <[email-masked]> 
       cc:         
       Subject:        RE: [Ecrit] multiple location sources

It's not always desirable to wait for a protocol to time-out, before launching the next protocol. Specifically, if a device is configured to do DHCP for IP address configuration, it should launch its DHCP discovery ASAP, with options, instead of waiting the 4 or 5 seconds for LLDP-MED to time out. This prevents unnecessary delays in the bootstrap process. It should be easy enough for the device to use a received LLDP-MED location, even if it arrives after the DHCP response. 
Barbara 
 
-------------------- 
[AJW] My first question is why are you using more than one acquisition protocol. My thoughts would be use one, if it fails, pick a different one. Never invoke both at the same time so you have this problem of choice. 

***** 

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_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 24 Sep 2007 18:04:37 -0500

Peter,

I would point out that a HELD-based LIS actually requires fewer things
to be up and running than the SIP client would in order to initiate the
emergency call in the first place. So I am not sure that the
machinations argument really carries a lot of weight. 

Cheers

James

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, 25 September 2007 6:35 AM
To: Brian Rosen
Cc: 'ecrit'
Subject: RE: [Ecrit] multiple location sources

> I'm not sure how you decided that LLDP-MED has fewer moving parts or
is more reliable than DHCP 
LLDP is running at the other end of the physical wire the device in
question is plugged into.  (In the case of wireless, it is likely at the
access point, or just behind it.)  In that sense, there are only 2
moving parts that have to be operating correctly -- the phone itself,
and the L2 access switch it is plugged into.  Even with DHCP there is at
least the network infrastructure, a server somewhere, and often DHCP
relay to set up to get it all working.  HELD has a bunch more mechanics
that all must be working correctly on top of that.   

> MIGHT lead to an implied ordering, but I don't think it's even useful

-- Peter 

24.09.07 16:22 

I'm not sure how you decided that LLDP-MED has fewer moving parts or is
more reliable than DHCP.  I think likely it's the other way right now.

Certainly, if your are autoconfiguring with LLDP, you will want that to
complete before you do DHCP.  I don't think we have to say that, but we
can if we need to.   
  
I agree you need an IP address before you can invoke HELD.  I don't
think we have to say that. 
  
This MIGHT lead to an implied ordering, but I don't think it's even
useful to say that.  I'm not sure why it matters. 
  
Brian 

Hi, 
I agree that the DSL Forum document makes a very good starting point for
orderly acquisition of location at startup, accounting for all 3
methods.  I also believe it points to a preference order, if there are
multiple answers coming back, which is LLDP-MED --> DHCP --> HELD.
Reasoning for this order (my opinion) is that it progresses from "least
moving parts" / most reliable (LLDP-MED) to most, and also follows the
natural layering of the overall system (L2 --> L2.5 --> L7).   In the
end, only ONE method should ever be selected, as the sequence diagram
shows.   

Your point below, that the methods can and should progress in parallel
is valid.  However there are constraints to this, notably: 

o If LLDP-MED is being used to autoconfigure voice VLAN ID, then the
device should wait to see if that stage succeeds before contacting DHCP.
Otherwise, the device may get an IP address on the default VLAN, only to
have to drop it and try again on the voice VLAN.  If it had started to
use this address for something already (say for HELD), then ongoing
interaction would be dropped and confusion would likely ensue.   

IMHO, orderly startup beats the few extra seconds delay incurred in
making sure the constraints are not broken.   We are only talking about
a very few seconds here after all.   

-- Peter 

24.09.07 08:48 

 
-------------------- 

***** 

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_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 25 Sep 2007 12:39:51 -0400

That's often all you can get.

There are only three cases:

1.	The user measures its own location, no LCP needed
2.	The location of the clients of the AP are reported as the location
of the AP
3.	There is triangulation between APs and clients to get a more
accurate location

Case 2 is going to be the norm for a while.

The ability to triangulate is around, but not widely deployed.

Brian

  _____  

From: Thomson, Martin [mailto:[email-masked]] 
Sent: Monday, September 24, 2007 6:35 PM
To: Brian Rosen; [email-masked]
Cc: ecrit
Subject: RE: [Ecrit] multiple location sources

An important caveat to document is that LLDP-MED doesn't always provide the
host location.  An 802.11 AP might only be able to provide its own location,
which, if it is in the next building, isn't much use.

  _____  

Brian

  _____  

more reliable than DHCP 

-- Peter 

24.09.07 16:22 

  

  
Brian 

  _____  

Hi, 

-- Peter 

24.09.07 08:48 

 
-------------------- 

***** 

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 25 Sep 2007 17:24:28 -0500

Uncertainty becomes useful information here.  It is important to distinguish between the location of the AP, which is known to a certain precision, and the location of the host.  If you are using the location of the AP to determine the location of the host, then the location of the host is the coverage area of the AP.  Therefore, there is a difference between the two.

That is, if the AP location is known as (x, y) with relatively high precision, then the location of the host is (x, y) give or take the effective range of the AP.  Therefore, the location of the AP and the location of a host differ.

But then, that doesn’t work very well with LCI.

Case 3 would be nice, but I doubt that it will ever account for 100% of cases.

Ta,

Martin

From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, 26 September 2007 2:40 AM
To: Thomson, Martin; [email-masked]
Cc: 'ecrit'
Subject: RE: [Ecrit] multiple location sources

That’s often all you can get.

1.	The user measures its own location, no LCP needed
2.	The location of the clients of the AP are reported as the location of the AP
3.	There is triangulation between APs and clients to get a more accurate location

Brian

Brian

-- Peter 

24.09.07 16:22 

  

  
Brian 

Hi, 

-- Peter 

24.09.07 08:48 

 
-------------------- 

*****

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 25 Sep 2007 17:35:44 -0500

But, then, the progenitors of 3825 have always said that it wasn't for
wireless - it is aimed at enterprise wired Ethernet switched LANs. Since
LLDP-MED has the same encoding, the same restrictions apply.

Cheers,

Martin

From: Thomson, Martin [mailto:[email-masked]] 
Sent: Wednesday, 26 September 2007 8:24 AM
To: Brian Rosen; [email-masked]
Cc: ecrit
Subject: RE: [Ecrit] multiple location sources

Uncertainty becomes useful information here.  It is important to
distinguish between the location of the AP, which is known to a certain
precision, and the location of the host.  If you are using the location
of the AP to determine the location of the host, then the location of
the host is the coverage area of the AP.  Therefore, there is a
difference between the two.

That is, if the AP location is known as (x, y) with relatively high
precision, then the location of the host is (x, y) give or take the
effective range of the AP.  Therefore, the location of the AP and the
location of a host differ.

But then, that doesn't work very well with LCI.

Case 3 would be nice, but I doubt that it will ever account for 100% of
cases.

Ta,

Martin

1.	The user measures its own location, no LCP needed
2.	The location of the clients of the AP are reported as the
location of the AP
3.	There is triangulation between APs and clients to get a more
accurate location

Brian

An important caveat to document is that LLDP-MED doesn't always provide
the host location.  An 802.11 AP might only be able to provide its own
location, which, if it is in the next building, isn't much use.

I understand the "moving parts" now.  Clearly, DHCP is much more mature
and likely to work today than LLDP-MED is.

I think the emergency call documentation is not the place to educate
device developers of how startup sequences involving LLDP, DHCP and HTTP
based protocols could best be done.

Brian

-- Peter 

24.09.07 16:22 

  

Brian 

Hi, 

-- Peter 

24.09.07 08:48 

 
-------------------- 

*****

---

From: John Schnizlein <[email-masked]>
Date: Tue, 25 Sep 2007 19:23:46 -0400

What RFC 3825 actually says about the wireless-LAN access point is as  
follows:

    Wireless hosts can utilize this option to gain knowledge of the
    location of the radio access point used during host configuration,
    but would need some more exotic mechanisms, maybe GPS, or maybe a
    future DHCP option, which includes a list of geo-locations like that
    defined here, containing the locations of the radio access points
    that are close to the client.

The range of the radio in the access point, or the accuracy of  
triangulation (or other means) would determine the resolution of the  
LCI provided.

John

P.S. Why are we rehashing settled issues from years ago here?

On Sep 25, 2007, at 6:35 PM, Dawson, Martin wrote:
> But, then, the progenitors of 3825 have always said that it wasn’t  
> for wireless – it is aimed at enterprise wired Ethernet switched  
> LANs. Since LLDP-MED has the same encoding, the same restrictions  
> apply.
>
>
>
>> distinguish between the location of the AP, which is known to a  
>> certain precision, and the location of the host.  If you are using  
>> the location of the AP to determine the location of the host, then  
>> the location of the host is the coverage area of the AP.   
>> Therefore, there is a difference between the two.
>>
>> That is, if the AP location is known as (x, y) with relatively  
>> high precision, then the location of the host is (x, y) give or  
>> take the effective range of the AP.  Therefore, the location of  
>> the AP and the location of a host differ.
>>
>>> The user measures its own location, no LCP needed
>>> The location of the clients of the AP are reported as the  
>>> location of the AP
>>> There is triangulation between APs and clients to get a more  
>>> accurate location
>>>> An important caveat to document is that LLDP-MED doesn’t always  
>>>> provide the host location.  An 802.11 AP might only be able to  
>>>> provide its own location, which, if it is in the next building,  
>>>> isn’t much use.
>>>>
>>>>> I understand the “moving parts” now.  Clearly, DHCP is much  
>>>>> more mature and likely to work today than LLDP-MED is.
>>>>  ...

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 25 Sep 2007 18:30:51 -0500

Huh? Well - the thread got onto LLDP-MED. Why are you changing the
characterization of 3825? We got repeatedly told that the encoding was
only ever intended to convey the location of a *point* - that's why the
inadequacies of using significant digits for uncertainty wasn't an
issue. Now you're saying it can be used to convey the "range" of the
access point? It can't - that was the whole point of the discussion
"years ago".

Cheers,
Martin

-----Original Message-----
From: John Schnizlein [mailto:[email-masked]] 
Sent: Wednesday, 26 September 2007 9:24 AM
To: Dawson, Martin
Cc: Thomson, Martin; Brian Rosen; [email-masked]; ecrit
Subject: Re: [Ecrit] multiple location sources

John

On Sep 25, 2007, at 6:35 PM, Dawson, Martin wrote:
> But, then, the progenitors of 3825 have always said that it wasn't  
> for wireless - it is aimed at enterprise wired Ethernet switched  
>>>> An important caveat to document is that LLDP-MED doesn't always  
>>>> isn't much use.
>>>>> I understand the "moving parts" now.  Clearly, DHCP is much

---

From: John Schnizlein <[email-masked]>
Date: Tue, 25 Sep 2007 19:47:54 -0400

I quoted RFC 3825.  Who is "changing the characterization of 3825"?

Despite mistaken interpretations that were aired in the GeoPriv WG,  
the meaning of resolution has been clear (significant binary digits)  
all along.

John

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 25 Sep 2007 19:00:34 -0500

Yes - you quoted 3825 - which didn't say it could provide the area of
coverage of the access point - and then you went on to say that
resolution could be used to express the range of the access point.

To give you the benefit of the doubt - are you or are you not
maintaining that you can represent any arbitrary access point location
and range with just resolution?

Cheers,
Martin

-----Original Message-----
From: John Schnizlein [mailto:[email-masked]] 
Sent: Wednesday, 26 September 2007 9:48 AM
To: Dawson, Martin
Cc: Thomson, Martin; Brian Rosen; [email-masked]; ecrit
Subject: Re: [Ecrit] multiple location sources

John

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 25 Sep 2007 19:22:41 -0500

John,

3825 states normative section 2.1,

"The examples in the appendix illustrate that a smaller value in the
   resolution field increases the area within which the device is
   located."

And this is clearly what is reflected in the examples. That is, it tries
to use significant digit to express uncertainty. Whether you believe it
or not, that it what it is doing. It is flawed.

You cannot use the LCI encoding to express a range of values without
contradicting what you stated earlier. Either it is a point, and 3825 is
simply wrong, or you are trying to express an area using significant
digits, and you have the error situation.

Which is it?

Cheers
James

> Cc: ecrit; Thomson, Martin

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Wed, 26 Sep 2007 15:37:07 +0200

Thank you Barbara, for these useful documents from the DSL forum.
I haven't read everything, but just two small comments so far:

In Appendix A, Flow A, there is a line missing. "Was location in DHCP
response" has no "No" branching. It should connect to "Determine LIS",
I would suggest.

Concerning Manual Configuration of Location Information: you use
manual configuration only in case no other location determination was
successful. This is different to
draft-ietf-geopriv-pdif-lo-profile-08, I think. If I understand
Section 3.3. correctly, a separate PIDF document would be created
containing the manual configuration even if automatic configuration
was successful.

karl heinz

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 26 Sep 2007 09:50:10 -0400

Concerning manual location:

If a subscriber says he is at "X" and the carrier thinks the demark point is
"Y", you better route the call on and send "X".  You probably want to send
"Y" also.  That mirrors what PSAPs do.  

Brian

> Sent: Wednesday, September 26, 2007 9:37 AM
> To: Stark, Barbara
> Cc: ecrit
> material from all computers. GA621
> >
> >
> >
>

---

From: <[email-masked]>
Date: Wed, 26 Sep 2007 10:01:09 -0400

I disagree in the context of ES.

The reverse should be done (route on Y and maybe send X as long as there is a mechanism to help the PSAP interpreting this situation) and let the call taker confirm the information through interaction with the caller. This is how it works today.

Guy Caron
-----Message d'origine-----
De : Brian Rosen [mailto:[email-masked]] 
Envoyé : 26 septembre 2007 09:50
À : 'Karl Heinz Wolf'; 'Stark, Barbara'
Cc : 'ecrit'
Objet : RE: [Ecrit] multiple location sources

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 26 Sep 2007 10:22:43 -0400

Well, in the sense that today, there is no way for a subscriber to tell a
carrier that the location is X and not Y, you are correct.

Imagine the following scenario:
I have a family compound.  It has 4 houses in 30 acres.  We pay for a single
high speed Internet connection, and order 4 VoIP "lines", one for each house
with a LAN between the houses.  To the carrier, there is one demarc point,
and one address for all four "lines".  I come to you and say "If anyone
calls from Line 1, the location is X1, line 2 is X2, ...  I know someone who
has a set-up like this now.

What will you do?  If you behave like you do today, you will always send Y
and that’s it.

I won't speak for Canadians, but in the U.S, if you got a request like that
and a 9-1-1 call was sent to Y, you would likely not have a problem.
However, if the subscriber told you again, and the next 9-1-1 call was sent
to Y, you would be in serious trouble (this happened recently, although it
was a simple data entry problem and not a subscriber-knows-more-than-carrier
problem).  

You must have a manual method, and if the subscriber insists he is at X, you
MUST route on X.  A difference between demarc and actual location is way too
easy to be significant these days.

In the PSAP itself, the way this plays out is that you say you are at X, and
the ALI says you are at Y.  The response goes to X.  Always.  The PSAP never
gets in trouble sending people to X.  If they sent response only to Y, it
could be very bad news.  If the caller actually was at Y, and they send
responders to X, there would be no problem as long as the tape showed they
asked the guy the right questions.  If the caller was an X and they send
response to Y, they would be in big trouble.  You always believe the caller.
You may question him carefully (which is why sending Y is a good idea), but
you respond to X.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 26, 2007 10:01 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> The reverse should be done (route on Y and maybe send X as long as there
> is a mechanism to help the PSAP interpreting this situation) and let the
> call taker confirm the information through interaction with the caller.
> This is how it works today.
> 
> Guy Caron
> > > (see http://www1.ietf.org/mail-
> archive/web/geopriv/current/msg04297.html

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 26 Sep 2007 10:53:28 -0400

Karl Heinz,
Thanks for your feedback. I'll fix the DHCP response "No" branch in my
next version.

As for the manual configuration comment --
I didn't read pidf-lo-profile-08 Section 3.3 as recommending that the
manual config necessarily be included. It's a good question, though, and
I think you've done a great job at starting discussion on this on the
list.
Barbara 

-----Original Message-----
From: Karl Heinz Wolf [mailto:[email-masked]] 
Sent: Wednesday, September 26, 2007 9:37 AM
To: Stark, Barbara
Cc: ecrit
Subject: Re: [Ecrit] multiple location sources

karl heinz

> 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. GA621

*****

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. GA625

---

From: <[email-masked]>
Date: Wed, 26 Sep 2007 11:07:42 -0400

Your scenario seems to imply that the each "line" is fixed (non-nomadic) and always associated with one location Xx. What happens when "line" 1 is moved to location X2? Worst, what happens when "line" 1 is used completely outside of the family compound?

Also, location Y in your scenario is not wrong, it's imprecise (your family compound has a single civic address with multiple dwellings). This can be resolved through interaction between caller and callee.

BTW, there are ways today for subscribers to notify carriers of situations like you describe.

Manual input is dangerous in ES.

Guy Caron
-----Message d'origine-----
De : Brian Rosen [mailto:[email-masked]] 
Envoyé : 26 septembre 2007 10:23
À : Caron, Guy (A162859); [email-masked]; [email-masked]
Cc : [email-masked]
Objet : RE: [Ecrit] multiple location sources

and that's it.

Brian

> to

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 26 Sep 2007 10:15:16 -0500

I'm with Guy on this one.

Picture this - somebody has manually configured a location in the VoIP client on their PDA. They did it out of curiosity when they first got it and never really understood what it was for. They forgot about it shortly afterwards.

When they eventually make a 911 call, they are in a completely different city. The call gets routed to the wrong PSAP.

You should believe the network location first because the network has responsibility to maintain location information and users do not. The FCC recognizes this - which is why they say that user provided location is not going to be suitable for VoIP in the long term.

If you've got such an extensive "campus" that dispatch really makes a difference, then you should have a LIS. The network location will ensure routing is done correctly. If the PSAP is really going to get both locations then the network (less granular) location will still correlate with the user provided (more granular) location and will still be useful to the operator.

I don't think you can meaningfully suggest that a user "configured" location is semantically equivalent to a location provided verbally in the course of the call. It's not the same thing.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, 27 September 2007 12:23 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Ecrit] multiple location sources

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 26 Sep 2007 11:34:00 -0400

I think that the carrier will never be in trouble if I screw up, especially
if they send what they think the location should be.  I think they will be
seriously hosed if they are wrong and I am right.

I don't think this should be particularly easy.  I think it should be
possible.  I know that it MUST be possible for the subscriber to tell the
carrier what address to report, regardless of what the carrier thinks the
location is.

In the situation I've described, if the endpoint put a location on the call
(local LIS), what do you do if the network thinks it's wrong?  -phonebcp
says you use the one from the endpoint.  That is indistinguishable from
manual configuration from the network point of view.

I am not suggesting that user configuration and verbal communication are the
same.  I'm suggesting that when there is a conflict between what the user
asserts and what the network asserts, the emergency system uses the user's
answer, always.

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Wednesday, September 26, 2007 11:15 AM
> To: Brian Rosen; [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Picture this - somebody has manually configured a location in the VoIP
> client on their PDA. They did it out of curiosity when they first got it
> and never really understood what it was for. They forgot about it shortly
> afterwards.
> 
> When they eventually make a 911 call, they are in a completely different
> city. The call gets routed to the wrong PSAP.
> 
> You should believe the network location first because the network has
> responsibility to maintain location information and users do not. The FCC
> recognizes this - which is why they say that user provided location is not
> going to be suitable for VoIP in the long term.
> 
> If you've got such an extensive "campus" that dispatch really makes a
> difference, then you should have a LIS. The network location will ensure
> routing is done correctly. If the PSAP is really going to get both
> locations then the network (less granular) location will still correlate
> with the user provided (more granular) location and will still be useful
> to the operator.
> 
> I don't think you can meaningfully suggest that a user "configured"
> location is semantically equivalent to a location provided verbally in the
> course of the call. It's not the same thing.
> 
> Cheers,
> Martin
> 
> > If a subscriber says he is at "X" and the carrier thinks the demark
> point
> > is
> > > > Again, this is suggested for the case where there is nothing on
> which
> > to

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 26 Sep 2007 10:59:26 -0500

below

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, 27 September 2007 1:34 AM
To: Dawson, Martin; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Ecrit] multiple location sources

[[MCD]]  I wasn't saying anything about liability - I'm talking about reliability. I believe the network provided location will be more reliable than user configured location. I'm talking about the best solution, not the "least liability" solution. Network operators already have responsibility for getting location information correct - nothing has changed there.

[[MCD]] You're talking about something that doesn't happen today. You agree that a location provided verbally in the actual course of the call is not the same as a user configured location. I don't know what empirical data you're basing your assertion on that this is better.

[[MCD]] The current functionality does not offer much scope for sophistication on this point. If the device acquires location by value, it could choose to replace the proffered location with its own. If it does it by reference, it doesn't have an opportunity to compare anyway. If it decides to just use its own without asking the network, then the network doesn't get a chance to express an opinion anyway. Until we have location signing, there won't be a definitive way to know for sure that we're dealing with a genuine network determined location. Callers could choose to deliberately lie about their location for whatever purpose that served them.

When the routing engine can genuinely tell the difference, then I think it should be a matter of jurisdictional policy as to which location takes precedence for routing. Routing rules (and LoST implementation) are within the remit of the jurisdiction. I don't think phonebcp has authority over jurisdictions to decide that policy (nor does it need to have). 

I am not suggesting that user configuration and verbal communication are the
same.  I'm suggesting that when there is a conflict between what the user
asserts and what the network asserts, the emergency system uses the user's
answer, always.
[[MCD]] Yes - we disagree on that.

Brian

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 26 Sep 2007 13:12:01 -0400

I think this is a perfect example as to why manual config is not a good idea in an end device, but does need to be supported in home and business routers.

I think it's pretty safe to assume that a person, P1, living at X1 (in Brian's 30 acre compound) will quickly learn that he can take the telephone, T1, with him to gossip at X2, and everything works perfectly. P1 can make calls on line 1 (L1), and receive them, no matter where T1 happens to be! No way is P1 going to be updating location info, everytime he leaves the house with T1. Imagine his joy when he discovers that T1 not only works at X1-4, but it also works at the Wi-Fi enabled barber shop, in town. Fortunately, he can leave T1' and T1'' at X1, so his kids (P1'-P1''''') can still use L1, as well. VoIP is a wonderful thing.

On the other hand, that router serving the 4 homes will be relatively static in location, and I think it would be a good idea to support manual config, partly for the scenario Brian describes.

What I really wish we could seriously discuss, is desired default behaviors.
I think we have to accept that
a) Manual configuration of all sorts of devices (end devices and intermediary devices) will exist, no matter how hard regulators frown or smile -- I mean, let's be realistic: No way  is the Canadian government going to fine me or throw me in jail, when I take my US laptop to Quebec City, and it's subscribed to a Sierra Leone provider, and has a soft client that I downloaded off the Internet that lets me manually configure my location. There's nothing they can really do to keep Canadian citizens from having configurable devices, either, if the Canadian citizens so choose. Unless they intend to cut the Canadian Internet off from the rest of the world, and close their borders...

b) There will exist devices where end users can set the logic of location determination and acquisition. They can add protocols, remove protocols, re-order protocols, enter 20 different manual locations with rules as to which to use where, etc. Regulators can't prevent the existence of these devices, or control the end users.

c) The vast majority of people won't want to use manual configuration of location, especially in end devices. In cases where they find a manual config capability in a device, odds are they'll put bad info in it by playing with it and then forgetting about it. The info they enter might not even be valid.

With those assumptions, I think the right *default* behavior is:
1) If you're an end device making an emergency call, and you have a network-provided location and a manual location, use the network-provided (understanding that there will always exist configurable and custom devices that deviate from the recommended default); I'd rather not even send the manual, by default. (Again, configure it if you don't like the default.) But I could be swayed to include the manual, as described in Section 3.3 of sip-location-conveyance-08 -- it probably won't hurt. But only if the manual location was valid (i.e., had been validated). It would be hard to convince me that manual should be used for routing and put first in the list of locations, as a recommended default.
2) Default server behavior will be to send clients the network-determined location, if they get one. Again, if that's not the desired behavior, then configure the thing. I think routers should be more configurable that end devices in this regard.

We need to set the default behaviors to meet the needs of the greater majority of people. Let the others jump through a few hoops to get things to work the way they want. We can't create rules that will meet 100% of needs. Above all, be realistic -- devices with manual config will exist. Just create reasonable rules and defaults so that lots of people don't feel obliged to go out of their way to get devices that don't abide by recommended behavior. Avoid rules that encourage lots of people to lie to get what they want.
Barbara

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, September 26, 2007 10:23 AM
To: [email-masked]; [email-masked]; Stark, Barbara
Cc: [email-masked]
Subject: RE: [Ecrit] multiple location sources

Brian

---

From: <[email-masked]>
Date: Wed, 26 Sep 2007 14:16:11 -0400

First, please don't make this a country-specific topic because it is not. Second, forget about regulation. It is not the basis of my position.

I agree default behaviour for ES is required at the endpoint. IMO, use of manual input location should be at the very bottom of the decision tree. And even then, I'm not convinced this is a better default solution than sending the call to a 3rd party if manual entry is only what you have (acting as if no location was available).

See the rest of my comments inline.

Guy Caron
-----Message d'origine-----
De : Stark, Barbara [mailto:[email-masked]] 
Envoyé : 26 septembre 2007 13:12
À : Brian Rosen; Caron, Guy (A162859); [email-masked]
Cc : [email-masked]
Objet : RE: [Ecrit] multiple location sources

On the other hand, that router serving the 4 homes will be relatively static in location, and I think it would be a good idea to support manual config, partly for the scenario Brian describes.
[GC] Nope. You just reduced the impreciseness of the location but did not cover the scenario I described in my previous mail.

What I really wish we could seriously discuss, is desired default behaviors.
I think we have to accept that
a) Manual configuration of all sorts of devices (end devices and intermediary devices) will exist, no matter how hard regulators frown or smile -- I mean, let's be realistic: No way  is the Canadian government going to fine me or throw me in jail, when I take my US laptop to Quebec City, and it's subscribed to a Sierra Leone provider, and has a soft client that I downloaded off the Internet that lets me manually configure my location. There's nothing they can really do to keep Canadian citizens from having configurable devices, either, if the Canadian citizens so choose. Unless they intend to cut the Canadian Internet off from the rest of the world, and close their borders...
[GC] Who's talking about regulators? I'm not. What I'm saying is that you can't rely on information inputted statically by users. This is bad in ES context. You need a safeguard solution to validate the information provided. This is done today, and will continue to be done as per PSAP operation's procedures with VoIP, through interaction with the caller. The scenario you described is exactly what you don't want to happen with ES. If you are in Quebec City, your device is better choosing the network-provided location to route if you dial 9-1-1. That is what you want. Not doing so will indeed not send you to jail but may increase the risks of a visit to the cemetery.

b) There will exist devices where end users can set the logic of location determination and acquisition. They can add protocols, remove protocols, re-order protocols, enter 20 different manual locations with rules as to which to use where, etc. Regulators can't prevent the existence of these devices, or control the end users.
[GC] Again, please forget about regulation. It is not the basis of my position. What you describe may happen and I don't mind how this would work in non-ES situations however, for ES we need less relax rules/behaviours.

c) The vast majority of people won't want to use manual configuration of location, especially in end devices. In cases where they find a manual config capability in a device, odds are they'll put bad info in it by playing with it and then forgetting about it. The info they enter might not even be valid.
[GC] Agreed. However, if the capability of manually inputted location exists at the endpoint with a relatively intuitive GUI, this will happen and maybe more than we can think now. 

With those assumptions, I think the right *default* behavior is:
1) If you're an end device making an emergency call, and you have a network-provided location and a manual location, use the network-provided (understanding that there will always exist configurable and custom devices that deviate from the recommended default); I'd rather not even send the manual, by default. (Again, configure it if you don't like the default.) But I could be swayed to include the manual, as described in Section 3.3 of sip-location-conveyance-08 -- it probably won't hurt. But only if the manual location was valid (i.e., had been validated). It would be hard to convince me that manual should be used for routing and put first in the list of locations, as a recommended default.
[GC] Maybe there should be a timeout on those manual locations so they are not persistent? This in conjunction with an ES flag on a per location basis would seem like a reasonable solution. That is, the user manually enters a location and decides if this information is to be used for ES by setting a checkbox. If yes, the checkbox remain until the timeout expires (24 hours?). It's not perfect but a good compromise.

2) Default server behavior will be to send clients the network-determined location, if they get one. Again, if that's not the desired behavior, then configure the thing. I think routers should be more configurable that end devices in this regard.
[GC] Routers are nomadic too. Bolt it to the house and I'm fine with that.

We need to set the default behaviors to meet the needs of the greater majority of people. Let the others jump through a few hoops to get things to work the way they want. We can't create rules that will meet 100% of needs. Above all, be realistic -- devices with manual config will exist. Just create reasonable rules and defaults so that lots of people don't feel obliged to go out of their way to get devices that don't abide by recommended behavior. Avoid rules that encourage lots of people to lie to get what they want.
[GC] Manual config will exist, no argument here. I just prefer this information not to be used for ES.

Barbara

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, September 26, 2007 10:23 AM
To: [email-masked]; [email-masked]; Stark, Barbara
Cc: [email-masked]
Subject: RE: [Ecrit] multiple location sources

Brian

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Thu, 27 Sep 2007 15:19:35 +0200

Barbara, I have read your requirements document now, and I'd like to
post a few comments. First I want to say that this is a good document
that clarifies things. Thank you, Barbara.

Client.manual 1: why not geo?

Client.sequence.general.7: what about unplugging a cable, should the
knowledge of successful means also not be stored?

also Client.sequence.general.7: "Do we have a rule for LLDP-MED?": I
believe yes, every LLDP frame has a Time To Live TTL TLV (type 3),
which is mandatory for LLDP according to IEEE Std. chapter 9.5.4.

Client.sequence.L7.1:  which sequence? The sequence of LIS servers?

Server.Protocol.15: why should manually configured and GPS locations
just be sent using HELD? Why not with the other protocols, too?
Besides, according to your document, the server may even not support
HELD. That confuses me a bit.

karl heinz