[Geopriv] Document Action: 'Requirements for a Location-by-Reference Mechanism' to Informational RFC

The IESG has approved the following document:

- 'Requirements for a Location-by-Reference Mechanism '
<draft-ietf-geopriv-lbyr-requirements-09.txt> as an Informational RFC

This document is the product of the Geographic Location/Privacy Working Group.

The IESG contact persons are Cullen Jennings and Robert Sparks.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lbyr-requirements-09.txt

Technical Summary:

This document defines terminology and describes requirements for the
use of Location-by-Reference, a means of indirectly providing location
information within the GEOPRIV architecture defined in RFC 3693. The
document describes the use of location URIs as a means of providing
this indirection. The document provides requirements that pay
particular attention to privacy and security.

Working Group Summary:

This document represents the strong consensus of the GEOPRIV working
group.

Document Quality:

This requirements document is the product of design team work in the
GEOPRIV working group. It has been thoroughly reviewed by GEOPRIV
participants.

Personnel

The document shepherd for this document is Alissa Cooper.

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] I-D Action:draft-ietf-geopriv-prefix-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

Title : Prefix elements for Road and House Numbers in PIDF-LO
Author(s) : B. Rosen
Filename : draft-ietf-geopriv-prefix-00.txt
Pages : 4
Date : 2010-01-20

RFC4119 updated by RFC5139 defines suffixes for street names and
house numbers, but does not define prefixes. Both occur regularly in
addresses and CAtypes are needed for them. This memo defines STP
Street Prefix and HNP house number prefix CAtypes.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 23, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-prefix-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Re: [Geopriv] [geopriv] #23: Good Security of DHCP

At 10:38 PM 1/19/2010, Thomson, Martin wrote:
> > >Which begs the question of what additional potential security risks
> > >the sentence is advocating that we consider.
> >
> > this might be opening up pandora's box here, so let's keep this
> > between just you and me...
> >
>
>Rather than open that box, why not close it and remove this entirely:
>
> When implementing a DHCP server that will serve clients across an
> uncontrolled network, one should consider the potential security
> risks.
>
>There's sufficient specific advice already. This doesn't really add
>anything that can be acted upon directly; it's sort of vague.
>
> > ... you're thinking of L2 hop-by-hop,
> > or between the endhost and the first L3 node...
>
>I don't see a great deal of value in belabouring the point, unless
>we're aware of a specific attack. We've already highlighted the
>disclosure problem - if the network uses hop-by-hop confidentiality,
>then I'd hope that it would be clear that any hops can get the data.

I agree with each point made here

James

>--Martin

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #23: Good Security of DHCP

> >Which begs the question of what additional potential security risks
> >the sentence is advocating that we consider.
>
> this might be opening up pandora's box here, so let's keep this
> between just you and me...
>

Rather than open that box, why not close it and remove this entirely:

When implementing a DHCP server that will serve clients across an
uncontrolled network, one should consider the potential security
risks.

There's sufficient specific advice already. This doesn't really add anything that can be acted upon directly; it's sort of vague.

> ... you're thinking of L2 hop-by-hop,
> or between the endhost and the first L3 node...

I don't see a great deal of value in belabouring the point, unless we're aware of a specific attack. We've already highlighted the disclosure problem - if the network uses hop-by-hop confidentiality, then I'd hope that it would be clear that any hops can get the data.

--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #23: Good Security of DHCP

At 08:47 PM 1/19/2010, Bernard Aboba wrote:
> > wrt the above "when":
> >
> > s/when/after
> >
> > IMO this makes the statement more direct and to the point.
>
>Yes, it's more clear.
>
> > >When implementing a DHCP server that will serve
> > >clients across an uncontrolled network, one
> > >should consider the potential security risks."
> >
> > I assume that for controlled networks -- this doesn't apply?
>
>I suppose that depends on what "uncontrolled" means. My (perhaps
>incorrect) assumption was that "uncontrolled" meant a network that
>did not employ security mechanisms such as link layer security or
>even packet filtering. Perhaps another term might be appropriate?

I was thinking more along the lines of SMB/enterprise vs. SP
environments, where one is generally (significantly) more often
controlled than the other (but not in every case).

>The security risks discussed in the section include disclosure and
>packet modification.
>
>The section advocates use of DHCP authentication to address packet
>modification threats.
>
>In -06, I inserted a sentence to address the disclosure aspect:
>"Link layer confidentiality may also be employed to reduce the risk
>of location disclosure."
>
>Which begs the question of what additional potential security risks
>the sentence is advocating that we consider.

this might be opening up pandora's box here, so let's keep this
between just you and me...

;-)

is the 'link layer confidentiality' you're thinking of L2 hop-by-hop,
or between the endhost and the first L3 node? One or two multipart
sentence(s) could address both cases, if you want to expound on this point.

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #23: Good Security of DHCP

> wrt the above "when":
>
> s/when/after
>
> IMO this makes the statement more direct and to the point.

Yes, it's more clear.

> >When implementing a DHCP server that will serve
> >clients across an uncontrolled network, one
> >should consider the potential security risks."
>
> I assume that for controlled networks -- this doesn't apply?

I suppose that depends on what "uncontrolled" means.   My (perhaps incorrect) assumption was that "uncontrolled" meant a network that did not employ security mechanisms such as link layer security or even packet filtering.  Perhaps another term might be appropriate?

The security risks discussed in the section include disclosure and packet modification. 

The section advocates use of DHCP authentication to address packet modification threats.

