Subject: RE: [Geopriv] Registration of additional PIDF-LO Methods

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 29 Mar 2006 21:17:33 -0600

Hi Cullen,

We certainly have systems that will use a number of these. We envisage
carriers that are deploying 3G wireless IP networks and that have
existing control-plane wireless location infrastructure will use it. So
in short, I think that there is a strong need for these in wireless
converged networks, even if they are not all used right of the bat.

Cheers

James

________________________________

From: Cullen Jennings [mailto:[email-masked]] 
Sent: Thursday, 30 March 2006 1:02 PM
To: Winterbottom, James; [email-masked]
Cc: [email-masked]
Subject: Re: [Geopriv] Registration of additional PIDF-LO Methods

Just out of curiosity, do you have systems that are going to use all the
things you registered?

On 3/24/06 2:35 PM, "Winterbottom, James"
<[email-masked]> wrote:

Hi All,
 
For those interested I have registered quite a number of additional
<method> types for the PIDF-LO. These are largely, but not exclusively,
wireless determination types.
 
http://www.iana.org/assignments/method-tokens

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]

________________________________

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

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

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

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 29 Mar 2006 21:29:03 -0600

James

I want you to remove "wiremap" as it is a direct duplicate to "DHCP" as 
defined in RFC4119 and what's exactly in the IANA description on the link 
you have below.  Leaving it here will cause confusion.

I am curious about the differences between "A-GPS" and "Device Assisted GPS"?

At 02:35 PM 3/24/2006 -0600, Winterbottom, James wrote:
>Content-Type: multipart/alternative;
>         boundary="--=_NextPart_ST_14_35_13_Friday_March_24_2006_25372"
>Content-class: urn:content-classes:message
>
>Hi All,
>
>
>
><http://www.iana.org/assignments/method-tokens>http://www.iana.org/assignments/method-tokens
>
>
>
>
>
>Cheers
>
>James
>
>
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 30 Mar 2006 07:10:09 -0600

James,

DHCP is not the only way to discover location using a wiremap database.
I would therefore suggest that the DHCP description be updated to
specifically indicate that it is to be used only where DHCP-relays are
involved in the determination of location. Remember, that the method is
for how location was determined and not how it was delivered.

Cheers
James

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]]
> Sent: Thursday, 30 March 2006 1:29 PM
> I am curious about the differences between "A-GPS" and "Device
Assisted
> GPS"?
> ><http://www.iana.org/assignments/method-
> tokens>http://www.iana.org/assignments/method-tokens
> >
> >
> >
> >
> >
> >Cheers
> >
> >James
> >
> >
> >
>
>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------

---

From: "Abbott, Nadine B" <[email-masked]>
Date: Thu, 30 Mar 2006 10:52:39 -0500

"Wiremap" seems to have a meaning that is more specific to how the
location information is created/maintained, and has a less
protocol-specific connotation than use of DHCP.  
 
Nadine

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Wednesday, March 29, 2006 10:29 PM
To: Winterbottom, James; [email-masked]
Cc: [email-masked]
Subject: Re: [Geopriv] Registration of additional PIDF-LO Methods

James

I want you to remove "wiremap" as it is a direct duplicate to "DHCP" as
defined in RFC4119 and what's exactly in the IANA description on the
link you have below.  Leaving it here will cause confusion.

I am curious about the differences between "A-GPS" and "Device Assisted
GPS"?

>------------------------- 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: "James M. Polk" <[email-masked]>
Date: Thu, 30 Mar 2006 11:30:28 -0600

Nadine/James

So, how do you separate "DHCP" stating it is for "wireline access"?

Where cannot someone get confused?

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 30 Mar 2006 11:33:56 -0600

James,

My recommendation is to update the DHCP description to say where
DHCP-relay is used only, and we could indicate for the generic wiremap
that this is not to be used where a specific method is described.

This will avoid confusion. 

Cheers
James

> Sent: Friday, 31 March 2006 3:30 AM
> To: Abbott, Nadine B; Winterbottom, James; [email-masked]
> Subject: RE: [Geopriv] Registration of additional PIDF-LO Methods
> 
> Nadine/James
> 
Assisted
><http://www.iana.org/assignments/method-tokens>http://www.iana.org/assi
immediately

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 30 Mar 2006 16:04:35 -0600

James

DHCP Relay is used in 802.11 deliveries too...

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 30 Mar 2006 16:13:54 -0600

But that is my entire point James, Method is a parameter describing how
location was determined NOT how it was delivered. They are not the same
thing!

If I were to use VLAN or VPI/VCI identifiers as keys to my database to
determine location, I could quite easily use wiremap as my method, but
it would be ludicrous to suggest that I put a method of DHCP. Hopefully
this clarifies the issue, method describes how location was determined,
not the type of access, and not how location was delievered.

> Sent: Friday, 31 March 2006 8:05 AM
> To: Winterbottom, James; Abbott, Nadine B; [email-masked]
> > > >I want you to remove "wiremap" as it is a direct duplicate to
"DHCP"
> >as
--
--

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 30 Mar 2006 16:55:45 -0600

