Subject: [Geopriv] draft-thomson-geopriv-3825bis-01.txt

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2007 00:35:25 +0100

I read through the draft and came across the example.

I like it but I have a question. The example shows a polygon that 
describes the Sydney Opera House.
It is a nice but I wonder whether this is the typical example. In past 
discussions we wanted to address the problem that geodetic location 
information is distributed in a WLAN (as an example). Now, I don't think 
that the resulting area where the Target can be found is typically a 
polygon. I guess that the typical area is a circle (or something similar).

Hence, I believe it would be more realistic to assume that the area 
where the Target is located is something close to a circle.
As such, the PIDF-LO would most likely carry a circle shape as well.

Ciao
Hannes

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

---

From: [email-masked]
Date: Mon, 26 Nov 2007 08:01:22 +0000

Hannes Tschofenig <[email-masked]> wrote:
> In past discussions we wanted to address the problem that geodetic 
location 

> polygon. I guess that the typical area is a circle (or something 
similar).

I've run long range WLAN services in the recent past.

The typical coverage area was only ever circular for marketing purposes...

Ray

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2007 10:14:49 +0100

Hi Ray,

thanks for the feedback.

So, can you give us some feedback what the typical coverage area for 
your WLANs was?

Ciao
Hannes

[email-masked] wrote:
>> polygon. I guess that the typical area is a circle (or something 
>>     
> similar).
>

---

From: [email-masked]
Date: Mon, 26 Nov 2007 09:34:14 +0000

> So, can you give us some feedback what the typical coverage area for 

"polygonal" probably covers most of the possibilities.

However it's worth noting that WLAN coverage tends not to be completely 
binary either since it depends on the sensitivity of the individual radio 
receivers and the gain on the client antenna.

You can see some examples from a Google Images search for "wifi coverage 
map".  The one at <
http://www.myrtletown.net/pics/myrtletown_wifi_coverage_map_r2.jpg> is a 
particularly good example.

Ray

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2007 10:58:27 +0100

Hi Ray,

thanks for the good feedback.

I think there are three aspects to consider here:

a) Case where the location of the access point is returned.

This would be a point. The assumption would be that the Target is 
somewhere close but unknown where exactly.

b) Case where the location of the coverage area is returned. In this 
case the example of Martin's draft and your Wifi coverage example would 
be relevant 
http://www.myrtletown.net/pics/myrtletown_wifi_coverage_map_r2.jpg
In this case, using RFC 3825 one can only do a rough approximation.

c) Case where the location of the Target itself is being determined. 
Depending on the used location determination technique the result the 
shape type will be correspondingly. Do you have an experience about the 
used shapes that are going to be produced? Since the area is pretty 
small (given the size of typical WLANs in comparison to cell sizes in 
cellular systems) I wonder whether a likely shape type isn't a circle.

Ciao
Hannes

BTW:

In RFC 4776 there is the "What" field that allows you to express the 
fact that the location refers to the access point (or a similar node 
close to the Target). With RFC 3825 there is unfortunately not such 
mechanism available.

In PIDF-LO one could express the fact that you are not distributing the 
location of the Target but rather of the access point by setting
the entity field to the address of the access point. Additionally, one 
can put location into the device, person, tuple part of the PIDF-LO 
document.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2007 11:02:38 +0100

Looking closer at the map you sent me
http://www.myrtletown.net/pics/myrtletown_wifi_coverage_map_r2.jpg
I wonder what type of WLAN that is that spans such a large area.

This seems to be the map of the entire WLAN network. The stuff we are 
interested in is about individual access point coverage areas. I hope 
that one can provide the coverage of the access point at least rather 
than the coverage of the entire network.

Ciao
Hannes

---

From: [email-masked]
Date: Mon, 26 Nov 2007 10:34:25 +0000

> cellular systems) I wonder whether a likely shape type isn't a circle.

My own experience is with 802.11a Fixed Wireless Access systems running at 
5.8 GHz, where we actually knew the location of every Target anyway.