In -06, I inserted a sentence to address the disclosure aspect:
"Link layer confidentiality may also be employed to reduce the risk of location disclosure."

Which begs the question of what additional potential security risks the sentence is advocating that we consider.

Re: [Geopriv] [geopriv] #23: Good Security of DHCP

At 04:42 PM 1/19/2010, geopriv issue tracker wrote:
>#23: Good Security of DHCP
>---------------------------------------+------------------------------------
>Reporter: Hannes.Tschofenig@… |
>Owner: Hannes.Tsschofenig@… Type:
>enhancement | Status:
>closed Priority: major
> | Milestone:
>draft-ietf-geopriv-3825bis
>Component: rfc3825bis |
>Version: Severity:
>Active WG
>Document | Resolution: fixed
> Keywords:
> |
>---------------------------------------+------------------------------------
>Changes (by bernard_aboba@…): * stattus: new
>=> closed * resolution: => fixed *
>severity: - => Active WG Document Comment: The
>current text of the security considerations
>section addresses potential disclosure risks as
>well as modification attacks. I will add some
>advice on use of link level encryption in -06.
>"Where critical decisions might be based on the
>value of this GeoConf option, DHCP
>authentication as defined in "Authentication for
>DHCP Messages" [RFC3118] and "Dynamic Host
>Configuration Protocol for IPv6 (DHCPv6)"
>[RFC3315] SHOULD be used to protect the
>integrity of the DHCP options. Since there is no
>privacy protection for DHCP messages, an
>eavesdropper who can monitor the link between
>the DHCP server and requesting client can
>discover this LCI. To minimize the unintended
>exposure of location information, the LCI option
>SHOULD be returned by DHCP servers only when the
>DHCP client has included this option in its
>'parameter request list' (section 3.5 [RFC2131]).

wrt the above "when":

s/when/after

IMO this makes the statement more direct and to the point.

>When implementing a DHCP server that will serve
>clients across an uncontrolled network, one
>should consider the potential security risks."

I assume that for controlled networks -- this doesn't apply?

James

> -- Ticket URL:
> <http://wiki.tools.ietf.org/wg/geopriv/trac/ticket/23#comment:3>
> geopriv <http://tools.ietf.org/geopriv/>
> _______________________________________________
> Geopriv mailing list Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] I-D Action:draft-ietf-geopriv-rfc3825bis-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

Title : Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information
Author(s) : J. Polk, et al.
Filename : draft-ietf-geopriv-rfc3825bis-06.txt
Pages : 27
Date : 2010-01-19

This document specifies Dynamic Host Configuration Protocol Options
(both DHCPv4 and DHCPv6) for the coordinate-based geographic location
of the client. The Location Configuration Information (LCI) includes
latitude, longitude, and altitude, with resolution or uncertainty
indicators for each. Separate parameters indicate the reference
datum for each of these values.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-rfc3825bis-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Re: [Geopriv] [geopriv] #23: Good Security of DHCP

#23: Good Security of DHCP
---------------------------------------+------------------------------------
Reporter: Hannes.Tschofenig@… | Owner: Hannes.Tschofenig@…
Type: enhancement | Status: closed
Priority: major | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version:
Severity: Active WG Document | Resolution: fixed
Keywords: |
---------------------------------------+------------------------------------
Changes (by bernard_aboba@…):

* status: new => closed
* resolution: => fixed
* severity: - => Active WG Document

Comment:

The current text of the security considerations section addresses
potential disclosure risks as well as modification attacks. I will add
some advice on use of link level encryption in -06.

"Where critical decisions might be based on the value of this GeoConf
option, DHCP authentication as defined in "Authentication for DHCP
Messages" [RFC3118] and "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)" [RFC3315] SHOULD be used to protect the integrity of the DHCP
options.

Since there is no privacy protection for DHCP messages, an
eavesdropper who can monitor the link between the DHCP server and
requesting client can discover this LCI.

To minimize the unintended exposure of location information, the LCI
option SHOULD be returned by DHCP servers only when the DHCP client
has included this option in its 'parameter request list' (section 3.5
[RFC2131]).

When implementing a DHCP server that will serve clients across an
uncontrolled network, one should consider the potential security
risks."

--
Ticket URL: <http://wiki.tools.ietf.org/wg/geopriv/trac/ticket/23#comment:3>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Issue #3: GML Mapping

For those who are unfamiliar:
<http://www.uncertml.org/>

On Jan 19, 2010, at 12:00 PM, Carl Reed wrote:

