Subject: [Geopriv] Moving Forward on 3825 update

From: Andrew Newton <[email-masked]>
Date: Sat, 3 Feb 2007 21:14:06 -0500

All,

Brian is right.  We need to come to conclusions on this document and  
move on.  The following are how I see the consensus of the GEOPRIV  
working group on this topic.

1) We've had long discussions regarding the difference between  
uncertainty and resolution.  While some people believe uncertainty  
information should be communicated with 3825 coordinates, there is no  
consensus within the working group to do this.

2) Likewise, there is no consensus in the working group that  
resolution should not be communicated with 3825 coordinates.  With  
this particular issue, I also weighed the chair's right to demand  
technical soundness of a document.  There were no valid answers to  
Henning's question (http://www1.ietf.org/mail-archive/web/geopriv/ 
current/msg02665.html), so I am left to conclude that this is a  
technically sound and reasonable thing to do.

3) There is rough consensus that RFC 3825 is unclear or misleading  
with respect to the type of information to be conveyed in DHCP.   
Therefore, the decision made in San Diego at IETF 67 to produce an  
update to RFC 3825 clarifying any misleading text and adding new,  
clarifying text is still the course of action for this working group.

-andy, GEOPRIV co-chair

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 3 Feb 2007 23:04:04 -0600

I didn't send an answer to Henning's question because I didn't even see how it was relevant to the discussion.
 
Here's the full substance of the post:
 
"I'm curious how you would do this with fixed-point binary numbers, unless you add a length or mask parameter of some sort."
 
What is it actually asking, how is it the same as adding a resolution parameter, and why is it fundamentally decisive to the discussion?
 
Cheers,
Martin

________________________________

From: Andrew Newton [mailto:[email-masked]]
Sent: Sun 2/4/2007 1:14 PM
To: GEOPRIV WG
Subject: [Geopriv] Moving Forward on 3825 update

All,

-andy, GEOPRIV co-chair

------------------------------------------------------------------------------------------------
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: Andrew Newton <[email-masked]>
Date: Sun, 4 Feb 2007 11:07:34 -0500

On Feb 4, 2007, at 12:04 AM, Dawson, Martin wrote:

> What is it actually asking, how is it the same as adding a  
> resolution parameter, and why is it fundamentally decisive to the  
> discussion?

Summarizing your argument, you said the resolution parameters were  
"superfluous".
Henning asked a straightforward question, "How else would you do it?"

I'm also gonna move the goal post on you (a chair's prerogative) and  
ask for a demonstration of harm.

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 4 Feb 2007 16:35:58 -0600

Andy,

The harm is crystal clear, the fact that this discussion is occurring at
all is demonstration enough.

I pose to you the question that if the location can only be determined
to within some level of uncertainty, why not simply adjust the meaning
of the resolution parameter so that it can express what it is intending
to express without ambiguity. That is, allow the encoding to express an
area in an umambiguous fashion, or express a point if that is the
desired wish of the system administrator. Currently RFC-3825 and the
proposed "informational document" do not do that.

The specification that Martin and I put together addresses all of these
concerns, AND includes a DHPCv6 option, something that is no present in
the current specification. The difference in outcome is that a single
specification then be used to understand how to encode, decode and
interpret the information, rather than having to have one specification
that provides the format, and a second specification that says "well
actually the interpretation in RFC-3825 was misleading or incorrect,
this is how you actually interpret it".

We should do the job right this time, and not simply patch the problem
with glue and cellotape.

Cheers
James

> -----Original Message-----
> Sent: Monday, 5 February 2007 3:08 AM
> To: Dawson, Martin
> Cc: GEOPRIV WG
> Subject: Re: [Geopriv] Moving Forward on 3825 update
> 
>

---

From: Andrew Newton <[email-masked]>
Date: Sun, 4 Feb 2007 20:12:26 -0500

> all is demonstration enough.

Honestly, do you really think this sentence helps your argument?

> to express without ambiguity.

And now you are attempting a bate-and-switch.  It isn't appreciated.

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 4 Feb 2007 19:32:12 -0600

I thought Henning was actually asking something else. However, your
interpretation is more useful to the discussion. I'm saying that if you
only want to communicate a point and don't want to convey anything about
area/extent/uncertainty/precision - then additional resolution
parameters are both superfluous *and* confusing *and* ultimately, a bad
thing. So I'd have to ask - with respect to your question - "how else
would you do what?"

