Subject: [Geopriv] Resolution in RFC3825

From: "Marc Linsner" <[email-masked]>
Date: Thu, 13 Jul 2006 10:31:09 -0400

[list and subject changed to reflect topic]
 
James,
 
Appendix A in the draft-ietf-geopriv-pdif-lo-profile-04.txt is wrong.
RFC3825 represents a point, and uncertainty is never mentioned, nor intended
to be represented in LCI.  I am still searching for use cases were RFC3825
may apply that uncertainty is normally expressed.  

The fixed-point 2s-complement binary value in RFC3825 is also fixed at 34
bits of length.  If the value one is attempting to represent does not match
the 34-bit resolution allowed for, then it is prudent to express the desired
resolution.  If this feature were not available, it would lead one to
believe that 39.6 equals 39.60000000, which as you know, is bad in the
application of geo coordinates.

A side symptom of expressing resolution also filled the very desired
requirement in GeoPriv of the ability to 'fuzz up' the location.  Using the
example above, 39.6 implies 39.60000000 to 39.69999999, which at this
resolution covers a large territory.  This ability to represent this large
territory satisfied this Geopriv requirement.  The requirement was to simply
fuzz the location value, not express exact fuzziness, hence resolution is
not suitable to express uncertainty.

I hope this helps,

-Marc-

________________________________

	From: Winterbottom, James [mailto:[email-masked]] 
	Sent: Wednesday, July 12, 2006 7:35 PM
	To: Marc Linsner
	Cc: [email-masked]
	Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New
phonebcpdraftwassubmitted)

	Marc you are missing the point entirely.

	No one is required to convey uncertainty, but RFC-3825 stipulates
quite clearly how the values returned in option 123 are to be interpreted.

	The shape described by the encoding in RFC-3825 is either a 4 sided
polygon, or a prism, unless you use the maximum resolution, hence
uncertainty is part of the interpretation and mobility 

	has absolutely nothing to do with it.

	Are you suggesting that the way to interpret the values in RFC-3825
is not normative?

	________________________________

		From: Marc Linsner [mailto:[email-masked]] 
	Sent: Thursday, 13 July 2006 9:22 AM
	To: Winterbottom, James
	Cc: [email-masked]
	Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New
phonebcpdraftwassubmitted)

	Please identify the non-mobile application(s) that use geo and are
required to convey uncertainty.

	-Marc-

		Marc, this has nothing to do with mobile. It is to do with
the potential for massive errors to be introduced by the encoding technique
used in RFC-3825. Please see appendix A of PIDF-LO profile for more details.

		 

		________________________________

				From: Marc Linsner
[mailto:[email-masked]] 
		Sent: Wednesday, 12 July 2006 11:34 PM
		To: Winterbottom, James; 'Stark, Barbara'; 'Andrew Newton';
'Rohan Mahy'
		Cc: 'Rosen, Brian'; [email-masked]
		Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New
phonebcpdraftwassubmitted)

		As stated in RFC3825, it is applicable to non-mobile
environments.

		-Marc-

			________________________________

						From: Winterbottom, James
[mailto:[email-masked]] 
			Sent: Tuesday, July 11, 2006 11:39 PM
			To: Stark, Barbara; Andrew Newton; Rohan Mahy
			Cc: Rosen, Brian; [email-masked]
			Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New
phonebcpdraftwassubmitted)

			I would be very cautious about recommending the use
of RFC-3825 encoding to report emergency locations given the issues raised
at IETF-65 in Dallas that are yet to be adequately resolved. In NENA we put
a caveat around its use to the effect that location provided in this manner
must be regarded as a point only, and that encodings for resolution must be
ignored.

			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] 

			*****

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

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 13 Jul 2006 09:49:25 -0500

I don't think that we need to re-open this discussion - I have explained
previously why the argument below is wrong; I suggest that you read the
archives.

> -----Original Message-----
> Sent: Friday, 14 July 2006 12:31 AM
> To: Winterbottom, James
> Cc: 'GEOPRIV'
> Subject: [Geopriv] Resolution in RFC3825
> 
> requirement in GeoPriv of the ability to 'fuzz up' the location.
Using
> the
> 						From: Winterbottom,
James
> at IETF-65 in Dallas that are yet to be adequately resolved. In NENA
we
> put
> must be regarded as a point only, and that encodings for resolution
must
> be
------------------------------------------------------------------------
--
> --
------------------------------------------------------------------------
--
> --
> dissemination or other use of, or taking of any action in reliance
upon
> this
------------------------------------------------------------------------
--
> --
sender
> 		this email is prohibited.
------------------------------------------------------------------------
--
> --
------------------------------------------------------------------------
--
> --
information.
> 	this email is prohibited.
------------------------------------------------------------------------
--
> --

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

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 13 Jul 2006 11:18:43 -0400

Martin,

I remember the previous thread, I did not start this one.

Your conclusion in the previous thread was 'LCI resolution/uncertainty is
not useful'.