> Since the discussion involved how to express uncertainty, I would
> encourage the group to at least consider the information model used
> in UnCertML. Understanding that 3825 is a binary encoding, use of a
> common info model for uncertainty that could be expressed in binary,
> as XML, as whatever would be quite nice - and easier for the
> implementation community. UnCertML is (from their website):
>
> UncertML is a conceptual model, with accompanying XML schemata, that
> may be used to quantify and exchange complex uncertainties in data.
> The interoperable model can be used to describe uncertainty in a
> variety of ways including:
> a.. Realisations or sampled data
> b.. Statistics including means, variances, standard deviations and
> quantiles
> c.. Probability distributions including both marginal and joint
> distributions and mixture models
> The OGC community is working closely with the statistical gurus who
> represent the UnCertML community. Much joint work in the information
> fusion domain, where expressing uncertainty using a common model is
> extremely important.
>
> Cheers
>
> Carl
>
> ----- Original Message ----- From: "Winterbottom, James" <James.Winterbottom@andrew.com
> >
> To: "James M. Polk" <jmpolk@cisco.com>; "Thomson, Martin" <Martin.Thomson@andrew.com
> >; "Bernard Aboba" <bernard_aboba@hotmail.com>; <geopriv@ietf.org>
> Sent: Monday, January 18, 2010 12:39 PM
> Subject: Re: [Geopriv] Issue #3: GML Mapping
>
>
>> Martin I am sure will add to this but this is my take on what the
>> issues with your statements below are.
>>
>> Firstly, you are trying to represent uncertainty using significant
>> figures, and a number of very credible references have been cited
>> indicating that this is a very bad idea.
>>
>> Secondly, when you turn this into XML, there is no way to express
>> the difference between the two numbers you describe below. When the
>> XML is interpreted, they are both represented by exactly the same
>> IEEE double. This means that your intent of representing
>> uncertainty through significant figures is completely lost and you
>> are misrepresenting the location, and indeed the area of
>> uncertainty around it.
>>
>> To my mind, these are the main issues for us BISing this document
>> in the first place.
>>
>> Cheers
>> James
>>
>>
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org]
>>> On Behalf
>>> Of James M. Polk
>>> Sent: Tuesday, 19 January 2010 6:02 AM
>>> To: Thomson, Martin; Bernard Aboba; geopriv@ietf.org
>>> Subject: Re: [Geopriv] Issue #3: GML Mapping
>>>
>>> At 05:17 PM 1/17/2010, Thomson, Martin wrote:
>>> > > [BA] Any recommendations on how we should
>>> > resolve the remaining aspects of Issue #3?
>>> >
>>> >I still don’t really know what resolution means.
>>>
>>> well... that's silly (so I'm expecting this to
>>> actually be a trap question), as several folks
>>> have explained this to you (and others) over the years.
>>>
>>> To fall into your trap, let me explain again
>>> (even though John S. explains it best):
>>>
>>> The resolution field indicates how many bits to
>>> be considered valid (left to right) when looking
>>> at a Lat, Long or Alt field value.
>>>
>>> The analogy is a subnet mask, but I know most
>>> here don't understand that -- where the mask
>>> doesn't indicate the length of the host part but
>>> of what shouldn't be viewed at all.
>>>
>>> This was never really meant to indicate less than
>>> all integers within a Lat/Long/Alt value, but it
>>> could. It is meant to indicate the number of
>>> decimals to account for (i.e., is the number X.1
>>> or X.100000 -- which are two different numbers entirely).
>>>
>>> put another way, albeit loosely defined -
>>> resolution is a left to right length field within
>>> the binary to indicate how many bits to convert
>>> from binary to decimal for a particular
>>> Lat/Long/Alt value. All bit values to the right
>>> of the resolution indication are to be ignored.
>>>
>>> Marc or John S can correct me.
>>>
>>> James
>>>
>>> >That lies at the heart of the problem. Hence my
>>> >preference to defer to James P. (or one of his colleagues) at
>>> this >point.
>>> >
>>> >As far as I can extract from the history of the
>>> >issue, there are two possible interpretations, and maybe more:
>>> >
>>> > (1) If resolution is roughly analogous to
>>> > uncertainty, then I don’t see an easy way to
>>> > provide a GML->3825 mapping. Following the
>>> > same process that I used for the uncertainty
>>> > mappings just leads to weird results (the 32 degree crossover
>>> problem).
>>> >
>>> > The 3825->GML mapping is easy enough for this
>>> > case, and it could be based on the old
>>> > examples, but there are a few minor
>>> > mathematical errors (for instance, the very
>>> > first point states that res2 is -1 to 128,
>>> > which is inconsistent with res5 at -64 to -80;
>>> > I think that res2 should be 0 to -128).
>>> >
>>> > (2) If resolution is simply a way of encoding
>>> > significant digits (i.e., 3 bits =~ 1 decimal
>>> > digit; 10 bits =~ 3 decimal digits), then the
>>> > mapping is simply a GML point<->3825 mapping,
>>> > but the examples would have to be entirely replaced.
>>> >
>>> >I don't have any particular preference.
>>> >
>>> >--Martin
>>> >
>>> >
>>> >_______________________________________________
>>> >Geopriv mailing list Geopriv@ietf.org
>>> >https://www.ietf.org/mailman/listinfo/geopriv
>>>
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Issue #3: GML Mapping

Since the discussion involved how to express uncertainty, I would encourage
the group to at least consider the information model used in UnCertML.
Understanding that 3825 is a binary encoding, use of a common info model for
uncertainty that could be expressed in binary, as XML, as whatever would be
quite nice - and easier for the implementation community. UnCertML is (from
their website):

UncertML is a conceptual model, with accompanying XML schemata, that may be
used to quantify and exchange complex uncertainties in data. The
interoperable model can be used to describe uncertainty in a variety of ways
including:
a.. Realisations or sampled data
b.. Statistics including means, variances, standard deviations and
quantiles
c.. Probability distributions including both marginal and joint
distributions and mixture models
The OGC community is working closely with the statistical gurus who
represent the UnCertML community. Much joint work in the information fusion
domain, where expressing uncertainty using a common model is extremely
important.

Cheers

Carl

----- Original Message -----
From: "Winterbottom, James" <James.Winterbottom@andrew.com>
To: "James M. Polk" <jmpolk@cisco.com>; "Thomson, Martin"
<Martin.Thomson@andrew.com>; "Bernard Aboba" <bernard_aboba@hotmail.com>;
<geopriv@ietf.org>
Sent: Monday, January 18, 2010 12:39 PM
Subject: Re: [Geopriv] Issue #3: GML Mapping