The nominal cell size was typically 3km radius though, which is comparable 
in size to rural cellular systems, and a lot larger than an urban cell.

WiMAX systems for mobile users (802.16e) could operate on similarly sized 
cells and obviously the operator wouldn't then know the end user location.

Large area WLANs tend to use sectorized nodes (just like mobile phone 
cells) and not omnidirectional antennas.  Each sector would use a 
directional antenna, with a gain pattern similar to <
www.netgate.com/info/antennas/pattern_hg5817d.png>.  You'd then get holes 
in the coverage caused by buildings and trees, etc.

> than the coverage of the entire network.

The page containing their network architecture is at <
http://www.myrtletown.net/wifi.php> where it shows that it's just boosted 
802.11b/g with a single access point and antenna.

It's actually on a somewhat smaller scale than the stuff I was doing.

Ray

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2007 11:53:40 +0100

Hi Ray,

thanks for the quick response.

> 5.8 GHz, where we actually knew the location of every Target anyway.
When you say "know the location of every Target" then what exactly does 
this mean?
When you run the location determination process then what shape type 
would you get?

> It's actually on a somewhat smaller scale than the stuff I was doing.
Thanks for the pointer. Very interesting stuff.

Ciao
Hannes

---

From: [email-masked]
Date: Mon, 26 Nov 2007 12:23:35 +0000

> this mean?  When you run the location determination process then what
> shape type would you get?

I'm not at all up to speed on this stuff yet, so my terminology is 
probably wrong.

What I meant is that we'd know which customer the IPs belonged to, and 
thence which building we had attached the antenna to.

Ray

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2007 13:35:09 +0100

> thence which building we had attached the antenna to.
In this case you would rather return the civic address instead of a 
geodetic address right?

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 26 Nov 2007 08:38:36 -0500

In many cases, all you care about and can reasonably measure is some  
reasonable bound on where the target can be. For the Myrtletown  
example, this would be a circle with the radius of the maximum extent  
of the yellow area. Trying to discover an exact WiFi coverage area is  
a fool's errand, given that it can change by somebody turning on  
another AP on the same or adjacent channel, or a microwave oven or 2.4  
GHz DECT phone, and thus decreasing the SNR.

In addition to the mobile's radio, the antenna matters a lot. (We're  
currently running some experiments in Manhattan, where you can  
routinely see 20 or 30 residential APs, but can't associate with any  
of them. An omnidirectional antenna helps a lot.)

Also, from my limited experience, coverage seems to vary by time  
("fading") and user location. Somebody sitting next to a window may  
get the yellow coverage area; somebody sitting in the basement may get  
no coverage beyond a few dozen feet away from the AP. I recently tried  
to get WiFi connectivity in JetBlue's temporary JFK terminal and  
signal strength there seemed to have many peaks and valleys, rather  
than some nice convex polygon.

Henning

On Nov 26, 2007, at 4:58 AM, Hannes Tschofenig wrote:

> case the example of Martin's draft and your Wifi coverage example  
> would be relevant http://www.myrtletown.net/pics/myrtletown_wifi_coverage_map_r2.jpg
> Depending on the used location determination technique the result  
> the shape type will be correspondingly. Do you have an experience  
> about the used shapes that are going to be produced? Since the area  
> is pretty small (given the size of typical WLANs in comparison to  
> cell sizes in cellular systems) I wonder whether a likely shape type  
> isn't a circle.
>
> Ciao
> Hannes
>
> BTW:
>
> In PIDF-LO one could express the fact that you are not distributing  
> the location of the Target but rather of the access point by setting
> the entity field to the address of the access point. Additionally,  
> one can put location into the device, person, tuple part of the PIDF- 
> LO document.
>
>
>>> So, can you give us some feedback what the typical coverage area  
>>> for your WLANs was?
>>>
>>
>> However it's worth noting that WLAN coverage tends not to be  
>> completely binary either since it depends on the sensitivity of the  
>> individual radio receivers and the gain on the client antenna.
>>
>> You can see some examples from a Google Images search for "wifi  
>> coverage map".  The one at <
>> http://www.myrtletown.net/pics/myrtletown_wifi_coverage_map_r2.jpg>  
>> is a particularly good example.
>>
>> Ray
>>
>
>
>

