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

From: "James M. Polk" <[email-masked]>
Date: Thu, 30 Mar 2006 19:56:57 -0600

James

The WG, a long time ago, agreed after a lot of discussion that uncertainty 
and confidence were not in Geopriv's plans.  This was about the time the WG 
decided granularity and accuracy were out too (in favor of precision and 
resolution).

The <method> element is all about:

         by what method of connection (configuation if manually entered) did
         the LG learn location.

This method is then to be placed into the PIDF-LO as an indication to the 
PSAP operator to inform them so they can make certain decisions based on 
the topology used by the caller's device.

What you describe is not what the WG had in mind, and was in fact rejected 
at that time.  I don't remember if you were part of the WG then, but 
cellular systems were not thought of very much at that time because the WG 
felt that their infrastructures had the necessary layer 2 information and 
capabilities to not use Geopriv.  Perhaps that was a mistake. But I am 
resistent to changing the definitions that were made and agreed to by the WG.

At 07:07 PM 3/30/2006 -0600, Winterbottom, James wrote:
>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
>
> > -----Original Message-----
> > 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]
> > Subject: Re: [Geopriv] Registration of additional PIDF-LO Methods
> >
> > 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
> > >
> > >
> > >> -----Original Message-----
> > >> From: James M. Polk [mailto:[email-masked]]
> > >> Sent: Friday, 31 March 2006 8:56 AM
> > >> To: Winterbottom, James; Abbott, Nadine B; [email-masked]
> > >> Cc: [email-masked]
> > >> Subject: RE: [Geopriv] Registration of additional PIDF-LO Methods
> > >>
> > >> At 04:13 PM 3/30/2006 -0600, Winterbottom, James wrote:
> > >>> But that is my entire point James, Method is a parameter
>describing
> > > how
> > >>> location was determined NOT how it was delivered.
> > >>
> > >> no, that's not the intend of <method>
> > >>
> > >>> They are not the same
> > >>> thing!
> > >>
> > >> 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
> > >>
> > >>
> > >>> 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.
> > >>
> > >> 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
> > >>> this clarifies the issue, method describes how location was
> > > determined,
> > >>> not the type of access, and not how location was delievered.
> > >>
> > >> 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.
> > >>
> > >>
> > >>
> > >>
> > >>>> -----Original Message-----
> > >>>> From: James M. Polk [mailto:[email-masked]]
> > >>>> Sent: Friday, 31 March 2006 8:05 AM
> > >>>> To: Winterbottom, James; Abbott, Nadine B; [email-masked]
> > >>>> Cc: [email-masked]
> > >>>> Subject: RE: [Geopriv] Registration of additional PIDF-LO Methods
> > >>>>
> > >>>> James
> > >>>>
> > >>>> DHCP Relay is used in 802.11 deliveries too...
> > >>>>
> > >>>> At 11:33 AM 3/30/2006 -0600, Winterbottom, James wrote:
> > >>>>> 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
> > >>>>>
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: James M. Polk [mailto:[email-masked]]
> > >>>>>> Sent: Friday, 31 March 2006 3:30 AM
> > >>>>>> To: Abbott, Nadine B; Winterbottom, James; [email-masked]
> > >>>>>> Cc: [email-masked]
> > >>>>>> Subject: RE: [Geopriv] Registration of additional PIDF-LO
> > > Methods
> > >>>>>>
> > >>>>>> Nadine/James
> > >>>>>>
> > >>>>>> So, how do you separate "DHCP" stating it is for "wireline
> > >>> access"?
> > >>>>>>
> > >>>>>> Where cannot someone get confused?
> > >>>>>>
> > >>>>>> At 10:52 AM 3/30/2006 -0500, Abbott, Nadine B wrote:
> > >>>>>>> "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"?
> > >>>>>>>
> > >>>>>>> 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,
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> 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>http://www.iana.org/
> > >> assi
> > >>>>>>>> gnments/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
> > >>>>>>>
> > >>>>>>> _______________________________________________
> > >>>>>>> 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]
> > >>>
> > >>
> > >>
>---------------------------------------------------------------------
> > >> --
> > > --
> > >> -----------------------
> > >>> 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]
> > >
> > >
>----------------------------------------------------------------------
> > > --------------------------
> > > 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: Randall Gellens <[email-masked]>
Date: Fri, 31 Mar 2006 17:34:44 -0800

At 7:56 PM -0600 3/30/06, James M. Polk wrote:

>  This method is then to be placed into the PIDF-LO as an indication 
> to the PSAP operator to inform them so they can make certain 
> decisions based on the topology used by the caller's device.

the pidf-lo document says:

    The optional 'method' element describes the way that the location
    information was derived or discovered.

So 'Wiremap' would seem to make sense, but 'DHCP' wouldn't, since it 
would seem to describe how the location was configured into the 
device, not how it was derived or discovered.

>  I don't remember if you were part of the WG then, but cellular 
> systems were not thought of very much at that time because the WG 
> felt that their infrastructures had the necessary layer 2 
> information and capabilities to not use Geopriv.

My recollection is that cellular systems were considered from the 
very start of geopriv; as I recall, one of the main reasons for 
forming the group was concern that cellular systems would deploy 
location services that did not provide much in the way of security or 
privacy protections.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
They say that 90 per cent of TV is junk.  But 90 per cent
of *everything* is junk.
      --Gene Roddenberry, interview in TV Guide, Apr. 27, 1974
      (quoting Sturgeon's Revelation: "Ninety percent of
      everything is crap.")