> Martin I am sure will add to this but this is my take on what the issues
> with your statements below are.
>
> Firstly, you are trying to represent uncertainty using significant
> figures, and a number of very credible references have been cited
> indicating that this is a very bad idea.
>
> Secondly, when you turn this into XML, there is no way to express the
> difference between the two numbers you describe below. When the XML is
> interpreted, they are both represented by exactly the same IEEE double.
> This means that your intent of representing uncertainty through
> significant figures is completely lost and you are misrepresenting the
> location, and indeed the area of uncertainty around it.
>
> To my mind, these are the main issues for us BISing this document in the
> first place.
>
> Cheers
> James
>
>
>
>
>
>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> Behalf
>> Of James M. Polk
>> Sent: Tuesday, 19 January 2010 6:02 AM
>> To: Thomson, Martin; Bernard Aboba; geopriv@ietf.org
>> Subject: Re: [Geopriv] Issue #3: GML Mapping
>>
>> At 05:17 PM 1/17/2010, Thomson, Martin wrote:
>> > > [BA] Any recommendations on how we should
>> > resolve the remaining aspects of Issue #3?
>> >
>> >I still don’t really know what resolution means.
>>
>> well... that's silly (so I'm expecting this to
>> actually be a trap question), as several folks
>> have explained this to you (and others) over the years.
>>
>> To fall into your trap, let me explain again
>> (even though John S. explains it best):
>>
>> The resolution field indicates how many bits to
>> be considered valid (left to right) when looking
>> at a Lat, Long or Alt field value.
>>
>> The analogy is a subnet mask, but I know most
>> here don't understand that -- where the mask
>> doesn't indicate the length of the host part but
>> of what shouldn't be viewed at all.
>>
>> This was never really meant to indicate less than
>> all integers within a Lat/Long/Alt value, but it
>> could. It is meant to indicate the number of
>> decimals to account for (i.e., is the number X.1
>> or X.100000 -- which are two different numbers entirely).
>>
>> put another way, albeit loosely defined -
>> resolution is a left to right length field within
>> the binary to indicate how many bits to convert
>> from binary to decimal for a particular
>> Lat/Long/Alt value. All bit values to the right
>> of the resolution indication are to be ignored.
>>
>> Marc or John S can correct me.
>>
>> James
>>
>> >That lies at the heart of the problem. Hence my
>> >preference to defer to James P. (or one of his colleagues) at this
>> >point.
>> >
>> >As far as I can extract from the history of the
>> >issue, there are two possible interpretations, and maybe more:
>> >
>> > (1) If resolution is roughly analogous to
>> > uncertainty, then I don’t see an easy way to
>> > provide a GML->3825 mapping. Following the
>> > same process that I used for the uncertainty
>> > mappings just leads to weird results (the 32 degree crossover problem).
>> >
>> > The 3825->GML mapping is easy enough for this
>> > case, and it could be based on the old
>> > examples, but there are a few minor
>> > mathematical errors (for instance, the very
>> > first point states that res2 is -1 to 128,
>> > which is inconsistent with res5 at -64 to -80;
>> > I think that res2 should be 0 to -128).
>> >
>> > (2) If resolution is simply a way of encoding
>> > significant digits (i.e., 3 bits =~ 1 decimal
>> > digit; 10 bits =~ 3 decimal digits), then the
>> > mapping is simply a GML point<->3825 mapping,
>> > but the examples would have to be entirely replaced.
>> >
>> >I don't have any particular preference.
>> >
>> >--Martin
>> >
>> >
>> >_______________________________________________
>> >Geopriv mailing list Geopriv@ietf.org
>> >https://www.ietf.org/mailman/listinfo/geopriv
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Issue #3: GML Mapping

Hi James,

I'm not interesting in playing petty games. I understand your explanation; but that's never been the problem. I'm just not certain how the theory reduces to practice.

If you could produce the GML mapping algorithm as Richard suggests, 3825 -> GML, that would clear this all up. That way, me being dense becomes irrelevant.

--Martin

> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> Sent: Tuesday, 19 January 2010 6:02 AM
> To: Thomson, Martin; Bernard Aboba; geopriv@ietf.org
> Subject: Re: [Geopriv] Issue #3: GML Mapping
>
> At 05:17 PM 1/17/2010, Thomson, Martin wrote:
> > > [BA] Any recommendations on how we should
> > resolve the remaining aspects of Issue #3?
> >
> >I still don’t really know what resolution means.
>
> well... that's silly (so I'm expecting this to
> actually be a trap question), as several folks
> have explained this to you (and others) over the years.
>
> To fall into your trap, let me explain again
> (even though John S. explains it best):
>
> The resolution field indicates how many bits to
> be considered valid (left to right) when looking
> at a Lat, Long or Alt field value.
>
> The analogy is a subnet mask, but I know most
> here don't understand that -- where the mask
> doesn't indicate the length of the host part but
> of what shouldn't be viewed at all.
>
> This was never really meant to indicate less than
> all integers within a Lat/Long/Alt value, but it
> could. It is meant to indicate the number of
> decimals to account for (i.e., is the number X.1
> or X.100000 -- which are two different numbers entirely).
>
> put another way, albeit loosely defined -
> resolution is a left to right length field within
> the binary to indicate how many bits to convert
> from binary to decimal for a particular
> Lat/Long/Alt value. All bit values to the right
> of the resolution indication are to be ignored.
>
> Marc or John S can correct me.
>
> James
>
> >That lies at the heart of the problem. Hence my
> >preference to defer to James P. (or one of his colleagues) at this
> point.
> >
> >As far as I can extract from the history of the
> >issue, there are two possible interpretations, and maybe more:
> >
> > (1) If resolution is roughly analogous to
> > uncertainty, then I don’t see an easy way to
> > provide a GML->3825 mapping. Following the
> > same process that I used for the uncertainty
> > mappings just leads to weird results (the 32 degree crossover
> problem).
> >
> > The 3825->GML mapping is easy enough for this
> > case, and it could be based on the old
> > examples, but there are a few minor
> > mathematical errors (for instance, the very
> > first point states that res2 is -1 to 128,
> > which is inconsistent with res5 at -64 to -80;
> > I think that res2 should be 0 to -128).
> >
> > (2) If resolution is simply a way of encoding
> > significant digits (i.e., 3 bits =~ 1 decimal
> > digit; 10 bits =~ 3 decimal digits), then the
> > mapping is simply a GML point<->3825 mapping,
> > but the examples would have to be entirely replaced.
> >
> >I don't have any particular preference.
> >
> >--Martin
> >
> >
> >_______________________________________________
> >Geopriv mailing list Geopriv@ietf.org
> >https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Issue #3: GML Mapping