---

From: "Tschofenig, Hannes (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 26 Nov 2007 14:44:05 +0100

Hi Henning, 

This is something I wanted to figure out. I was wondering whether we should get rid of the RFC 3825 'resolution' and the draft-thomson-geopriv-3825bis-01 'uncertainty' mechanisms altogether (or to at least replace it with something reasonably simple).

I would like to better understand what type of location shapes are produced by location determination techniques for WLANs. I don't think we are looking for standardizing a mechanism that allows me to distribute the coverage area of an AP. 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: ext Henning Schulzrinne [mailto:[email-masked]] 
> Gesendet: Montag, 26. November 2007 14:39
> An: Hannes Tschofenig
> Cc: GEOPRIV
> Betreff: Re: [Geopriv] draft-thomson-geopriv-3825bis-01.txt
> 
> > would be relevant

---

From: John Schnizlein <[email-masked]>
Date: Mon, 26 Nov 2007 08:54:22 -0500

If you can find an indicator of the accuracy of the location point  
that is simpler than the number of significant digits in the value,  
which is within a constant of log(base2, uncertainty), please propose  
it.  For economy and power of expression, we found none when RFC 3825  
went through extensive review.  Nobody found one then.

John

On Nov 26, 2007, at 8:44 AM, Tschofenig, Hannes (NSN - DE/Munich) wrote:

> This is something I wanted to figure out. I was wondering whether  
> we should get rid of the RFC 3825 'resolution' and the draft- 
> thomson-geopriv-3825bis-01 'uncertainty' mechanisms altogether (or  
> to at least replace it with something reasonably simple).

---

From: "Tschofenig, Hannes (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 26 Nov 2007 15:51:25 +0100

Thanks for the challenge. 

I will think hard and I am also going to chat with WLAN location determination experts. 

Ciao
Hannes

> Von: ext John Schnizlein [mailto:[email-masked]] 
> Gesendet: Montag, 26. November 2007 14:54
> An: Tschofenig, Hannes (NSN - DE/Munich)
> Cc: ext Henning Schulzrinne; Hannes Tschofenig; GEOPRIV
> Betreff: Re: AW: [Geopriv] draft-thomson-geopriv-3825bis-01.txt
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 26 Nov 2007 09:52:08 -0500

In terms of WiFi, there are really two very different scenarios:

- Various multi-AP location determination techniques that use SNR  
mappings (and other techniques) to locate users, with multiple  
commercial implementations such as Ekahau or, for outdoor usage,  
Skyhook. This typically is not something that a LIS can announce, as  
it requires the mobile to measure SNR data from multiple sources (or  
the infrastructure to observe the STA via multiple APs.) These  
techniques typically require fairly careful measurements and  
surveying, and need to be redone periodically, e.g., when furniture is  
moved.

There, you probably get some version of a region, with indoor room- 
level precision. Given that walls cause distinct changes in RF  
patterns, the best you probably can do is provide a room indication.  
Since the indication is likely to be civic (room numbers or maybe  
"hallway, 5th floor") to be most useful and easily computed, I don't  
think you want any geo indication for coverage or uncertainty.

For truly mobile users walking in hallways or across a campus, things  
get tricky, since the elevation of the device matters - a device  
carried on a belt will see a different RF pattern than one pressed to  
the walker's ear. Even which way a user faces changes the observed SNR  
significantly. (We have done some local measurements as part of a  
student project.)

- Single-AP coverage regions, with all the problems mentioned. Again,  
a simple shape seems realistic - and it doesn't really matter whether  
that's a circle or some polygon, since the outlines of that shape are  
going to be very approximate in any event. Pretending that we can  
realistically compute a shape that has nice, precise properties such  
as "with 90% probability, the user is going to be on one side of that  
boundary" is just make-belief.

For outdoor, mobile usage, GPS will dominate, simply because it's  
cheap, relatively precise and needed for navigation. After all, you  
are not going to navigate by WiFi.