On to the discussion of "harm"

I've asked the question - what is the recipient of the resolution
parameters supposed to infer about the nature of the values provided in
the coordinate parameters? I still haven't seen a sensible answer to
that. The coordinate parameters already have their own resolution (34
bits) so the resolution parameter must be trying to say something else
about the nature of coordinate values.

The harm comes about from the following:

1. In this context "resolution" must mean the same as "precision" (until
somebody can tell me what else it's supposed to say about the location
value)
2. Precision/resolution indicates the best communicable accuracy. For
example, a precision of mm typically means a measured accuracy of +/-
0.5mm (though it's actually necessary to document the convention for
interpreting precision as used in any specific context)
3. Since the server decided to utilize a communicable precision less
than the protocol could support, it must be trying to say something else
about the nature of the location value or the location measurement.
4. Recipients of RFC3825 resolution values have to infer something from
them. They are going to assume it means accuracy.
5. Administrators of DHCP servers are going to assume they have to put
something meaningful in the resolution parameter values. They are going
to assume it means accuracy or area.
6. Administrators are eventually going to realize they can't represent
what they want to by using this prescribed "significant digits method"
and are going to question what the purpose of these resolution
parameters is or else they are just going to provide some inappropriate
value.
7. This issue will continue coming up in mailing lists and other forums
in perpetuity.
8. There are going to be multiple instances of location recipients
inferring something quite incorrect from the resolution values and
applying erroneous processing to the reported location.

Finally - here's my challenge to you. There appears to be agreement
that, whatever the RFC is trying to say these parameters are for, it
doesn't do a good job of it. Could you please send what you think would
have been useful text - not just something saying it means "resolution"
but something which explains what the recipient of the parameters is
supposed to interpret them as meaning and how they are useful to the
recipient?

Cheers,
Martin

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Monday, 5 February 2007 3:08 AM
To: Dawson, Martin
Cc: GEOPRIV WG
Subject: Re: [Geopriv] Moving Forward on 3825 update

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 4 Feb 2007 19:42:00 -0600

"Bait and switch?" I don't think so.

I think, like me, James feels that any honest attempt to explain the
purpose of the resolution parameters while still maintaining that the
intent is not to say anything about area or uncertainty will fail.

This is a reasonable request.

I think when we raised this issue, we thought there'd be a reasonable
response that said "Oh, yes, that's problem - we did mean
area/uncertainty; let's just fix it". Instead it's been a process of
contradicting previous statements about the parameters conveying "rings"
and "rectangles" to stating that "no, it's just a point" but somehow
these parameters are still meaningful they just mean.... "resolution".
I, for one, am puzzled by the determination to keep a self-evidently
contradictory position in play in a specification.

But - it's not my specification, and it's not my legacy. Clearly the
stake holders here will do what they like with it whatever the rationale
is.

Cheers,

Martin

From: Andrew Newton [mailto:[email-masked]] 
Sent: Monday, 5 February 2007 12:12 PM
To: Winterbottom, James
Cc: GEOPRIV WG
Subject: Re: [Geopriv] Moving Forward on 3825 update

-andy

---

From: Andrew Newton <[email-masked]>
Date: Sun, 4 Feb 2007 21:05:03 -0500

> interpreting precision as used in any specific context)

You have subtly intertwined accuracy with resolution at this point.   
Perhaps that is where you are getting confused.

> them. They are going to assume it means accuracy.

To be precise, you have assumed that they will make this mistake.   
This is not an argument based in known fact.

> supposed to interpret them as meaning and how they are useful to the

I can go you one better.  There is a entire draft written on the  
subject: http://www.ietf.org/internet-drafts/draft-ietf-geopriv- 
binary-lci-00.txt

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 4 Feb 2007 20:26:35 -0600

Andy,

> This is not an argument based in known fact.

Here is a direct quote from one of the authors of RFC-3825. Perhaps it
is no wonder that the notion of an area is so widely accepted as being
the correct interpretation.
(http://www1.ietf.org/mail-archive/web/ecrit/current/msg02588.html)

"BTW - RFC3825 has resolution as part of its solution.  This creates a
GML defined Linear Ring, which is 100% accurate 100% of the time that
the target is within that ring.  This concept can be taken out to a cell
tower's coverage area too (i.e. provide the polygon - regardless of
shape - the target is within in the PIDF-LO)."