James W: Re-visiting the utility of the resolution representation is
not germane here. What's needed for the -bis is a clear explanation
of what it means, which I believe James P is trying to provide.

Martin: You're correct that mapping GML->3825 is difficult; the point
of the "uncertainty encoding" is to provide an easier represtation.
But we still need a 3825->GML mapping to give the "representation
encoding" an unambiguous semantic.

James P: Could you turn your description below into an algorithm?
That is given a coordinate and a resolution value, how do you
determine the minimum and maximum values for that coordinate?
Repeating that algorithm for each coordinate should provide a mapping
between 3825 and a GML polygon/prism.

Thanks,
--Richard

On Jan 18, 2010, at 2:39 PM, Winterbottom, James wrote:

> Martin I am sure will add to this but this is my take on what the
> issues with your statements below are.
>
> Firstly, you are trying to represent uncertainty using significant
> figures, and a number of very credible references have been cited
> indicating that this is a very bad idea.
>
> Secondly, when you turn this into XML, there is no way to express
> the difference between the two numbers you describe below. When the
> XML is interpreted, they are both represented by exactly the same
> IEEE double. This means that your intent of representing uncertainty
> through significant figures is completely lost and you are
> misrepresenting the location, and indeed the area of uncertainty
> around it.
>
> To my mind, these are the main issues for us BISing this document in
> the first place.
>
> Cheers
> James
>
>
>
>
>
>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> Behalf
>> Of James M. Polk
>> Sent: Tuesday, 19 January 2010 6:02 AM
>> To: Thomson, Martin; Bernard Aboba; geopriv@ietf.org
>> Subject: Re: [Geopriv] Issue #3: GML Mapping
>>
>> At 05:17 PM 1/17/2010, Thomson, Martin wrote:
>>>> [BA] Any recommendations on how we should
>>> resolve the remaining aspects of Issue #3?
>>>
>>> I still don’t really know what resolution means.
>>
>> well... that's silly (so I'm expecting this to
>> actually be a trap question), as several folks
>> have explained this to you (and others) over the years.
>>
>> To fall into your trap, let me explain again
>> (even though John S. explains it best):
>>
>> The resolution field indicates how many bits to
>> be considered valid (left to right) when looking
>> at a Lat, Long or Alt field value.
>>
>> The analogy is a subnet mask, but I know most
>> here don't understand that -- where the mask
>> doesn't indicate the length of the host part but
>> of what shouldn't be viewed at all.
>>
>> This was never really meant to indicate less than
>> all integers within a Lat/Long/Alt value, but it
>> could. It is meant to indicate the number of
>> decimals to account for (i.e., is the number X.1
>> or X.100000 -- which are two different numbers entirely).
>>
>> put another way, albeit loosely defined -
>> resolution is a left to right length field within
>> the binary to indicate how many bits to convert
>> from binary to decimal for a particular
>> Lat/Long/Alt value. All bit values to the right
>> of the resolution indication are to be ignored.
>>
>> Marc or John S can correct me.
>>
>> James
>>
>>> That lies at the heart of the problem. Hence my
>>> preference to defer to James P. (or one of his colleagues) at this
>>> point.
>>>
>>> As far as I can extract from the history of the
>>> issue, there are two possible interpretations, and maybe more:
>>>
>>> (1) If resolution is roughly analogous to
>>> uncertainty, then I don’t see an easy way to
>>> provide a GML->3825 mapping. Following the
>>> same process that I used for the uncertainty
>>> mappings just leads to weird results (the 32 degree crossover
>>> problem).
>>>
>>> The 3825->GML mapping is easy enough for this
>>> case, and it could be based on the old
>>> examples, but there are a few minor
>>> mathematical errors (for instance, the very
>>> first point states that res2 is -1 to 128,
>>> which is inconsistent with res5 at -64 to -80;
>>> I think that res2 should be 0 to -128).
>>>
>>> (2) If resolution is simply a way of encoding
>>> significant digits (i.e., 3 bits =~ 1 decimal
>>> digit; 10 bits =~ 3 decimal digits), then the
>>> mapping is simply a GML point<->3825 mapping,
>>> but the examples would have to be entirely replaced.
>>>
>>> I don't have any particular preference.
>>>
>>> --Martin
>>>
>>>
>>> _______________________________________________
>>> Geopriv mailing list Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Issue #3: GML Mapping