As John points out, there's also the question as to whether you take  
the likely location of a user into account, either at the measuring  
site or at the location receiver. Indoors, this means omitting broom  
closets, outdoors that might mean omitting a swamp or lake. I'm not  
sure that this is advisable.

In other words, I think it's a waste of effort to try to worry too  
much as to whether we need circles or some other (implicit) shape.

Henning

On Nov 26, 2007, at 8:44 AM, Tschofenig, Hannes (NSN - DE/Munich) wrote:

> Hi Henning,
>
> This is something I wanted to figure out. I was wondering whether we  
> should get rid of the RFC 3825 'resolution' and the draft-thomson- 
> geopriv-3825bis-01 'uncertainty' mechanisms altogether (or to at  
> least replace it with something reasonably simple).
>
> I would like to better understand what type of location shapes are  
> produced by location determination techniques for WLANs. I don't  
> think we are looking for standardizing a mechanism that allows me to  
> distribute the coverage area of an AP.
>

---

From: "Tschofenig, Hannes (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 26 Nov 2007 16:14:02 +0100

So, what would you do in the context of the RFC 3825 debate? 

Here are the options: 

* Leave RFC 3825 as is 
* Add uncertainty as described in draft-thomson-geopriv-3825bis-01.txt 
* Only describe point locations (for example, by omitting the 'resolution' fields). 
* Add a new shape that is able to describe a circle. 

Ciao
Hannes

> Gesendet: Montag, 26. November 2007 15:52

---

From: John Schnizlein <[email-masked]>
Date: Mon, 26 Nov 2007 11:38:23 -0500

answers embedded in context:

On Nov 26, 2007, at 10:14 AM, Tschofenig, Hannes (NSN - DE/Munich)  

> So, what would you do in the context of the RFC 3825 debate?

Why should there be any debate?

> * Leave RFC 3825 as is

The WG has not even considered, much less come to consensus, that a  
revision is necessary.

> * Add uncertainty as described in draft-thomson-geopriv-3825bis-01.txt

Precisely what difference do you see between the number of  
significant binary digits and an encoding of log2(error) that fits in  
the same field?  There appear to be little change to the actual  
parameters, other than making some fields arbitrarily mandatory and  
optional.

> * Only describe point locations (for example, by omitting the  

RFC 3825 has always been about only point locations, but it does not  
pretend infinite precision.

> * Add a new shape that is able to describe a circle.

Neither RFC 3825 nor draft-thomson-geopriv-3825bis-01.txt describe  
"shapes".

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 26 Nov 2007 12:02:38 -0500

> * Add a new shape that is able to describe a circle.

I think there are two objectives:

- keep it simple, as anything complicated will likely be either  
ignored or mis-configured

- keep it honest, i.e., don't pretend to convey knowledge (such as  
confidence) that generally doesn't exist in real-world deployments

- keep it conservative, i.e., it's better to have a slightly larger  
coverage area rather than having users be actually located outside the  
claimed area.

I don't think circles are significantly better than the spheroid  
rectangles that are essentially in 3825 today.

I suspect that from an implementation and operational perspective, the  
most useful thing would be a table that tells a sys admin what value  
to configure for a typical outdoor AP at various common longitudes and  
latitudes. Simply assuming that an unamplified AP has, say, 300 ft  
coverage is probably as good as anything we can come up with.  
Specialized extremely well-maintained and surveyed systems may be able  
to come up with something more precise, but they can figure out the  
bit math themselves since they have more than an A+ technician on  
staff. It is very unlikely that your local Starbucks or Bryant Park  
(free WiFi in NYC) will pay for such a survey.

If I were to redo 3825, I would have suggested a simple circle  
diameter, maybe rounded to the nearest power of 2 meters, as that's  
easy to understand, but that's water under the bridge.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2007 20:38:15 +0100

Hi John,

I would like to respond to your mail.

John Schnizlein wrote:
> On Nov 26, 2007, at 10:14 AM, Tschofenig, Hannes (NSN - DE/Munich) wrote:
>
:-)

