Subject: RE: [Geopriv] RFC 3825 Updates

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 4 Jan 2007 21:07:54 -0600

The reason for the "unsolicited -bis personal submission" was to highlight and address the deficiencies in existing documents, including the binary-lci draft.

"Programming Hints" aren't what is needed; it's not necessary to tell people how to parse 34-bit twos complement numbers.  What is needed is a clear definition of what the bits mean.  All that binary-lci does is cloud the issue by providing a contradictory example.  If binary-lci is published, there will be two interpretations.  The -bis provides a clear definition.

> -----Original Message-----
> From: John Schnizlein [mailto:[email-masked]]
> Sent: Thursday, 28 December 2006 8:09 AM
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [Geopriv] RFC 3825 Updates
> 
> The high-level strategy AFAICT is to proceed as indicated by the San
> Diego meeting
> <http://www3.ietf.org/proceedings/06nov/minutes/geopriv.txt>.
> There is no consensus that a revision of RFC 3825 is necessary.
> You may have been surprised by the unsolicited -bis personal
> submission, as I was.
> 
> I have debugged the sample code in the geopriv-binary-lci draft, and
> added the explicit indication requested in San Diego that the appendix
> of RFC 3825 does not specify arbitrary region boundaries.  This WG
> draft should appear soon in the Internet-Draft repository.
> 
> As to what "we want to accomplish", the WG has been fairly clear that
> the interpretation of RFC 3825 as specifying regions with arbitrary
> boundaries should be clarified.  That is what the binary-lci draft
> does.  The purpose of RFC 3825 has not changed from its original intent
> to configure a host with its location (presumably on a wired network
> attachment).
> 
> Answers to your questions embedded in context:
> 
> On Dec 27, 2006, at 2:10 PM, Hannes Tschofenig wrote:
> 
> > Hi all,
> >
> > I read through the two available drafts on this subject. I would like
> > to hear something about the high-level strategy. What do we want to
> > accomplish?
> >
> > a) Allow a point (lat/long/alt) to be returned?
> 
> It does just that.

I believe that the -bis makes this clearer.  Changing the meaning of an uncertainty value (formerly resolution) of 0 makes this totally clear.

> 
> > b) Allow a way to reduce the precision?
> 
> It does that through the ability to include a lower resolution than
> measured.

By changing the meaning (as both the -bis and binary-lci do), this is actually more robust than in previous incarnations.  The point can be randomized, and the amount of randomization can be added to the uncertainty.

> > A rectangular prism would be returned but the Target is located
> > somewhere within this
> > rectangular prism (random placement, not in the center).
> 
> While interpretations of the implication of the resolution parameters
> as regions have been shown to be fraught with (unnecessary IMHO)
> controversy, these implications are explored in the appendix of RFC
> 3825.

True - but that exploration is the source of the problem.

> 
> > c) Allow a way to offer uncertainty information? (see James/Martin
> > draft)
> 
> My favorite definition of uncertainty is from Claude Shannon's
> Mathematical Theory of Communication
> H = sum (p * log (p)) - the top of page 11 of
> http://cm.bell-labs.com/cm/ms/what/shannonday/shannon1948.pdf

I fail to see how the formula for Information Entropy relates to this discussion. 

> Those who want background on the widely understood concept of
> uncertainty should review
> http://en.wikipedia.org/wiki/Uncertainty
> 
> Significant figures (which RFC 3825 specifies) are mentioned there as a
> use of uncertainty in engineering.  Special interpretations from
> cellular telephone contexts are not applicable.

Read the second section of the Wikipedia article.

More from Wikipedia:
http://en.wikipedia.org/wiki/Significant_figures

  "Significant figures can also refer to a crude form of error representation based around significant figure rounding"

And this gives a better perspective on significant figures:
http://www.av8n.com/physics/uncertainty.htm

When have cellular telephone contexts been involved in this discussion?  The point has always been that there is uncertainty in the measurement of a position.  That doesn't change, in any context.  The only bearing that cellular telephony has on the topic is that they solved that problem years ago and have since moved on.