I believe what I wrote below agrees with the uncertainty portion of your
conclusion, but disagrees with your conclusion about resolution.  My
explanation is the understanding of the GeoPriv WG and the IESG which
approved RFC3825.

Again, if you can show a use case where RFC3825 is desired and uncertainty
needs to be conveyed, please identify it.

-Marc-

> From: Thomson, Martin [mailto:[email-masked]] 
> Sent: Thursday, July 13, 2006 10:49 AM
> To: Marc Linsner; Winterbottom, James
> Cc: GEOPRIV
> Subject: RE: [Geopriv] Resolution in RFC3825
> 
> I don't think that we need to re-open this discussion - I 
> have explained previously why the argument below is wrong; I 
> suggest that you read the archives.
> 
> > RFC3825 represents a point, and uncertainty is never mentioned, nor 
> > intended to be represented in LCI.  I am still searching 
> for use cases 
> > were
> RFC3825
> > The fixed-point 2s-complement binary value in RFC3825 is 
> also fixed at
> 34
> > bits of length.  If the value one is attempting to 
> represent does not 
> > match the 34-bit resolution allowed for, then it is prudent 
> to express 
> > the desired resolution.  If this feature were not 
> available, it would 
> > lead one to believe that 39.6 equals 39.60000000, which as 
> you know, 
> > is bad in the application of geo coordinates.
> > 
> > territory satisfied this Geopriv requirement.  The 
> requirement was to 
> > simply fuzz the location value, not express exact fuzziness, hence 
> > resolution
> is
> > the potential for massive errors to be introduced by the encoding 
> > technique used in RFC-3825. Please see appendix A of 
> PIDF-LO profile 
> > for more details.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 		As stated in RFC3825, it is applicable to 
> non-mobile environments.
> > 
> > 
> > 
> > 		-Marc-
> > 
> > 
> > 
> > a caveat around its use to the effect that location 
> provided in this 
> > manner must be regarded as a point only, and that encodings for 
> > resolution
> must
> > be
> > ignored.
> > 
> > 
> > 
> > 			Cheers
> > 
> > 			James
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 14 Jul 2006 08:28:08 -0500

Hi Marc,

OK, consider the can opened.

All of your (and by "your" I also refer to James and John in previous
threads) assertions about resolution seem to indicate that it is somehow
different to uncertainty.  Yet every definition I see presented for
"resolution" unambiguously describes uncertainty.

Your use case is described in RFC 3825 - you know that the target is on
a certain floor of the Sears Tower, but not necessarily precisely where
on that floor.  That is uncertainty, and this is actually a pretty good
use case, people are often in buildings.

I'd also like to point out that the "fuzz up" property you describe
below has very little merit, given the role that DHCP plays.  For
privacy purposes, this does not provide a target any value, since they
are the ones consuming this information.  The only entity that is
protected in any way by this obfuscation is the operator of the network;
however, since the information can be derived from other sources if the
target is present at that location, this really isn't of much use to
anyone.  The only conceivable use is to indicate measurement errors, but
then we are back to uncertainty again.

Cheers,
Martin

> Sent: Friday, 14 July 2006 1:19 AM
> To: Thomson, Martin; Winterbottom, James
> Cc: 'GEOPRIV'
> > > resolution covers a large territory.  This ability to represent
this
> > large
> > > of RFC-3825 encoding to report emergency locations given the
issues
> > raised
> > > information by persons or entities other than the intended
recipient
> > is
> > > prohibited. If you received this in error, please contact the
sender
> > and

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 14 Jul 2006 17:38:52 -0500

Martin

There is zero uncertainty in resolution.  LCI knows for a fact, as in 100%, 
that the target is within the resolution given.  Resolution purposely 
doesn't place the target at the center of the given boundaries.

This is different than uncertainty.

Uncertainty is related more to accuracy, which is not the same as 
resolution. There are ample threads about this early in the WG, also 
discussed at several consecutive meetings - which have meeting minutes of 
each.  Please investigate these for a refresher.

As proof, you do not read the word "accuracy" in the final version of RFC 
3693, but it was there in previous versions at the ID level.

This point had complete WG consensus, please stick with that fact moving 
forward, especially since this was decided by the WG in mid 2003.

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 17 Jul 2006 18:46:36 -0500

James,

Your statement below shows a misunderstanding of the difference between
uncertainty and confidence with respect to how they are applied to
location systems. Uncertainty defines an enclosed space (area or volume)
in which a target is alleged to be. Confidence defines the probability
or likelihood that the target is in the specified space. Confidence is
often expressed as a probability or percentage. What you are saying is
that the confidence factor of LCI is 100%, and I don't have an opinion
about this either way, and since PIDF-LO does not have a standard way to
convey confidence it seems a little irrelevant.