At 04:13 PM 3/30/2006 -0600, Winterbottom, James wrote:
>location was determined NOT how it was delivered.

no, that's not the intend of <method>

>They are not the same

You're right, but you'll read below what was intended in 4119

Learning location through DHCP over a wire (because the LG knows how it 
received location) is "DHCP"

Learning location through DHCP over WiFi (because the LG knows how it 
received location) is "802.11"

This was all hammered out at the Seoul IETF

>it would be ludicrous to suggest that I put a method of DHCP.

You're using Method differently than 4119 is.  Method was created to give 
to the PSAP operator as an indication of how the caller learned the 
location they gave the operator.  The feeling was at the time that over 
time, operators would learn through experience how much to trust each 
Method given, and to tell first responders some things learned through 
dispatch experience.  This is not something we could have specified, 
because there is nothing like this type of location acquisition in the 
circuit or wireless world today.

Method was not intended to be in a database, it was to be used to give the 
operator an indication.  We didn't know what a creative SW engineer of an 
operator station w/could come up with as far as something relational 
depending on the PIDF-LO indication for different methods, but knowing 
location was learned for a AP means the operator needs to tell the 
responder the caller can be 100m from that position with an up and down 
angle allowing different floors of a building to take into account. 
Whereas, this would not be true if location were learned from a wire, which 
means a jack on a wall.

>Hopefully

Well, no, because I wrote the original text for the Method section of 4119, 
and that's not what I had in mind when I wrote it - and the WG approved it. 
So, it appears someone's made a assumption/conclusion that is not based on 
what happened then.  I'm sorry.

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 30 Mar 2006 19:07:56 -0600

Hi Andy,

In cellular networks this is quite easily addressed.
The location itself dictates the precision, through the use of
uncertainty.
There is a separate element, the position source, that indicates how
location was determined. This is a good model as it keeps the precision
with the location, and the determination method as a "by the way".
James's previous email blends these two in such a way that they are
compound and not distinct, which leads a mass of confusion.

Cheers
James

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Friday, 31 March 2006 10:11 AM
> To: Winterbottom, James
> Cc: James M. Polk; Abbott, Nadine B; [email-masked]; voip-
> [email-masked]
> I have to admit I'm a little confused here.  As James Polk mentioned,
> the intent is for the PSAP operator to better understand the meaning
> of the location and take appropriate steps.  But I don't think that
> is possible if in some situations "802.11" means that location must
> be interpretted with respect to the WiFi network itself and in other
> situations "802.11" must be interpretted without respect to the WiFi
> network because the location merely transited the WiFi network.
> 
> -andy
> 
> On Mar 30, 2006, at 6:07 PM, Winterbottom, James wrote:
> 
> > James,
> >
> > For this to be useful, it needs to indicate to the operator how
> > location
> > was determined, not how it was made available to the end-point, or
> > whoever else is receiving it. To this end, the text is clear,
whether
> > you meant it that way or not it is how most people I have spoken to
> > have
> > interpreted it. I believe that we need a determination type, if you
> > and
> > the WG are saying that method is not that parameter then we need a
new
> > one. If you are saying that method is the way in which location is
> > determined then wiremap is different from DHCP and the new
> > registration
> > needs to stay given the previously sited example.
> >
> > So at this point I am going asked the WG what they believe the
> > intent of
> > the method element is.
> >
> > Cheers
> > James
> >
> >
> >> Sent: Friday, 31 March 2006 8:56 AM
> >>> But that is my entire point James, Method is a parameter
describing
> > how
> >> Learning location through DHCP over a wire (because the LG knows
how
> > it
> >>> If I were to use VLAN or VPI/VCI identifiers as keys to my
database
> > to
> >> You're using Method differently than 4119 is.  Method was created
to
> > give
> >> Method was not intended to be in a database, it was to be used to
> >> give
> > the
> >> operator an indication.  We didn't know what a creative SW
> >> engineer of
> > an
> >> Whereas, this would not be true if location were learned from a
wire,
> >> which
> >> Well, no, because I wrote the original text for the Method section
of
> >> 4119,
> >> and that's not what I had in mind when I wrote it - and the WG
> > approved
> >> it.
> >>>>>>> "Wiremap" seems to have a meaning that is more specific to
> > how
> >>> the
> >>>>>>> defined in RFC4119 and what's exactly in the IANA description
> > on
> >>> the
> >> <http://www.iana.org/assignments/method-tokens>http://www.iana.org/
> >> assi
> >>>>>>>> gnments/method-tokens
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Cheers
> >>>>>>>>
> >>>>>>>> James
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >>
---------------------------------------------------------------------
> >> --
> >>>>>>>> ------------------------- This message is for the
> > designated
> >>>>> recipient
---------------------------------------------------------------------
---------------------------------------------------------------------
> >>>>> this email is prohibited.
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------
----------------------------------------------------------------------
> > --------------------------
----------------------------------------------------------------------
> > --------------------------
> > [mf2]
> >