> > d) Allow more complex shapes to be returned? (e.g., a rectangular
> > prism)
> 
> The purpose of RFC 3825 is to configure the location of a host, not a
> region of space. No good reason has been justified for changing this.
> As Henning has pointed out in the emergency-response case, determining
> which region of jurisdiction contains a point is difficult enough -
> determining which region a region is in is much more difficult.  Why
> add complexity that makes this life-and-death case more difficult?

Using a point is an approximation that, for routing purposes, is a good tradeoff of complexity against accuracy.  It can be demonstrated that it isn't optimal, but a great deal of complexity is avoided.

For DHCP, I don't see the point in returning complex shapes.  It already provides a means to represent a rectangular prism.  As a crude representation of uncertainty, it's sufficient.  Given the limited cases where DHCP is useful, this shouldn't present a major problem.  Adding encodings for circles, ellipses, and so forth only increases complexity.

Wikipedia again:
http://en.wikipedia.org/wiki/Appeal_to_fear

> 
> > Everything is fine for me. Obviously the description is different for
> > each time.
> >
> > In some sense I would also be interested to learn what the main use
> > cases for RFC 3825 are. I can see the civic version being more useful
> > in a number of places. The use cases might actually give some hint
> > about the required functionality.
> >
> > Ciao
> > Hannes
> >
> > PS: I would also remove the floor level way to specifying the altitude.
> >
> > _______________________________________________
> > 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]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 5 Jan 2007 09:45:03 -0500

Martin, 
 
> 
> When have cellular telephone contexts been involved in this 
> discussion?  The point has always been that there is 
> uncertainty in the measurement of a position.  That doesn't 
> change, in any context.  The only bearing that cellular 
> telephony has on the topic is that they solved that problem 
> years ago and have since moved on.
> 

Could you please identify consumer geo applications outside of the cellular
telephone context where uncertainty (error in measurement) is expressed?

In my limited exposure, I've looked at marine and aviation, neither of which
express uncertainty as a separate entity.

What isn't clear to me is the value of conveying uncertainty in the context
that DHCP serves.

-Marc-

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 7 Jan 2007 16:49:51 -0600

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Saturday, 6 January 2007 1:45 AM
> To: Thomson, Martin
> Cc: [email-masked]
> Subject: RE: [Geopriv] RFC 3825 Updates
> 
> Martin,
> 
> >
I think that you need to realize that this isn't about cellular telephony; it's about how location is determined.  I think that you will find that the same constraints apply in any wireless system, e.g. Mobile WiMAX.

> express uncertainty as a separate entity.
Marine and aeronautical navigation are bad examples.  I'm sure air traffic control would be extremely nervous if they had to deal with 10km uncertainty.  Fortunately, GPS is very good on open water, or in the sky, and systems like WAAS (which are specifically tuned for airports and the like) are very good at getting down to good precision.  Planes and boats are pretty big, so 5 metres is probably good enough, and 5 metres is pretty poor by current standards.

> What isn't clear to me is the value of conveying uncertainty in the
Then perhaps we should deprecate the 3825 resolution/uncertainty parameters, because that's what they convey.

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 7 Jan 2007 18:07:52 -0600

Hi Marc,

Happy New Year.

The fundamental issue - regardless of whether the preference is for the
RFC to provide an uncertainty measure or not - is that it does currently
provide an uncertainty measure and not a very good one. That's why the
recent clarification document didn't clarify; it only reinforced the
contradiction.

Perhaps the authors weren't particularly used to representing analog
values in a specification. It's common, of course, to represent real
values by a specific size encoding - floating point numbers are
constrained by machine word sizes or the on-the-wire encoding
convention. Generally, systems don't find it necessary to add an adjunct
parameter to re-state the implicit precision. The assumption is that the
value being communicated is, in fact, a specific point, an absolute
value. It is the actual real, rational, number represented by the
available resolution. Digits beyond the constrained resolution are
assumed to be zero. Yes, it means the encoding system has gaps in the
real number space that it can't represent but that's just accepted.