LCI provides an encoding scheme for expressing an enclosed space, either
as a rectangle, or a rectangular prism. It doesn't place you in the
centre I agree, it provides a position at one of the corners and says
"extrapolate" to the next significant digit in directions x, y and z,
based on the resolution supplied. The result is that and you are
somewhere in resulting defined space. This is clearly described in
section 2.1 "smaller value in the resolution field increases the area
within which the device is located". My interpretation of this
definition is that the object/device is somewhere in that space, but I
don't know exactly where. This is consistent with the definition of
uncertainty provided above.

After having looked through the entire email archive and all the meeting
minutes since this draft was introduced I find little evidence that this
concept has been adequately discussed or explained. Indeed the draft
minutes for the mid 2003 WG meeting indicate that you were not present
at the WG session, and they do not reflect detailed discussions on
resolution vs confidence and uncertainty. There is passing mention of a
discussion between Jon Peterson and John Schnizlein on "Coarseness", the
exact outcome is unclear from the minutes, but again this sounds like
uncertainty to me.

Just looking at yours and Marc's emails there does not appear to be
consensus even between you two on what is represented in the RFC-3825
encoding technique. Marc indicates that it is a point, and you suggest
in your email that it is a bounded area. Which is it?

Ultimately LCI requires the end-point to produce a PIDF-LO, and the
resulting location based on the encoding scheme in RFC-3825 is a
rectangular polygon or prism depending on the number of dimensions
provided. When this shape/volume is created by the end-point errors are
introduced based on the encoding scheme and in many cases these may be
significant. Since you cannot predict ahead of time the magnitude of the
errors introduced this encoding scheme is simply not suitable "as is"
for use in emergency shape representation. This is quite simply a matter
of public safety.

Cheers
James

> From: James M. Polk [mailto:[email-masked]]
> Sent: Saturday, 15 July 2006 8:39 AM
> To: Thomson, Martin; Marc Linsner; Winterbottom, James
> Cc: GEOPRIV
> > > Your conclusion in the previous thread was 'LCI
resolution/uncertainty
> >is
> > > not useful'.
> > >
> > > I believe what I wrote below agrees with the uncertainty portion
of
> >your
> > > > > RFC3825 represents a point, and uncertainty is never
mentioned,
> >nor
> > > > >   The shape described by the encoding in RFC-3825 is either a
4
> > > > sided
> > > > >   Please identify the non-mobile application(s) that use geo
and
> > > > are
> > > > >           Marc, this has nothing to do with mobile. It is to
do
> > > > with
> > > > >                   Subject: RE: LLDP-MED and Phone BCP (Re:
[Ecrit]
> > > > New
> > > > >                   I would be very cautious about recommending
the
> > > > use
> > > > > at IETF-65 in Dallas that are yet to be adequately resolved.
In
> >NENA
> > > > >                   If you have received it in error, please
notify
> > > > >                   The information transmitted is intended only
for
and
> > > > may
private
> > > > >           immediately and delete the original. Any
unauthorized
> > > > use of
information.
>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------

---

From: John Schnizlein <[email-masked]>
Date: Tue, 18 Jul 2006 07:14:02 -0400

There is no need to question James' understanding.  There is also no 
need to explicate the measurement principles in GeoPriv document 
because they apply to all measurement, not just to location 
measurement.

The representation of resolution in RFC 3825 follows established 
scientific and engineering practice rather than inventing new concepts 
and definitions.  What is relevant here is the concept of significant 
figures - which is in binary for efficient computer communication.  The 
number of significant digits is explicit in RFC 3825 rather than 
relying on syntactic hints to indicate significance.

"The concept of significant figures originated from measuring a value 
and then estimating one degree below the limit of the reading; for 
example, if an object, measured with a ruler marked in millimeters, is 
known to be between six and seven millimeters and can be seen to be 
approximately 2/3 of the way between them, an acceptable measurement 
for it could be 6.6 mm or 6.7 mm, but not 6.666666 mm as a recurring 
decimal. This rule is based upon the principle of not implying more 
precision than can be justified when measurements are taken in this 
manner. Teachers of engineering courses have been known to deduct 
points when scoring papers if excessive significant figures are given 
in a final answer."
http://en.wikipedia.org/wiki/Significant_figures

If this was not clear in the archives, I am sorry.  It is possible that 
the effort to show how reducing the resolution of a measurement to 
partially hide location (implying an area rather than a point with low 
resolution) contributed to confusion.  New interpretations of that text 
should not interfere with the fundamental concept intended in RFC 3825.

At some point we might ask the WG chairs to apply some analog of the 
practice of "teachers of engineering courses".  ;-)

John

---

From: Andrew Newton <[email-masked]>
Date: Tue, 18 Jul 2006 08:54:59 -0400

On Jul 18, 2006, at 7:14 AM, John Schnizlein wrote:

> At some point we might ask the WG chairs to apply some analog of  
> the practice of "teachers of engineering courses".  ;-)

I had one engineering prof that use to throw chalk and erasers at  
students.  At first I thought it was for comic relief, but one day  
when his aim was off I found out differently.  Regardless, it is a  
little hard to replicate his teaching methodology over email.

-andy