Now perhaps we can:

1) Agree that the intent of what RFC-3825 is intending to convey has
CHANGED!

2) That the current resolution parameter was intended to provide an
uncertainty value, and it doesn't do it very well.

The problem needs to be fixed, not patched. 

Cheers
James

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 4 Feb 2007 22:36:18 -0600

I'm familiar with that document - it's part of the history of this
issue. This document describes how to go about creating and translating
the resolution parameters as the DHCP admin and location recipient
respectively. It doesn't address the issue.

It perpetuates the contradiction. We need to start with the stated
proposition that the encoding just provides a point and says nothing
about uncertainty/error etc.

The useful text for the DHCP administrator says:

Where a geographic location comes with an explicit error specification,

this error can be translated into the resolution of the LCI.

Hmmm... "error". If I'm only interested in conveying a point location,
then I don't need to be trying to communicate information that is a
consequence of errors. The document proceeds to prescribe how to
construct the resolution parameters from the "bounding points of a
region".

Find the maximum and minimum of both, calculate the value of the
latitude/longitude as the average, and half the difference as  

the error.

If all I want to communicate is a point, then why are region bounding
errors driving what I am communicating?

The text describing how the recipient is supposed to use the resolution
parameters starts with:

Translation from the binary resolution of the LCI to the correct number
of  
significant decimal digits in the character string representation used
for  
numbers in PIDF-LO is as in the following example for Latitude:

Leaving aside the somewhat far-fetched premise that the original
intention was to tell recipients how to encode the PIDF-LO (why didn't
they just send the coordinates as strings then - and in what way is DHCP
so genetically linked to geopriv that the latter gets special
consideration from the former?), this still does not tell the recipient
what the intention of communicating "significant digits" is. What is the
recipient meant to make of this? What are they being told about the
insignificant digits?

I think the only answer is that they are being told the actual location
could be something other than the one provided.

I had hoped, Andy, that you would provide me your own honest description
of what you think "resolution" means as it is communicated in this
protocol. What is the recipient supposed to construe from it? I was
hoping that by doing this exercise you would see that it's highly
problematic to do so without assuming that something is being
communicated beyond a simple point location. I'm not confused about the
meanings of the terms "resolution" and "accuracy". You can't ban them
from being used in the same paragraph. In order to explain the intent of
"resolution" you have to use some other words appropriate to the
context. If I was talking about telescopes, I'd be using different words
to explain resolution in that context. When it comes to a location
value, I do not see how it can't end up being about
area/extent/uncertainty/error...

Cheers,

Martin

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Monday, 5 February 2007 1:05 PM
To: Dawson, Martin
Cc: GEOPRIV WG
Subject: Re: [Geopriv] Moving Forward on 3825 update

On Feb 4, 2007, at 8:32 PM, Dawson, Martin wrote:

> 1. In this context "resolution" must mean the same as  

> "precision" (until

> than the protocol could support, it must be trying to say something  

> else

> 4. Recipients of RFC3825 resolution values have to infer something  

> from

> doesn't do a good job of it. Could you please send what you think  

> would

> have been useful text - not just something saying it means  

> "resolution"

binary-lci-00.txt

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 5 Feb 2007 09:20:09 -0500

Martin,
 
Since you continually are asking for 'description of what you think
"resolution" means as it is communicated in this protocol'
 
How about this:
 
The user of the location data, the DHCP client, is assured that the value
derived from the DHCP option is the same as the value input by the wire map
admin.
 
-Marc-

---

From: Andrew Newton <[email-masked]>
Date: Mon, 5 Feb 2007 10:06:24 -0500

Martin, James,

I understand that you do not like the current decision of the working  
group, but that does not change it.  Your arguments have been heard,  
repeatedly.  You have pointed out several deficiencies in the spec,  
and for that we are grateful.  However, it is time to let the working  
group progress on its milestones.

-andy, co-chair of GEOPRIV

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 5 Feb 2007 17:28:17 -0600

OK - the establishment has spoken. As I say, it's not my legacy.

Cheers,
Martin

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Tuesday, 6 February 2007 2:06 AM
To: Dawson, Martin; Winterbottom, James
Cc: GEOPRIV WG
Subject: Re: [Geopriv] Moving Forward on 3825 update

Martin, James,