So, the RFC starts with a nice constrained precision for representing
the lat/lon values. If a location generator only needs a subset of those
bits, then it just needs to use that number of bits. The values it sets
the remaining bits to are not relevant. They may as well be set to zero,
but they could be set to anything else - remembering that the intent is
not to communicate anything about the accuracy of the measurement.

But then the RFC goes on to describe an additional parameter. It states,
quite literally, that the number of bits indicated by this parameter may
actually have the value of zero or one. Now we are not communicating a
single value any more, we are communicating 2^n possible values for lat
and lon with the statement that the actual value is only one of these
(uncertainty) - or that the location being communicated actually covers
all of these points (extent).

This goes beyond just communicating a point without uncertainty. This is
communicating a set of points, an area and/or an uncertainty.

There's nothing wrong with this concept if it's what is intended. As
discussed, some systems do this. If the intent was to provide this then
the problem is that the mechanism is faulty. Most systems do this by
providing an absolute scalar value of uncertainty or extent. The RFC
does it by enumerating a number of bits of precision. The failure of
this mechanism is that it embodies artifacts that effectively mean the
server cannot communicate an arbitrary value of uncertainty or extent as
it would desire. In fact, the value of uncertainty or extent that it can
communicate ends up on depending where the point location is - which is
a highly undesirable characteristic.

So - if the intent of the RFC is to only communicate an absolute value
without uncertainty, then this parameter should never have been part of
the definition. The RFC should be modified to remove it. If the intent
is that uncertainty can be communicated, then the mechanism should fixed
in the RFC. Martin's bis document attempts to address it from the latter
perspective with minimal perturbation to the authors' original
treatment. The contradiction needs to be dealt with one way or the
other.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Saturday, 6 January 2007 1:45 AM
To: Thomson, Martin
Cc: [email-masked]
Subject: RE: [Geopriv] RFC 3825 Updates

Martin, 
 
> years ago and have since moved on.

Could you please identify consumer geo applications outside of the
cellular
telephone context where uncertainty (error in measurement) is expressed?

In my limited exposure, I've looked at marine and aviation, neither of
which
express uncertainty as a separate entity.

What isn't clear to me is the value of conveying uncertainty in the
context
that DHCP serves.

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 8 Jan 2007 10:37:58 -0500

Martin,

in-line...

> > cellular telephone context where uncertainty (error in 
> measurement) is 
> > expressed?
> > 
> I think that you need to realize that this isn't about 
> cellular telephony; it's about how location is determined.  I 
> think that you will find that the same constraints apply in 
> any wireless system, e.g. Mobile WiMAX.
> 

Again, RFC3825 states that dhcp is not a good LCP mechanism for mobile
devices.  The point is that location determination for something that
doesn't move allows for precision such that determination error is
insignificant.

> > which express uncertainty as a separate entity.
> > 
> Marine and aeronautical navigation are bad examples.  I'm 
> sure air traffic control would be extremely nervous if they 
> had to deal with 10km uncertainty.  Fortunately, GPS is very 
> good on open water, or in the sky, and systems like WAAS 
> (which are specifically tuned for airports and the like) are 
> very good at getting down to good precision.  Planes and 
> boats are pretty big, so 5 metres is probably good enough, 
> and 5 metres is pretty poor by current standards.

I wasn't referring to locating mobile boats or airplanes, I'm referring to
the location of fixed objects like runway marker beacons, or harbor channel
markers.  These objects, like hardwired ethernet jacks, are not mobile,
hence the associated location determination/survey is afforded adequate
accuracy for the application.  Adequate accuracy equates to uncertainty
being not needed nor helpful.

Is there disagreement here?

> > context that DHCP serves.
> > 
> Then perhaps we should deprecate the 3825 
> resolution/uncertainty parameters, because that's what they convey.

Since RFC3285 defines a fixed-length value, how would you then suggest to
use the mechanism if your starting value was of lesser resolution than
allowed?  Again 38.9 does not equal 38.9000000.  If in fact 38.9 was what I
want to convey, accurate enough for my application, then I should not be
constrained to express 7 digits right of the point.  Conveying resolution
associated with the fixed-length value is appropriate.

-Marc-