Martin I am sure will add to this but this is my take on what the issues with your statements below are.

Firstly, you are trying to represent uncertainty using significant figures, and a number of very credible references have been cited indicating that this is a very bad idea.

Secondly, when you turn this into XML, there is no way to express the difference between the two numbers you describe below. When the XML is interpreted, they are both represented by exactly the same IEEE double. This means that your intent of representing uncertainty through significant figures is completely lost and you are misrepresenting the location, and indeed the area of uncertainty around it.

To my mind, these are the main issues for us BISing this document in the first place.

Cheers
James






> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
> Of James M. Polk
> Sent: Tuesday, 19 January 2010 6:02 AM
> To: Thomson, Martin; Bernard Aboba; geopriv@ietf.org
> Subject: Re: [Geopriv] Issue #3: GML Mapping
>
> At 05:17 PM 1/17/2010, Thomson, Martin wrote:
> > > [BA] Any recommendations on how we should
> > resolve the remaining aspects of Issue #3?
> >
> >I still don’t really know what resolution means.
>
> well... that's silly (so I'm expecting this to
> actually be a trap question), as several folks
> have explained this to you (and others) over the years.
>
> To fall into your trap, let me explain again
> (even though John S. explains it best):
>
> The resolution field indicates how many bits to
> be considered valid (left to right) when looking
> at a Lat, Long or Alt field value.
>
> The analogy is a subnet mask, but I know most
> here don't understand that -- where the mask
> doesn't indicate the length of the host part but
> of what shouldn't be viewed at all.
>
> This was never really meant to indicate less than
> all integers within a Lat/Long/Alt value, but it
> could. It is meant to indicate the number of
> decimals to account for (i.e., is the number X.1
> or X.100000 -- which are two different numbers entirely).
>
> put another way, albeit loosely defined -
> resolution is a left to right length field within
> the binary to indicate how many bits to convert
> from binary to decimal for a particular
> Lat/Long/Alt value. All bit values to the right
> of the resolution indication are to be ignored.
>
> Marc or John S can correct me.
>
> James
>
> >That lies at the heart of the problem. Hence my
> >preference to defer to James P. (or one of his colleagues) at this point.
> >
> >As far as I can extract from the history of the
> >issue, there are two possible interpretations, and maybe more:
> >
> > (1) If resolution is roughly analogous to
> > uncertainty, then I don’t see an easy way to
> > provide a GML->3825 mapping. Following the
> > same process that I used for the uncertainty
> > mappings just leads to weird results (the 32 degree crossover problem).
> >
> > The 3825->GML mapping is easy enough for this
> > case, and it could be based on the old
> > examples, but there are a few minor
> > mathematical errors (for instance, the very
> > first point states that res2 is -1 to 128,
> > which is inconsistent with res5 at -64 to -80;
> > I think that res2 should be 0 to -128).
> >
> > (2) If resolution is simply a way of encoding
> > significant digits (i.e., 3 bits =~ 1 decimal
> > digit; 10 bits =~ 3 decimal digits), then the
> > mapping is simply a GML point<->3825 mapping,
> > but the examples would have to be entirely replaced.
> >
> >I don't have any particular preference.
> >
> >--Martin
> >
> >
> >_______________________________________________
> >Geopriv mailing list Geopriv@ietf.org
> >https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Issue #3: GML Mapping

At 05:17 PM 1/17/2010, Thomson, Martin wrote:
> > [BA] Any recommendations on how we should
> resolve the remaining aspects of Issue #3?
>
>I still don’t really know what resolution means.

well... that's silly (so I'm expecting this to
actually be a trap question), as several folks
have explained this to you (and others) over the years.

To fall into your trap, let me explain again
(even though John S. explains it best):

The resolution field indicates how many bits to
be considered valid (left to right) when looking
at a Lat, Long or Alt field value.

The analogy is a subnet mask, but I know most
here don't understand that -- where the mask
doesn't indicate the length of the host part but
of what shouldn't be viewed at all.

This was never really meant to indicate less than
all integers within a Lat/Long/Alt value, but it
could. It is meant to indicate the number of
decimals to account for (i.e., is the number X.1
or X.100000 -- which are two different numbers entirely).

put another way, albeit loosely defined -
resolution is a left to right length field within
the binary to indicate how many bits to convert
from binary to decimal for a particular
Lat/Long/Alt value. All bit values to the right
of the resolution indication are to be ignored.

Marc or John S can correct me.

James

>That lies at the heart of the problem. Hence my
>preference to defer to James P. (or one of his colleagues) at this point.
>
>As far as I can extract from the history of the
>issue, there are two possible interpretations, and maybe more:
>
> (1) If resolution is roughly analogous to
> uncertainty, then I don’t see an easy way to
> provide a GML->3825 mapping. Following the
> same process that I used for the uncertainty
> mappings just leads to weird results (the 32 degree crossover problem).
>
> The 3825->GML mapping is easy enough for this
> case, and it could be based on the old
> examples, but there are a few minor
> mathematical errors (for instance, the very
> first point states that res2 is -1 to 128,
> which is inconsistent with res5 at -64 to -80;
> I think that res2 should be 0 to -128).
>
> (2) If resolution is simply a way of encoding
> significant digits (i.e., 3 bits =~ 1 decimal
> digit; 10 bits =~ 3 decimal digits), then the
> mapping is simply a GML point<->3825 mapping,
> but the examples would have to be entirely replaced.
>
>I don't have any particular preference.
>
>--Martin
>
>
>_______________________________________________
>Geopriv mailing list Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Issue #3: GML Mapping