We have the debate already for more than a year, or so.

> The WG has not even considered, much less come to consensus, that a 
Lack of decision making in the group does not mean that there aren't 
problems.

> Precisely what difference do you see between the number of significant 
> binary digits and an encoding of log2(error) that fits in the same 
> field?  There appear to be little change to the actual parameters, 
> other than making some fields arbitrarily mandatory and optional.

I might understand it better if RFC 3825 illustrates an example similar 
to the one in Section 3 of 
http://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-3825bis-01.txt

Is the example in Appendix B of 
http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-05 correct?

> pretend infinite precision.

I meant  something like:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Code 123    |      16       |R R R R R R|     Latitude      +
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Latitude (cont'd)              |R R R R R  |   +
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Longitude                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   AT  |R R R R R R|                Altitude                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Alt (cont'd) |     Datum     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> Neither RFC 3825 nor draft-thomson-geopriv-3825bis-01.txt describe 
If the fields for uncertainty are used then the result is a polygon, as 
illustrated in the example.
Quoting from the draft:

"

If all fields are included along with uncertainty, the shape
   described is a rectangular prism.

"

Am I the only one reading the GEOPRIV documents?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2007 21:00:45 +0100

Hi Henning,

> coverage area rather than having users be actually located outside the 
Good design goals.

> (free WiFi in NYC) will pay for such a survey.
Sounds good to me.

> easy to understand, but that's water under the bridge.
That's much simpler to understand.

Given that RFC 3825 is already out there for some time I wonder whether 
there is some deployment and implementation experience. The format was 
re-used by the IEEE and the document is being referenced by a couple of 
other SDOs. Why don't we solicit feedback?

Ciao
Hannes

---

From: John Schnizlein <[email-masked]>
Date: Mon, 26 Nov 2007 17:11:13 -0500

I tried to answer the question you posed, and provided response on  
each option.  It would have been nice if you answered my questions.

> We have the debate already for more than a year, or so.

For what reason?  Actually, a look at the archives does not show a  
year of debate on the individual draft: 3825bis.

>>> Here are the options:
>>>
>>> * Leave RFC 3825 as is
>>
>> The WG has not even considered, much less come to consensus, that  
>> a revision is necessary.
>>
> Lack of decision making in the group does not mean that there  
> aren't problems.

That may be true, but don't you think that actually understanding  
what problems are claimed should come before proposals to replace/ 
obsolete an RFC produced by the WG?

>> significant binary digits and an encoding of log2(error) that fits  
>> in the same field?  There appear to be little change to the actual  
>> parameters, other than making some fields arbitrarily mandatory  
>> and optional.
>
> I might understand it better if RFC 3825 illustrates an example  
> similar to the one in Section 3 of http://tools.ietf.org/wg/geopriv/ 
> draft-thomson-geopriv-3825bis-01.txt

RFC 3825 is done.  I would hope that the WG would not consider  
replacing a standards-track RFC to add examples.  Misinterpretations  
of RFC 3825 are clarified in draft-ietf-geopriv-binary-lci-00, which  
you can tell from its file name was approved as a WG document.  You  
must know that examples are not normative.  And reasoning by example  
is an invitation to error.

Please answer my question: what difference does it make if the  
precision of a location value is encoded as log2(error) rather than  
the number of significant binary digits (in the 34-bit field)?

> Is the example in Appendix B of http://tools.ietf.org/html/draft- 
> ietf-geopriv-pdif-lo-profile-05 correct?

No, but why are you even asking about version -05 when the current  
version (which has eliminated this error) is -10?

>> RFC 3825 has always been about only point locations, but it does  
>> not pretend infinite precision.
>
> I meant  something like:
>
>     0                   1                   2                   3

While I do not understand what you  mean by replacing the resolution  
fields with 'R's, the premise of that your "option" to "only describe  
point locations" would imply any change from RFC 3825 is false.   
Eliminating the resolution field would not change the specification  
from other-than-a-point because the specification was always for a  
point.

> If the fields for uncertainty are used then the result is a  
> polygon, as illustrated in the example.
> Quoting from the draft:
> "

While that text refers to a shape, the fields in the protocol object  
proposed specify the same number (6) bits of information as in RFC  
3825, although the log2(error) is bits of uncertainty rather than  
bits of (certainty) resolution.  Since the field is 34 bits wide, it  
matters little if r or 34-r is specified.  However, it is not a good  
idea to change from one to the other after the specification is  
published.

> Am I the only one reading the GEOPRIV documents?

Setting aside the implication that others are not reading, because  
you would certainly not be making an ad hominem attacks here, it  
seems that you are reading obsolete documents or reading implications  
not in the protocol specification.

John

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 00:05:30 +0100

Hi John,

thanks for your quick response. Please find my comments below:

> each option.  It would have been nice if you answered my questions.
Sorry. Trying harder this time.

> year of debate on the individual draft: 3825bis.
That's true. The discussions did not focus on a specific document and 
could have been more structured and constructive.

> That may be true, but don't you think that actually understanding what 
> problems are claimed should come before proposals to replace/obsolete 
> an RFC produced by the WG?
I fully agree.

>> similar to the one in Section 3 of 
I understand that this is not a reason for replacing an RFC to add 
examples.

> the number of significant binary digits (in the 34-bit field)?
That's not my worry. I don't care about these details. I am worried 
about the larger picture, namely the semantic of the entire bit 
shuffling. What is the outcome of it? Is it useful in the first place? 

> version (which has eliminated this error) is -10?
Version -10 does not describe these type of examples anymore. Hence, I 
referred to a version that had them included.

>> from other-than-a-point because the specification was always for a 
I understand that this is only a profiling step. Nevertheless, I wonder 
whether a this way of describing the location of the Target captures 80% 
of the cases.

>> If the fields for uncertainty are used then the result is a polygon, 
>> as illustrated in the example.
>> Quoting from the draft:
>> "
> 3825, although the log2(error) is bits of uncertainty rather than bits 
> of (certainty) resolution.  Since the field is 34 bits wide, it 
It is true that the amount of information that is being exchanged has 
not changed. That's fine.

I am more interested in the step that happens before and afterwards. 
Hence, I particularly commented the example section of the document. I 
think that's the place we should be looking at.

Btw, Section 2.1 of RFC 3825 says: "The examples in the appendix 
illustrate that a smaller value in the resolution field increases the 
area within which the device is located."

> Setting aside the implication that others are not reading, because you 
> would certainly not be making an ad hominem attacks here, it seems 
> that you are reading obsolete documents or reading implications not in 
> the protocol specification.
>
Sorry for my harsh statement.

Ciao
Hannes

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 26 Nov 2007 18:05:19 -0600

I think that this discussion is in danger of devolving into bickering (again), despite Hannes' best efforts to keep things civil.  Focus on the goal.

We can all agree on one point: RFC 3825 has a problem.  We even seem to agree that the problem needs a document to clarify it.  I also think that we have consensus that a normative update is required.

My opinion is that we don't get the luxury of a do-over.  People are already using the format, either oblivious to its limitations or content to leave us to fix its problems.  The progress we've demonstrated so far must be dreadfully reassuring.

If a do-over were possible, it would be with a DHCP option code other than 123 and, yes, it would be better.  That wouldn’t help those that have already published standards based on RFC 3825.

So we are stuck with what is there.

My proposal, as I documented in draft-thomson-geopriv-3825bis, is that the meaning of the "resolution" fields is changed.  The change is the minimum necessary to ensure that they are usable, while maintaining a veneer of compatibility with any existing implementations -- the size of the region of uncertainty is the same, but moved slightly.

At risk of attracting an inimical response, my opinion is that draft-ietf-binary-lci is poorly written and inadequate.  It equivocates over terminology that should be clear and precise.  The focus on C code is unnecessary and doesn't serve to clarify; it only demonstrates an inability to convey the message.  I wouldn't have written the -bis proposal if I thought that it could be fixed.

Cheers,
Martin

p.s. All THIS came from a comment about the example?  After seeing that comment, I was thinking "if that's all that comes out of this, then I don't have much to worry about..."

p.p.s.  To answer Hannes' original question on why the Sydney Opera House was chosen... I needed a public location and polygons are much easier to convert to the 3825 form.  A circle needs to be converted to ECEF before you can work out a bounding box; I wanted to avoid that complexity.
------------------------------------------------------------------------------------------------
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: Mon, 26 Nov 2007 18:35:14 -0600

At 06:05 PM 11/26/2007, Thomson, Martin wrote:
>Content-class: urn:content-classes:message
>Content-Type: text/plain;
>         charset="UTF-8"
>
>I think that this discussion is in danger of 
>devolving into bickering (again), despite 
>Hannes' best efforts to keep things civil.  Focus on the goal.
>
>We can all agree on one point: RFC 3825 has a problem.

no everyone agrees with this

>We even seem to agree that the problem needs a document to clarify it.

that's not how the binary doc came into being.  A 
few said, said again, said again and then 
screamed they didn't understand 3825.  The chairs 
asked a co-author of 3825 if it would be a 
problem if a new doc were written to have a 
common reference for the discussion. That doc was 
written. That doc wasn't written because everyone 
thought there was a problem with 3825, it was 
written because a small few didn't like the 
resolution fields, and wanted cellular 
uncertainty and confidence values instead.

>I also think that we have consensus that a normative update is required.

no no no no

see above

the WG agreed the additional doc couldn't hurt to 
have, and was expedited to become a WG item after its first presentation.

>My opinion is that we don't get the luxury of a 
>do-over.  People are already using the format, 
>either oblivious to its limitations or content 
>to leave us to fix its problems.  The progress 
>we've demonstrated so far must be dreadfully reassuring.
>
>If a do-over were possible, it would be with a 
>DHCP option code other than 123 and, yes, it 
>would be better.  That wouldn’t help those 
>that have already published standards based on RFC 3825.
>
>My proposal, as I documented in 
>draft-thomson-geopriv-3825bis, is that the 
>meaning of the "resolution" fields is 
>changed.  The change is the minimum necessary to 
>ensure that they are usable, while maintaining a 
>veneer of compatibility with any existing 
>implementations -- the size of the region of 
>uncertainty is the same, but moved slightly.
>
>At risk of attracting an inimical response, my 
>opinion is that draft-ietf-binary-lci is poorly 
>written and inadequate.  It equivocates over 
>terminology that should be clear and 
>precise.  The focus on C code is unnecessary and 
>doesn't serve to clarify; it only demonstrates 
>an inability to convey the message.  I wouldn't 
>have written the -bis proposal if I thought that it could be fixed.
>
>Cheers,
>Martin
>
>p.s. All THIS came from a comment about the 
>example?  After seeing that comment, I was 
>thinking "if that's all that comes out of this, 
>then I don't have much to worry about..."
>
>p.p.s.  To answer Hannes' original question on 
>why the Sydney Opera House was chosen... I 
>needed a public location and polygons are much 
>easier to convert to the 3825 form.  A circle 
>needs to be converted to ECEF before you can 
>work out a bounding box; I wanted to avoid that complexity.

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 26 Nov 2007 19:00:10 -0600

James,

Expressing an area of uncertainty is a fundamental location concept not a cellular one. I really don't understand why you believe it to be a cellular concept. You yourself have stated on more than one occasion that 3825 represents a polygonal area, which is simply the area of uncertainty.

The following statement from John S back in September also highlights the misunderstanding of what uncertainty is.

>> The range of the radio in the access point, or the accuracy of 
>> triangulation (or other means) would determine the resolution of the 
>> LCI provided.

This is NOT POSSIBLE if RFC-3825 is only a point, if you try, you are using significant digits to express uncertainty which has been shown more than once to be a bad idea.

Also, please check the minutes for IETF-67, I think you will see that they reflect consensus in the WG was to accept a document that corrected the problem in a standards track way. 
http://tools.ietf.org/wg/geopriv/minutes?item=minutes67.html
This sentiment was similarly reflected to the ECRIT list by Andy Newton in September.

Cheers
James

> >would be better.  That wouldnâ€™t help those

Subject: Re: [Ecrit] Phonebcp comments
From: "Andrew Newton" <[email-masked]>
To: "John Schnizlein" <[email-masked]>
Cc: "Stark, Barbara" <[email-masked]>, "ECRIT" <[email-masked]>
Date: Thu, 20 Sep 2007 10:16:54 -0600
List-Id: ecrit.ietf.org

On Sep 19, 2007, at 5:23 PM, John Schnizlein wrote:

> That is the subject of draft-ietf-geopriv-binary-lci-00, which  
> expired July 1 after the (previous) GeoPriv chair let it languish  
> after the WG adopted it as a WG item.

This is a bit incorrect.

Despite the fact that the binary-lci-00 draft was a very useful  
document, the working group did not adopt it.  What the working group  
consented to adopt was a draft that updated 3825.  The previous chair  
simply held to that wish, and did not allow the submittal of binary- 
lci until it was revised to be an update of 3825.  Though they were  
asked to do so by the previous chair, the authors of binary-lci never  
revised the document as needed.

> There is a misinterpretation about the resolution parameter in RFC  
> 3825 that this draft was written to clarify, but the dispute of the  
> meaning of resolution has not gone away.

The working group did reach a consensus (though it was very rough) on  
this matter.

-andy

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 10:49:15 +0100

I guess the recent exchange shows quite well where some of the problems 
with this work are.
It might be fair to say that the authors of the two documents are not 
going to come to a conclusion anytime soon.

Ciao
Hannes

James M. Polk wrote:
>> I think that this discussion is in danger of devolving into bickering 
>> (again), despite Hannes' best efforts to keep things civil. Focus on 
>> the goal.
>>
> that's not how the binary doc came into being. A few said, said again, 
> said again and then screamed they didn't understand 3825. The chairs 
> asked a co-author of 3825 if it would be a problem if a new doc were 
> written to have a common reference for the discussion. That doc was 
> written. That doc wasn't written because everyone thought there was a 
> problem with 3825, it was written because a small few didn't like the 
> resolution fields, and wanted cellular uncertainty and confidence 
> values instead.
>
> the WG agreed the additional doc couldn't hurt to have, and was 
> expedited to become a WG item after its first presentation.
>
>
>> My opinion is that we don't get the luxury of a do-over. People are 
>> already using the format, either oblivious to its limitations or 
>> content to leave us to fix its problems. The progress we've 
>> demonstrated so far must be dreadfully reassuring.
>>
>> If a do-over were possible, it would be with a DHCP option code other 
>> than 123 and, yes, it would be better. That wouldn’t help those 
>> My proposal, as I documented in draft-thomson-geopriv-3825bis, is 
>> that the meaning of the "resolution" fields is changed. The change is 
>> the minimum necessary to ensure that they are usable, while 
>> maintaining a veneer of compatibility with any existing 
>> implementations -- the size of the region of uncertainty is the same, 
>> but moved slightly.
>>
>> At risk of attracting an inimical response, my opinion is that 
>> draft-ietf-binary-lci is poorly written and inadequate. It 
>> equivocates over terminology that should be clear and precise. The 
>> focus on C code is unnecessary and doesn't serve to clarify; it only 
>> demonstrates an inability to convey the message. I wouldn't have 
>> written the -bis proposal if I thought that it could be fixed.
>>
>> Cheers,
>> Martin
>>
>> p.s. All THIS came from a comment about the example? After seeing 
>> that comment, I was thinking "if that's all that comes out of this, 
>> p.p.s. To answer Hannes' original question on why the Sydney Opera 
>> House was chosen... I needed a public location and polygons are much 
>> easier to convert to the 3825 form. A circle needs to be converted to 
>> ECEF before you can work out a bounding box; I wanted to avoid that 
>> complexity.