> [BA] Any recommendations on how we should resolve the remaining aspects of Issue #3?

I still don't really know what resolution means. That lies at the heart of the problem. Hence my preference to defer to James P. (or one of his colleagues) at this point.

As far as I can extract from the history of the issue, there are two possible interpretations, and maybe more:

(1) If resolution is roughly analogous to uncertainty, then I don't see an easy way to provide a GML->3825 mapping. Following the same process that I used for the uncertainty mappings just leads to weird results (the 32 degree crossover problem).

The 3825->GML mapping is easy enough for this case, and it could be based on the old examples, but there are a few minor mathematical errors (for instance, the very first point states that res2 is -1 to 128, which is inconsistent with res5 at -64 to -80; I think that res2 should be 0 to -128).

(2) If resolution is simply a way of encoding significant digits (i.e., 3 bits =~ 1 decimal digit; 10 bits =~ 3 decimal digits), then the mapping is simply a GML point<->3825 mapping, but the examples would have to be entirely replaced.

I don't have any particular preference.

--Martin


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Issue #29: Review by Randy Gellens

I don't think the two are in conflict: The option itself expresses a rectangular prism (within the coordinate space), which may contain a more complex shape.  Perhaps it would make sense to replace the referenced sentence with something like the following?

"

In effect, this describes a rectangular prism, which may be used as as a coarse representation of a more complex shape that fits within it.  (See Section 2.3.2 for more detail on the correspondence between shapes and uncertainty.)

"

--Richard

On Jan 17, 2010, at 2:15 AM, Bernard Aboba wrote:

I believe I have addressed sub-issues 1, 2, and 3 of Issue #29 in RFC 3825bis-05:
http://tools.ietf.org/html/draft-ietf-geopriv-rfc3825bis

However, sub-issue #4 is still outstanding:

4: Conflict between text and figure


In "1.2. Resolution and Uncertainty," it says about uncertainty: 

"In effect, this describes a rectangular prism." However, the ASCII 
art in section "2.3.2. Latitude and Longitude Uncertainty", the shape 
is more complex than a rectangular prism, it has angles and cut-outs 
which don't seem to follow from anything.

[BA] Any opinions on how we should resolve this?



_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] Issue #3: GML Mapping

A good portion of Issue #3 was resolved in RFC 3825bis-05:
http://tools.ietf.org/html/draft-ietf-geopriv-rfc3825bis

However, as Martin notes, we do not have GML mapping examples for the resolution fields (or fixes for errors in the current examples):

"...and I forgot, I cannot provide examples of GML mappings for the resolution fields. The current examples have some errors as well. I recommend that James Polk look at these."

[BA] Any recommendations on how we should resolve the remaining aspects of Issue #3?

[Geopriv] Issue #29: Review by Randy Gellens

I believe I have addressed sub-issues 1, 2, and 3 of Issue #29 in RFC 3825bis-05:
http://tools.ietf.org/html/draft-ietf-geopriv-rfc3825bis

However, sub-issue #4 is still outstanding:

4: Conflict between text and figure


In "1.2. Resolution and Uncertainty," it says about uncertainty:

"In effect, this describes a rectangular prism." However, the ASCII
art in section "2.3.2. Latitude and Longitude Uncertainty", the shape
is more complex than a rectangular prism, it has angles and cut-outs
which don't seem to follow from anything.

[BA] Any opinions on how we should resolve this?

[Geopriv] I-D Action:draft-ietf-geopriv-rfc3825bis-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

Title : Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information
Author(s) : J. Polk, et al.
Filename : draft-ietf-geopriv-rfc3825bis-05.txt
Pages : 26
Date : 2010-01-14

This document specifies Dynamic Host Configuration Protocol Options
(both DHCPv4 and DHCPv6) for the coordinate-based geographic location
of the client. The Location Configuration Information (LCI) includes
latitude, longitude, and altitude, with resolution or uncertainty
indicators for each. Separate parameters indicate the reference
datum for each of these values.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-rfc3825bis-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

[Geopriv] Notification rate control in SIP

Folks,

the SIPCORE WG intends to WGLC the following draft shortly:

http://tools.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-02.txt

However, before starting the WGLC, we want to bring it to the attention
of the Geopriv WG in case someone has comments on it. Should you want to
provide input on this draft, please do it on the SIPCORE mailing list.

Thanks,

Gonzalo
SIPCORE WG co-chair
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] geolocation compare

Actually, he asked the chairs before he sent to the list :)

If I understand correctly, the CAIDA program is more focused on
comparing implementations than on protocol issues. I invited him to
ping the geopriv list in case there were any implementors on here that
might be interested.

On Jan 6, 2010, at 3:14 AM, Hannes Tschofenig wrote:

> Interesting activity.
>
> I suggest that you talk to the working group chairs, Bradley, since
> this group has worked on protocol mechanisms to obtain high-quality
> location information based on IP-address (and other information)
> information in a privacy sensitive way (unlike some other mechanisms
> you might have been looking at).
>
> Ciao
> Hannes
>
> -------- Original-Nachricht --------
>> Datum: Tue, 5 Jan 2010 09:07:14 -0800
>> Von: Bradley Huffaker <bhuffake@caida.org>
>> An: geopriv@ietf.org
>> Betreff: [Geopriv] geolocation compare
>
>> CAIDA plans to conduct a comparison of geolcocation tools for
>>
>> determining the location of Internet Protocal (IP) address (and other
>>
>> identifiers) in the summer of 2010.
>>
>>
>>
>> At this time we wish to receive feedback from interested parties
>>
>> on input to the comparison survey, whether they wish to participate
>>
>> and in what capacity.
>>
>>
>>
>> * What is your primary interest in geolocation services?
>>
>> Legal, academic, content localization, disaster preparedness,
>>
>> regulation, ...
>>
>>
>>
>> * Can you provide ground truth geolocation information for your
>>
>> organization?
>>
>>
>>
>> * Do you have suggested metrics, questions, or tests to include in
>>
>> the comparisons?
>>
>>
>>
>> * If you provide a geolocation service, under what conditions
>> would
>>
>> you be willing to participate?
>>
>>
>>
>> * If you use a Geolocation service(s), which do you use and in
>> what
>>
>> way?
>>
>>
>>
>> * Which companies do you consider to be the primary providers of
>>
>> geolocation services at this time?
>>
>>
>>
>> Please send any comments to: geocompare-info@caida.org
>>
>>
>>
>> Details can be found:
>> http://www.caida.org/projects/cybersecurity/geolocation/
>>
>> --
>> "Be always at war with your vices, at peace with your neighbors,
>> and let each new year find you a better man." - Benjamin Franklin
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] geolocation compare

Interesting activity.

I suggest that you talk to the working group chairs, Bradley, since this group has worked on protocol mechanisms to obtain high-quality location information based on IP-address (and other information) information in a privacy sensitive way (unlike some other mechanisms you might have been looking at).

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Tue, 5 Jan 2010 09:07:14 -0800
> Von: Bradley Huffaker <bhuffake@caida.org>
> An: geopriv@ietf.org
> Betreff: [Geopriv] geolocation compare

> CAIDA plans to conduct a comparison of geolcocation tools for
>
> determining the location of Internet Protocal (IP) address (and other
>
> identifiers) in the summer of 2010.
>
>
>
> At this time we wish to receive feedback from interested parties
>
> on input to the comparison survey, whether they wish to participate
>
> and in what capacity.
>
>
>
> * What is your primary interest in geolocation services?
>
> Legal, academic, content localization, disaster preparedness,
>
> regulation, ...
>
>
>
> * Can you provide ground truth geolocation information for your
>
> organization?
>
>
>
> * Do you have suggested metrics, questions, or tests to include in
>
> the comparisons?
>
>
>
> * If you provide a geolocation service, under what conditions would
>
> you be willing to participate?
>
>
>
> * If you use a Geolocation service(s), which do you use and in what
>
> way?
>
>
>
> * Which companies do you consider to be the primary providers of
>
> geolocation services at this time?
>
>
>
> Please send any comments to: geocompare-info@caida.org
>
>
>
> Details can be found:
> http://www.caida.org/projects/cybersecurity/geolocation/
>
> --
> "Be always at war with your vices, at peace with your neighbors,
> and let each new year find you a better man." - Benjamin Franklin
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] FYI: I wonder what the implications are

No implications (without further judgment).

-------- Original-Nachricht --------
> Datum: Tue, 5 Jan 2010 12:33:16 -0700
> Von: "Carl Reed" <creed@opengeospatial.org>
> An: geopriv@ietf.org
> Betreff: [Geopriv] FYI: I wonder what the implications are

> http://apb.directionsmag.com/index.php?url=archives/7087-Apple-Patent-App-for-Latitude-like-Service.html&serendipity[csuccess]=true#feedback
>
>
> Carl Reed, PhD
> CTO and Executive Director Specification Program
> OGC
>
> The OGC: Helping the World to Communicate Geographically
>
> ---------------------
>
> This communication, including attachments, is for the exclusive use of
> addressee and may contain proprietary, confidential or privileged information.
> If you are not the intended recipient, any use, copying, disclosure,
> dissemination or distribution is strictly prohibited. If you are not the
> intended recipient, please notify the sender immediately by return email and
> delete this communication and destroy all copies.
>
> "The important thing is not to stop questioning." -- Albert Einstein
> "Security is mostly a superstition. It does not exist in nature. Life is
> either a daring adventure or nothing." -- Helen Keller
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] FYI: I wonder what the implications are

http://apb.directionsmag.com/index.php?url=archives/7087-Apple-Patent-App-for-Latitude-like-Service.html&serendipity[csuccess]=true#feedback

 

 

Carl Reed, PhD
CTO and Executive Director Specification Program
OGC

 

The OGC: Helping the World to Communicate Geographically

 

---------------------

 

This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender  immediately by return email and delete this communication and destroy all copies.

 

"The important thing is not to stop questioning." -- Albert Einstein
"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller

[Geopriv] geolocation compare

CAIDA plans to conduct a comparison of geolcocation tools for
determining the location of Internet Protocal (IP) address (and other
identifiers) in the summer of 2010.

At this time we wish to receive feedback from interested parties
on input to the comparison survey, whether they wish to participate
and in what capacity.

* What is your primary interest in geolocation services?
Legal, academic, content localization, disaster preparedness,
regulation, ...

* Can you provide ground truth geolocation information for your
organization?

* Do you have suggested metrics, questions, or tests to include in
the comparisons?

* If you provide a geolocation service, under what conditions would
you be willing to participate?

* If you use a Geolocation service(s), which do you use and in what
way?

* Which companies do you consider to be the primary providers of
geolocation services at this time?

Please send any comments to: geocompare-info@caida.org

Details can be found: http://www.caida.org/projects/cybersecurity/geolocation/

--
"Be always at war with your vices, at peace with your neighbors,
and let each new year find you a better man." - Benjamin Franklin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv