Monday, January 31, 2011

Re: [Geopriv] Consensus call: Civic extensions

+1

-Robins

On 01-Feb-2011 3:44 AM, "Brian Rosen" <br@brianrosen.net> wrote:
> I support this plan
>
> Brian
>
> On Jan 31, 2011, at 10:02 AM, Richard L. Barnes wrote:
>
>> Hey all,
>>
>> The chairs would like to get a sense of the working group for a plan for a group of civic-address-related issues.
>>
>> -- Request a milestone for civic address extensibility
>> Dec 2012 - Submit recommendations for civic address extensions as PS
>>
>> -- Adopt draft-winterbottom-geopriv-local-civic-04 as the basis for this milestone
>>
>> -- Merge draft-ietf-geopriv-prefix-00 and draft-george-geopriv-lamp-post-00 into the milestone draft.
>>
>> Please send comments on this proposal to the list by Monday, 7 Feb 2011.
>>
>> Thanks,
>> --Richard
>> _______________________________________________
>> 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

Posted by at

Re: [Geopriv] Consensus call: Civic extensions

Sounds good thanks Richard.

Cheers,
Martin

-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Richard L.Barnes
Sent: Tuesday, 1 February 2011 2:02 AM
To: geopriv@ietf.org
Subject: [Geopriv] Consensus call: Civic extensions

Hey all,

The chairs would like to get a sense of the working group for a plan for a group of civic-address-related issues.

-- Request a milestone for civic address extensibility
Dec 2012 - Submit recommendations for civic address extensions as PS

-- Adopt draft-winterbottom-geopriv-local-civic-04 as the basis for this milestone

-- Merge draft-ietf-geopriv-prefix-00 and draft-george-geopriv-lamp-post-00 into the milestone draft.

Please send comments on this proposal to the list by Monday, 7 Feb 2011.

Thanks,
--Richard
_______________________________________________
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

Posted by at

[Geopriv] I-D Action:draft-ietf-geopriv-res-gw-lis-discovery-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 : Location Information Server (LIS) Discovery using IP address and Reverse DNS
Author(s) : M. Thomson, R. Bellis
Filename : draft-ietf-geopriv-res-gw-lis-discovery-00.txt
Pages : 19
Date : 2011-01-31

The residential gateway is a device that has become an integral part
of home networking equipment. Discovering a Location Information
Server (LIS) is a necessary part of acquiring location information
for location-based services. However, discovering a LIS when a
residential gateway is present poses a configuration challenge,
requiring a method that is able to work around the obstacle presented
by the gateway.

This document describes a solution to this problem. The solution
provides alternative domain names as input to the LIS discovery
process based on the network addresses assigned to a Device.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-res-gw-lis-discovery-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.

Posted by at

Re: [Geopriv] Consensus call: Civic extensions

I support this plan

Brian

On Jan 31, 2011, at 10:02 AM, Richard L. Barnes wrote:

> Hey all,
>
> The chairs would like to get a sense of the working group for a plan for a group of civic-address-related issues.
>
> -- Request a milestone for civic address extensibility
> Dec 2012 - Submit recommendations for civic address extensions as PS
>
> -- Adopt draft-winterbottom-geopriv-local-civic-04 as the basis for this milestone
>
> -- Merge draft-ietf-geopriv-prefix-00 and draft-george-geopriv-lamp-post-00 into the milestone draft.
>
> Please send comments on this proposal to the list by Monday, 7 Feb 2011.
>
> Thanks,
> --Richard
> _______________________________________________
> 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

Posted by at

Re: [Geopriv] Consensus call: Civic extensions

Yes to the first two.

I have no strong opinion on the merging of prefix and lamp-post. I'll go with the crowd on that part.

On 2011-02-01 at 02:02:06, Richard L.Barnes wrote:
> Hey all,
>
> The chairs would like to get a sense of the working group for a plan
> for a group of civic-address-related issues.
>
> -- Request a milestone for civic address extensibility
> Dec 2012 - Submit recommendations for civic address extensions as PS
>
> -- Adopt draft-winterbottom-geopriv-local-civic-04 as the basis for
> this milestone
>
> -- Merge draft-ietf-geopriv-prefix-00 and draft-george-geopriv-lamp-
> post-00 into the milestone draft.
>
> Please send comments on this proposal to the list by Monday, 7 Feb
> 2011.
>
> Thanks,
> --Richard

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

Posted by at

Re: [Geopriv] Consensus call: Civic extensions

See inline:


>
> The chairs would like to get a sense of the working group for a plan for a
> group of civic-address-related issues.
>
> -- Request a milestone for civic address extensibility
> Dec 2012 - Submit recommendations for civic address extensions as PS
>
[AJW] I support the creation of this milestone.


> -- Adopt draft-winterbottom-geopriv-local-civic-04 as the basis for this
> milestone
>
[AJW] I support this proposal

> -- Merge draft-ietf-geopriv-prefix-00 and draft-george-geopriv-lamp-post-
> 00 into the milestone draft.
>
[AJW] I support this proposal also.

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

Posted by at

[Geopriv] Consensus call: Civic extensions

Hey all,

The chairs would like to get a sense of the working group for a plan for a group of civic-address-related issues.

-- Request a milestone for civic address extensibility
Dec 2012 - Submit recommendations for civic address extensions as PS

-- Adopt draft-winterbottom-geopriv-local-civic-04 as the basis for this milestone

-- Merge draft-ietf-geopriv-prefix-00 and draft-george-geopriv-lamp-post-00 into the milestone draft.

Please send comments on this proposal to the list by Monday, 7 Feb 2011.

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

Posted by at

Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04

We're going to go ahead with the (rough) consensus that we have on
this one, acknowledging that text changes can and will likely be made
before WGLC, and that the updated milestone is restricted to the first-
party case.

Alissa

On Jan 25, 2011, at 2:24 PM, Brian Rosen wrote:

> Is there an alternative document that you want to use as a basis for
> the milestone?
>
> Brian
>
> On Jan 25, 2011, at 3:43 AM, Hannes Tschofenig wrote:
>
>> I argued that the chosen approach is not the one I would like to
>> see moving forward, and the description in the document replicates
>> text we already have in other documents.
>>
>> In that sense I do not want this document as a WG item.
>>
>> On Jan 12, 2011, at 4:18 PM, Alissa Cooper wrote:
>>
>>> Now that we have a milestone to "submit recommendations for LIS
>>> discovery conducted by hosts behind residential gateways as
>>> Informational," I'd like to call for WG adoption of draft-thomson-
>>> geopriv-res-gw-lis-discovery-04. Please respond to the list by
>>> January 19, 2011 about adopting this document as a WG item.
>>>
>>> Thanks,
>>> Alissa
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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

Posted by at

Thursday, January 27, 2011

Re: [Geopriv] "Do not track" header field

Thanks. I've forwarded this to the WEBSEC list.

On 1/25/11 2:47 AM, Alissa Cooper wrote:
> And I've been talking to Sid at Mozilla about getting a draft ready
> before IETF 80.
>
> On Jan 24, 2011, at 9:49 PM, Richard L. Barnes wrote:
>
>> If you look at the Bugzilla link, Julian has already suggested that
>> this go to WEBSEC for IETF approval and de-X-ification.
>> --Richard
>>
>>
>> On Jan 24, 2011, at 4:45 PM, Thomson, Martin wrote:
>>
>>> They should really drop the X-...
>>>
>>> On 2011-01-25 at 08:41:41, Richard L. Barnes wrote:
>>>> This will likely come up on the WEBSEC list as well, but I thought this
>>>> might be interesting to GEOPRIV folks:
>>>>
>>>> Mozilla and Google Chrome are proposing to extend browsers to send a
>>>> "do not track" HTTP header of the following form:
>>>> X-Tracking-Choice: do-not-track
>>>>
>>>> This seems like another example of users sending along privacy
>>>> preferences with their data, just like PIDF-LO privacy rules, Creative
>>>> Commons licenses, etc.
>>>>
>>>> References:
>>>> <http://firstpersoncookie.wordpress.com/2011/01/23/more-choice-and-
>>>> control-over-online-tracking/>
>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=628197>
>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=628198>
>>>>
>>>> --Richard
>>>
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>>

Posted by at

Wednesday, January 26, 2011

Re: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC3825bis)

Note this phrase:
"The exact meaning of these values determined by the datum; the description in this section applies to the datums defined in this document. "

So the approach you're proposing is already there. (1) You can use any datum value you want, but (2) you have to define it. (4) This document defines the rules for the datums in the document (including WGS84).

(3) and (5) are noops. There is no default CRS, because it is always specified -- the datum bits always have a value. There are other datums besides WGS84 (see the IANA registry).

--Richard

On Jan 26, 2011, at 11:12 AM, Andy Mabbett wrote:

> Thank you, but I do think the the GeoURL approach:
>
> 1) Any recognised CRS may be used
> 2) For each a set of rules must be provided
> 3) The default CRS is WGS84
> 4) Here are the rules for WGS84...
> 5) No other CRS is recognised, yet.
>
> using wording based on that in the cited section of the GeoURL
> specifcation would be better, more compatible (not least with GeoURL),
> and more future proof; for the reasons given previously.
>
> On 23 January 2011 16:24, Bernard Aboba <bernard.aboba@gmail.com> wrote:
>> How about this?
>>
>> 2.3. Latitude and Longitude Fields
>>
>> The Latitude and Longitude values in this specification are encoded
>> as 34 bit, twos complement, fixed point values with 9 integer bits
>> and 25 fractional bits. The exact meaning of these values is
>> determined by the datum; the description in this section applies to
>> the datums defined in this document. This document uses the same
>> definition for all datums it specifies.
>>
>> When encoding, Latitude and Longitude values are rounded to the
>> nearest 34-bit binary representation. This imprecision is considered
>> acceptable for the purposes to which this form is intended to be
>> applied and is ignored when decoding.
>>
>> Positive latitudes are north of the equator and negative latitudes
>> are south of the equator. Positive longitudes are east of the Prime
>> Meridian (Greenwich) and negative (2s complement) longitudes are west
>> of the Prime Meridian.
>>
>> Within the coordinate reference systems defined in this document
>> (Datum values 1-3), longitude values outside the range of -180 to 180
>> decimal degrees or latitude values outside the range of -90 to 90
>> degrees MUST be considered invalid. Server implementations SHOULD
>> prevent the entry of invalid values within the selected coordinate
>> reference system. Location consumers MUST ignore invalid location
>> coordinates and SHOULD log invalid location errors.
>>
>>
>> On Sun, Jan 23, 2011 at 2:49 AM, Andy Mabbett <andy@pigsonthewing.org.uk>
>> wrote:
>>>
>>> On 23 January 2011 00:27, Bernard Aboba <bernard.aboba@gmail.com> wrote:
>>>> Here is a proposed revision of Section 2.3 to address the concern.
>>>> Comments
>>>> welcome.
>>>>
>>>> 2.3. Latitude and Longitude Fields
>>>
>>> [...]
>>>
>>>> Longitude values encoded by the DHCP server MUST be normalized to the
>>>> range from -180 to +180 degrees. Positive longitudes are east of the
>>>> Prime Meridian (Greenwich) and negative (2s complement) longitudes
>>>> are west of the Prime Meridian.
>>>
>>> geoURI (rfc5870) allows for a 'crs' (coordinate reference system)
>>> parameter so that, in future, coordinates on bodies such as The Moon
>>> or Mars can be expressed. Some such CRSs allow a longitude value range
>>> of 0-360, with no negative values, and of course these do not make
>>> reference to Greenwich.
>>>
>>> WGS84 is assumed as default, where no CRS is specified.
>>>
>>> It would be sensible to build in such future proofing - and
>>> consistency & compatibility - here, using the relevant sections of
>>> GeoURI (3.4.1, 3.4.2) as a model.
>>>
>>> See:
>>>
>>> <http://tools.ietf.org/html/rfc5870#section-3.4.1>
>>>
>>> <http://tools.ietf.org/html/rfc5870#section-3.4.2>
>>>
>>> also <http://en.wikipedia.org/wiki/Geo_URI>.
>>>
>>> --
>>> Andy Mabbett
>>> @pigsonthewing
>>> http://pigsonthewing.org.uk
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>
>>
>
>
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
> _______________________________________________
> 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

Posted by at

Re: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC3825bis)

Thank you, but I do think the the GeoURL approach:

1) Any recognised CRS may be used
2) For each a set of rules must be provided
3) The default CRS is WGS84
4) Here are the rules for WGS84...
5) No other CRS is recognised, yet.

using wording based on that in the cited section of the GeoURL
specifcation would be better, more compatible (not least with GeoURL),
and more future proof; for the reasons given previously.

On 23 January 2011 16:24, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> How about this?
>
> 2.3.  Latitude and Longitude Fields
>
>    The Latitude and Longitude values in this specification are encoded
>    as 34 bit, twos complement, fixed point values with 9 integer bits
>    and 25 fractional bits.  The exact meaning of these values is
>    determined by the datum; the description in this section applies to
>    the datums defined in this document.  This document uses the same
>    definition for all datums it specifies.
>
>    When encoding, Latitude and Longitude values are rounded to the
>    nearest 34-bit binary representation.  This imprecision is considered
>    acceptable for the purposes to which this form is intended to be
>    applied and is ignored when decoding.
>
>    Positive latitudes are north of the equator and negative latitudes
>    are south of the equator.  Positive longitudes are east of the Prime
>    Meridian (Greenwich) and negative (2s complement) longitudes are west
>    of the Prime Meridian.
>
>    Within the coordinate reference systems defined in this document
>    (Datum values 1-3), longitude values outside the range of -180 to 180
>    decimal degrees or latitude values outside the range of -90 to 90
>    degrees MUST be considered invalid.  Server implementations SHOULD
>    prevent the entry of invalid values within the selected coordinate
>    reference system.  Location consumers MUST ignore invalid location
>    coordinates and SHOULD log invalid location errors.
>
>
> On Sun, Jan 23, 2011 at 2:49 AM, Andy Mabbett <andy@pigsonthewing.org.uk>
> wrote:
>>
>> On 23 January 2011 00:27, Bernard Aboba <bernard.aboba@gmail.com> wrote:
>> > Here is a proposed revision of Section 2.3 to address the concern.
>> > Comments
>> > welcome.
>> >
>> > 2.3.  Latitude and Longitude Fields
>>
>> [...]
>>
>> >    Longitude values encoded by the DHCP server MUST be normalized to the
>> >    range from -180 to +180 degrees.  Positive longitudes are east of the
>> >    Prime Meridian (Greenwich) and negative (2s complement) longitudes
>> >    are west of the Prime Meridian.
>>
>> geoURI (rfc5870) allows for a 'crs' (coordinate reference system)
>> parameter so that, in future, coordinates on bodies such as The Moon
>> or Mars can be expressed. Some such CRSs allow a longitude value range
>> of 0-360, with no negative values, and of course these do not make
>> reference to Greenwich.
>>
>> WGS84 is assumed as default, where no CRS is specified.
>>
>> It would be sensible to build in such future proofing - and
>> consistency & compatibility - here, using the relevant sections of
>> GeoURI (3.4.1, 3.4.2) as a model.
>>
>> See:
>>
>> <http://tools.ietf.org/html/rfc5870#section-3.4.1>
>>
>> <http://tools.ietf.org/html/rfc5870#section-3.4.2>
>>
>> also <http://en.wikipedia.org/wiki/Geo_URI>.
>>
>> --
>> Andy Mabbett
>> @pigsonthewing
>> http://pigsonthewing.org.uk
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
>

--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Posted by at

Tuesday, January 25, 2011

[Geopriv] I-D Action:draft-ietf-geopriv-rfc3825bis-16.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-16.txt
Pages : 33
Date : 2011-01-25

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. This document obsoletes RFC 3825.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-rfc3825bis-16.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.

Posted by at

Re: [Geopriv] [geopriv] rfc3825bis #44 (closed): Jari's DISCUSS

#44: Jari's DISCUSS

Changes (by bernard_aboba@…):

* status: new => closed
* resolution: => fixed


Comment:

To address the concern bout clamping versus ignoring potential invalid
lat/long values, the proposal is to replace the text of Section 2.3 with
the following:

2.3. Latitude and Longitude Fields

The Latitude and Longitude values in this specification are encoded
as 34 bit, twos complement, fixed point values with 9 integer bits
and 25 fractional bits. The exact meaning of these values is
determined by the datum; the description in this section applies to
the datums defined in this document. This document uses the same
definition for all datums it specifies.

When encoding, Latitude and Longitude values are rounded to the
nearest 34-bit binary representation. This imprecision is considered
acceptable for the purposes to which this form is intended to be
applied and is ignored when decoding.

Positive latitudes are north of the equator and negative latitudes
are south of the equator. Positive longitudes are east of the Prime
Meridian (Greenwich) and negative (2s complement) longitudes are west
of the Prime Meridian.

Within the coordinate reference systems defined in this document
(Datum values 1-3), longitude values outside the range of -180 to 180
decimal degrees or latitude values outside the range of -90 to 90
degrees MUST be considered invalid. Server implementations SHOULD
prevent the entry of invalid values within the selected coordinate
reference system. Location consumers MUST ignore invalid location
coordinates and SHOULD log invalid location errors.

--
---------------------------------------+------------------------------------
Reporter: bernard_aboba@… | Owner: bernard_aboba@…
Type: defect | Status: closed
Priority: blocker | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version: 1.0
Severity: Submitted WG Document | Resolution: fixed
Keywords: |
---------------------------------------+------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/geopriv/trac/ticket/44#comment:2>
geopriv <http://tools.ietf.org/geopriv/>

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

Posted by at

Re: [Geopriv] Want to Track People? There's an App for That

 
Just a matter of time until the consumer begins to realize the implications to their privacy
 
Carl Reed, PhD
CTO and Executive Director Specification Program
Open Geospatial Consortium
www.opengeospatial.org
 
The OGC: Making Location Count!
 
---------------------
 
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
Posted by at

Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04

Is there an alternative document that you want to use as a basis for the milestone?

Brian

On Jan 25, 2011, at 3:43 AM, Hannes Tschofenig wrote:

> I argued that the chosen approach is not the one I would like to see moving forward, and the description in the document replicates text we already have in other documents.
>
> In that sense I do not want this document as a WG item.
>
> On Jan 12, 2011, at 4:18 PM, Alissa Cooper wrote:
>
>> Now that we have a milestone to "submit recommendations for LIS discovery conducted by hosts behind residential gateways as Informational," I'd like to call for WG adoption of draft-thomson-geopriv-res-gw-lis-discovery-04. Please respond to the list by January 19, 2011 about adopting this document as a WG item.
>>
>> Thanks,
>> Alissa
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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

Posted by at

Re: [Geopriv] "Do not track" header field

And I've been talking to Sid at Mozilla about getting a draft ready
before IETF 80.

On Jan 24, 2011, at 9:49 PM, Richard L. Barnes wrote:

> If you look at the Bugzilla link, Julian has already suggested that
> this go to WEBSEC for IETF approval and de-X-ification.
> --Richard
>
>
> On Jan 24, 2011, at 4:45 PM, Thomson, Martin wrote:
>
>> They should really drop the X-...
>>
>> On 2011-01-25 at 08:41:41, Richard L. Barnes wrote:
>>> This will likely come up on the WEBSEC list as well, but I thought
>>> this
>>> might be interesting to GEOPRIV folks:
>>>
>>> Mozilla and Google Chrome are proposing to extend browsers to send a
>>> "do not track" HTTP header of the following form:
>>> X-Tracking-Choice: do-not-track
>>>
>>> This seems like another example of users sending along privacy
>>> preferences with their data, just like PIDF-LO privacy rules,
>>> Creative
>>> Commons licenses, etc.
>>>
>>> References:
>>> <http://firstpersoncookie.wordpress.com/2011/01/23/more-choice-and-
>>> control-over-online-tracking/>
>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=628197>
>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=628198>
>>>
>>> --Richard
>>
>
> _______________________________________________
> 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

Posted by at

Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04

I argued that the chosen approach is not the one I would like to see moving forward, and the description in the document replicates text we already have in other documents.

In that sense I do not want this document as a WG item.

On Jan 12, 2011, at 4:18 PM, Alissa Cooper wrote:

> Now that we have a milestone to "submit recommendations for LIS discovery conducted by hosts behind residential gateways as Informational," I'd like to call for WG adoption of draft-thomson-geopriv-res-gw-lis-discovery-04. Please respond to the list by January 19, 2011 about adopting this document as a WG item.
>
> Thanks,
> Alissa
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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

Posted by at

Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04

I argued that the chosen approach is not the one I would like to see moving forward, and the description in the document replicates text we already have in other documents.

In that sense I do not want this document as a WG item.

On Jan 12, 2011, at 4:18 PM, Alissa Cooper wrote:

Now that we have a milestone to "submit recommendations for LIS discovery conducted by hosts behind residential gateways as Informational," I'd like to call for WG adoption of draft-thomson-geopriv-res-gw-lis-discovery-04. Please respond to the list by January 19, 2011 about adopting this document as a WG item.

Thanks,
Alissa











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

Posted by at

Monday, January 24, 2011

Re: [Geopriv] LIS discovery implementation thoughts

I'm assuming you mean the authentication against the input to the U-NAPTR process?

The way we have things structured, we have separate modules that communicate via pub/sub:

measurements ---+
+--> held --> zeus-locator [== application API]
lis-discovery ---+

(DHCP location is parallel to the HELD module, and also feeds the application API.)

The messages that the the lis-discovery module emits are of the form:
struct LisDiscoveryInfo {
std::string lisUri;
std::string domain;
}

So:

1. We could in principle do authentication against the input to U-NAPTR -- if it's supported by the underlying HTTP library. Right now, we're using libcurl, which does not support changes to the name that it authenticates.

2. At the same time, it would be awkward for the lis-discovery module to do HELD requests required to "verify that the LIS is able to provide location information". It's not impossible (there's actually a separate HeldRequest object (think like XMLHttpRequest) that could be used), but it would feel kind of like a circular dependency.

--Richard

On Jan 24, 2011, at 7:43 PM, Thomson, Martin wrote:

> What are your thoughts on the server authentication requirements? Or is that another part of the validation that you aren't performing?
>
> I have to commend the approach you are using. I always hoped that this is how discovery would be implemented.
>
> --Martin
>
> On 2011-01-14 at 15:47:58, Richard L. Barnes wrote:
>> One additional note: Our client is not technically compliant with RFC
>> 5986, since it doesn't validate the URI with a HELD request:
>> "
>> A Device that discovers a LIS URI MUST attempt to verify that the
>> LIS
>> is able to provide location information. For the HELD protocol, the
>> Device verifies the URI by making a location request to the LIS.
>> "
>>
>> --Richard
>>
>>
>> On Jan 13, 2011, at 11:45 PM, Richard L. Barnes wrote:
>>
>>> Hey all,
>>>
>>> Just wanted to share some impressions of the LIS discovery process,
>> including NAT traversal, based on our experience implementing this
>> function in the igtk project [1]. (Note: The techniques here haven't
>> yet been merged into the sourceforge version.)
>>>
>>> The basic flow-chart in RFC 5986 is pretty easy to implement,
>> although it wasn't really clear what to do for step (3), "Check URI",
>> beyond verifying that it's a well-formed URI. In pseudo-code, we ended
>> up with something like this:
>>>
>>> foreach (NetworkInterface iface) {
>>> DomainIterator it(iface);
>>> while (it.hasNext()) {
>>> string lisUri = performDdds(it.next());
>>> if (valid(lisUri)) { return lisUri; }
>>> }
>>> }
>>>
>>> Here the DomainIterator supplies the following domains, if they are
>> available:
>>> 1. Option 213 [NB: Not DHCPv6 capable]
>>> 2. Option 15
>>>
>>> The DomainIterator construct also allows us to easily extend the
>> process to support NAT traversal. If neither of the above options
>> works, the DomainIterator looks at the IP address for the interface,
>> and if it's private (any of the IANA reserved ranges [2]), then it does
>> a STUN request to find a public address. Using either the interface
>> address or the STUN address, it then provides the following domains:
>>> 3. The reverse domain
>>> 4. The reverse domain with the first label dropped
>>> 5. The reverse domain with the first two labels dropped
>>>
>>> The entire LIS discovery service, which listens for network interface
>> changes and emits alerts when it finds a new LIS URI, required 584
>> lines of C++. A very basic STUN client was another 293.
>>>
>>> So in a nutshell, extending a client from RFC 5986 to draft-thomson-
>> geopriv-res-gw-lis-discovery was pretty trivial, just a matter of
>> adding a few domains to the search list. We hope to have the code
>> posted to the igtk site soon; if you're interested in an advance copy,
>> let me know and I can send you an interim snapshot.
>>>
>>> --Richard
>>>
>>>
>>> [1] <http://igtk.sourceforge.net/>
>>> [2] <http://www.iana.org/assignments/ipv4-address-space/ipv4-address-
>> space.xml>
>>> _______________________________________________
>>> 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

Posted by at

Re: [Geopriv] LIS discovery implementation thoughts

What are your thoughts on the server authentication requirements? Or is that another part of the validation that you aren't performing?

I have to commend the approach you are using. I always hoped that this is how discovery would be implemented.

--Martin

On 2011-01-14 at 15:47:58, Richard L. Barnes wrote:
> One additional note: Our client is not technically compliant with RFC
> 5986, since it doesn't validate the URI with a HELD request:
> "
> A Device that discovers a LIS URI MUST attempt to verify that the
> LIS
> is able to provide location information. For the HELD protocol, the
> Device verifies the URI by making a location request to the LIS.
> "
>
> --Richard
>
>
> On Jan 13, 2011, at 11:45 PM, Richard L. Barnes wrote:
>
> > Hey all,
> >
> > Just wanted to share some impressions of the LIS discovery process,
> including NAT traversal, based on our experience implementing this
> function in the igtk project [1]. (Note: The techniques here haven't
> yet been merged into the sourceforge version.)
> >
> > The basic flow-chart in RFC 5986 is pretty easy to implement,
> although it wasn't really clear what to do for step (3), "Check URI",
> beyond verifying that it's a well-formed URI. In pseudo-code, we ended
> up with something like this:
> >
> > foreach (NetworkInterface iface) {
> > DomainIterator it(iface);
> > while (it.hasNext()) {
> > string lisUri = performDdds(it.next());
> > if (valid(lisUri)) { return lisUri; }
> > }
> > }
> >
> > Here the DomainIterator supplies the following domains, if they are
> available:
> > 1. Option 213 [NB: Not DHCPv6 capable]
> > 2. Option 15
> >
> > The DomainIterator construct also allows us to easily extend the
> process to support NAT traversal. If neither of the above options
> works, the DomainIterator looks at the IP address for the interface,
> and if it's private (any of the IANA reserved ranges [2]), then it does
> a STUN request to find a public address. Using either the interface
> address or the STUN address, it then provides the following domains:
> > 3. The reverse domain
> > 4. The reverse domain with the first label dropped
> > 5. The reverse domain with the first two labels dropped
> >
> > The entire LIS discovery service, which listens for network interface
> changes and emits alerts when it finds a new LIS URI, required 584
> lines of C++. A very basic STUN client was another 293.
> >
> > So in a nutshell, extending a client from RFC 5986 to draft-thomson-
> geopriv-res-gw-lis-discovery was pretty trivial, just a matter of
> adding a few domains to the search list. We hope to have the code
> posted to the igtk site soon; if you're interested in an advance copy,
> let me know and I can send you an interim snapshot.
> >
> > --Richard
> >
> >
> > [1] <http://igtk.sourceforge.net/>
> > [2] <http://www.iana.org/assignments/ipv4-address-space/ipv4-address-
> space.xml>
> > _______________________________________________
> > 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

Posted by at

Re: [Geopriv] General consensus on Civic schema extensions

I am in favor of this.

I have some issues with the current draft, but they are relatively minor.  I am comfortable with the basic idea.

Brian

On Jan 24, 2011, at 6:28 PM, Winterbottom, James wrote:

Hi Alissa and Richard,
 
At the virtual interim, did we get general consensus from the WG that we needed to have a milestone for a document describing how to do civic address extensions? I did think that we had at least got that. If we did, can we get a milestone added to the charter for it please?
 
Given the relatively little opposition to the latest version of local-civic, it also seems like we might be approaching consensus on a mechanism to meet this milestone.
 
Cheers
James
 
 
 
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Posted by at

[Geopriv] General consensus on Civic schema extensions

Hi Alissa and Richard,

 

At the virtual interim, did we get general consensus from the WG that we needed to have a milestone for a document describing how to do civic address extensions? I did think that we had at least got that. If we did, can we get a milestone added to the charter for it please?

 

Given the relatively little opposition to the latest version of local-civic, it also seems like we might be approaching consensus on a mechanism to meet this milestone.

 

Cheers

James

 

 

 

Posted by at

Re: [Geopriv] "Do not track" header field

If you look at the Bugzilla link, Julian has already suggested that this go to WEBSEC for IETF approval and de-X-ification.
--Richard


On Jan 24, 2011, at 4:45 PM, Thomson, Martin wrote:

> They should really drop the X-...
>
> On 2011-01-25 at 08:41:41, Richard L. Barnes wrote:
>> This will likely come up on the WEBSEC list as well, but I thought this
>> might be interesting to GEOPRIV folks:
>>
>> Mozilla and Google Chrome are proposing to extend browsers to send a
>> "do not track" HTTP header of the following form:
>> X-Tracking-Choice: do-not-track
>>
>> This seems like another example of users sending along privacy
>> preferences with their data, just like PIDF-LO privacy rules, Creative
>> Commons licenses, etc.
>>
>> References:
>> <http://firstpersoncookie.wordpress.com/2011/01/23/more-choice-and-
>> control-over-online-tracking/>
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=628197>
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=628198>
>>
>> --Richard
>

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

Posted by at

Re: [Geopriv] "Do not track" header field

They should really drop the X-...

On 2011-01-25 at 08:41:41, Richard L. Barnes wrote:
> This will likely come up on the WEBSEC list as well, but I thought this
> might be interesting to GEOPRIV folks:
>
> Mozilla and Google Chrome are proposing to extend browsers to send a
> "do not track" HTTP header of the following form:
> X-Tracking-Choice: do-not-track
>
> This seems like another example of users sending along privacy
> preferences with their data, just like PIDF-LO privacy rules, Creative
> Commons licenses, etc.
>
> References:
> <http://firstpersoncookie.wordpress.com/2011/01/23/more-choice-and-
> control-over-online-tracking/>
> <https://bugzilla.mozilla.org/show_bug.cgi?id=628197>
> <https://bugzilla.mozilla.org/show_bug.cgi?id=628198>
>
> --Richard

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

Posted by at

[Geopriv] "Do not track" header field

This will likely come up on the WEBSEC list as well, but I thought this might be interesting to GEOPRIV folks:

Mozilla and Google Chrome are proposing to extend browsers to send a "do not track" HTTP header of the following form:
X-Tracking-Choice: do-not-track

This seems like another example of users sending along privacy preferences with their data, just like PIDF-LO privacy rules, Creative Commons licenses, etc.

References:
<http://firstpersoncookie.wordpress.com/2011/01/23/more-choice-and-control-over-online-tracking/>
<https://bugzilla.mozilla.org/show_bug.cgi?id=628197>
<https://bugzilla.mozilla.org/show_bug.cgi?id=628198>

--Richard

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

Posted by at

Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04

Thanks all, looks like we have consensus on this one.
Alissa

On Jan 12, 2011, at 2:18 PM, Alissa Cooper wrote:

> Now that we have a milestone to "submit recommendations for LIS
> discovery conducted by hosts behind residential gateways as
> Informational," I'd like to call for WG adoption of draft-thomson-
> geopriv-res-gw-lis-discovery-04. Please respond to the list by
> January 19, 2011 about adopting this document as a WG item.
>
> Thanks,
> Alissa
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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

Posted by at

Sunday, January 23, 2011

Re: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC3825bis)

How about this?

2.3.  Latitude and Longitude Fields

   The Latitude and Longitude values in this specification are encoded
   as 34 bit, twos complement, fixed point values with 9 integer bits
   and 25 fractional bits.  The exact meaning of these values is
   determined by the datum; the description in this section applies to
   the datums defined in this document.  This document uses the same
   definition for all datums it specifies.

   When encoding, Latitude and Longitude values are rounded to the
   nearest 34-bit binary representation.  This imprecision is considered
   acceptable for the purposes to which this form is intended to be
   applied and is ignored when decoding.

   Positive latitudes are north of the equator and negative latitudes
   are south of the equator.  Positive longitudes are east of the Prime
   Meridian (Greenwich) and negative (2s complement) longitudes are west
   of the Prime Meridian.

   Within the coordinate reference systems defined in this document
   (Datum values 1-3), longitude values outside the range of -180 to 180
   decimal degrees or latitude values outside the range of -90 to 90
   degrees MUST be considered invalid.  Server implementations SHOULD
   prevent the entry of invalid values within the selected coordinate
   reference system.  Location consumers MUST ignore invalid location
   coordinates and SHOULD log invalid location errors.


On Sun, Jan 23, 2011 at 2:49 AM, Andy Mabbett <andy@pigsonthewing.org.uk> wrote:
On 23 January 2011 00:27, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> Here is a proposed revision of Section 2.3 to address the concern.  Comments
> welcome.
>
> 2.3.  Latitude and Longitude Fields

[...]

>    Longitude values encoded by the DHCP server MUST be normalized to the
>    range from -180 to +180 degrees.  Positive longitudes are east of the
>    Prime Meridian (Greenwich) and negative (2s complement) longitudes
>    are west of the Prime Meridian.

geoURI (rfc5870) allows for a 'crs' (coordinate reference system)
parameter so that, in future, coordinates on bodies such as The Moon
or Mars can be expressed. Some such CRSs allow a longitude value range
of 0-360, with no negative values, and of course these do not make
reference to Greenwich.

WGS84 is assumed as default, where no CRS is specified.

It would be sensible to build in such future proofing - and
consistency & compatibility - here, using the relevant sections of
GeoURI (3.4.1, 3.4.2) as a model.

See:

<http://tools.ietf.org/html/rfc5870#section-3.4.1>

<http://tools.ietf.org/html/rfc5870#section-3.4.2>

also <http://en.wikipedia.org/wiki/Geo_URI>.

--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Posted by at

Re: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC3825bis)

On 23 January 2011 00:27, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> Here is a proposed revision of Section 2.3 to address the concern.  Comments
> welcome.
>
> 2.3.  Latitude and Longitude Fields

[...]

>    Longitude values encoded by the DHCP server MUST be normalized to the
>    range from -180 to +180 degrees.  Positive longitudes are east of the
>    Prime Meridian (Greenwich) and negative (2s complement) longitudes
>    are west of the Prime Meridian.

geoURI (rfc5870) allows for a 'crs' (coordinate reference system)
parameter so that, in future, coordinates on bodies such as The Moon
or Mars can be expressed. Some such CRSs allow a longitude value range
of 0-360, with no negative values, and of course these do not make
reference to Greenwich.

WGS84 is assumed as default, where no CRS is specified.

It would be sensible to build in such future proofing - and
consistency & compatibility - here, using the relevant sections of
GeoURI (3.4.1, 3.4.2) as a model.

See:

<http://tools.ietf.org/html/rfc5870#section-3.4.1>

<http://tools.ietf.org/html/rfc5870#section-3.4.2>

also <http://en.wikipedia.org/wiki/Geo_URI>.

--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Posted by at

Saturday, January 22, 2011

Re: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC3825bis)

Here is a proposed revision of Section 2.3 to address the concern.  Comments welcome.

2.3.  Latitude and Longitude Fields

   The Latitude and Longitude values in this specification are encoded
   as 34 bit, twos complement, fixed point values with 9 integer bits
   and 25 fractional bits.  The exact meaning of these values is
   determined by the datum; the description in this section applies to
   the datums defined in this document.  This document uses the same
   definition for all datums it specifies.

   Latitude values encoded by the DHCP server MUST be constrained to the
   range from -90 to +90 degrees.  Positive latitudes are north of the
   equator and negative latitudes are south of the equator.

   Longitude values encoded by the DHCP server MUST be normalized to the
   range from -180 to +180 degrees.  Positive longitudes are east of the
   Prime Meridian (Greenwich) and negative (2s complement) longitudes
   are west of the Prime Meridian.

   Since it is required that server-provided values of Latitude and
   Longitude be constrained, location consumers encountering values
   outside the range MUST ignore the location data rather than
   attempting to normalize potentially invalid values.  Location
   consumers SHOULD log the error.

   When encoding, Latitude and Longitude values are rounded to the
   nearest 34-bit binary representation.  This imprecision is considered
   acceptable for the purposes to which this form is intended to be
   applied and is ignored when decoding.


On Fri, Jan 21, 2011 at 2:11 PM, Carl Reed <creed@opengeospatial.org> wrote:
I would agree that if a value is outside the normal ranges for lat and long, then there is an error somewhere in the workflow. As such, an error message should be reported to the application or the user. Clamping to +90 is actually creating even more erroneous data. Thanks, Bernard.
 
Carl
 
----- Original Message -----
Sent: Wednesday, January 19, 2011 9:50 AM
Subject: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC3825bis)

Ari Keränen's review (see below) included a comment on issues arising from clamping of
latitude/longitude values outside the range. 

Comments?
===========================================
2.3. Latitude and Longitude Fields

Latitude values encoded by the DHCP server MUST be constrained to the
range from -90 to +90 degrees. Location consumers MUST be prepared
to normalize values outside this range. Values outside the range are
normalized by clamping [...]

If the values MUST be within those boundaries, doesn't it mean that a
value that is out of the range is somewhat likely completely wrong (due
to a broken implementation) and thus it would make sense to ignore it
rather than try to normalize the value and make it appear as if it was
valid? I'm not sure if I'd like to be liberal in what I accept when it
comes to information that could literally be a matter of life and death.

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

Posted by at

Friday, January 21, 2011

Re: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC3825bis)

I would agree that if a value is outside the normal ranges for lat and long, then there is an error somewhere in the workflow. As such, an error message should be reported to the application or the user. Clamping to +90 is actually creating even more erroneous data. Thanks, Bernard.
 
Carl
 
----- Original Message -----
Sent: Wednesday, January 19, 2011 9:50 AM
Subject: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC3825bis)

Ari Keränen's review (see below) included a comment on issues arising from clamping of
latitude/longitude values outside the range. 

Comments?
===========================================
2.3. Latitude and Longitude Fields

Latitude values encoded by the DHCP server MUST be constrained to the
range from -90 to +90 degrees. Location consumers MUST be prepared
to normalize values outside this range. Values outside the range are
normalized by clamping [...]

If the values MUST be within those boundaries, doesn't it mean that a
value that is out of the range is somewhat likely completely wrong (due
to a broken implementation) and thus it would make sense to ignore it
rather than try to normalize the value and make it appear as if it was
valid? I'm not sure if I'd like to be liberal in what I accept when it
comes to information that could literally be a matter of life and death.

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

Wednesday, January 19, 2011

Re: [Geopriv] Civic extensions draft

Can we please see some feedback on this updated document?
We would like to get the issue of civic schema extensions resolved quickly to avoid extensions occurring that differ from what we would all like to see happen.

Cheers
James


> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
> Of Thomson, Martin
> Sent: Friday, 17 December 2010 3:44 PM
> To: geopriv@ietf.org
> Subject: [Geopriv] Civic extensions draft
>
> I've just posted a revision to the -local-civic draft that captures some
> of the progress in the civic address extension discussions we've been
> having.
>
> http://tools.ietf.org/html/draft-winterbottom-geopriv-local-civic-04
>
> A lot has changed. The changes are based on the discussions that Brian,
> Richard and I have had both on and off list.
>
> This isn't the end of the discussion. We haven't completely finished
> ironing out all the details, but we've made some fairly significant
> progress.
>
> The high points:
>
> - problem: there are two formats, and currently two places that
> extensions to those formats can originate
>
> - solution: the draft makes the XML format the only place an extension
> can originate
>
> - consequence: one final CAtype is defined for carrying an XML-
> originating extension
>
> - consequence: the CAtype registry is revised to reflect this
>
>
> I think that this is simple, pragmatic and backward compatible.
>
> --Martin
>
> p.s. On leave until January. Apologies if responses are a little slow.
> _______________________________________________
> 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

Posted by at

Re: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC 3825bis)

In reality, wouldn't the decision be made at higher layers anyway?  The DHCP client typically would not be the place to execute the clamping (or discard) logic, the LCI Option would be passed up to other components (e.g. location provider or application) where the decision would be made.  Given this, advocating that the DHCP client make a discard decision which relies on detailed knowledge of the option format doesn't make sense to me.

It seems more likely that a decision on discard would be made by the application which has available the full range of information relating to location determination (e.g. local policies, whether other more accurate location values are available, whether manual override has occurred, etc.).

On Wed, Jan 19, 2011 at 8:57 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:
It seems like things are likely to be wrong in either case, assuming you're not at a pole.  So I don't see any difference between one flavor of wrong and the other, at that level.  At least clamping is less likely to cause problems at higher layers.

--Richard


On Jan 19, 2011, at 11:50 AM, Bernard Aboba wrote:

> Ari Keränen's review (see below) included a comment on issues arising from clamping of
> latitude/longitude values outside the range.
>
> Comments?
> ===========================================
> 2.3. Latitude and Longitude Fields
>
> Latitude values encoded by the DHCP server MUST be constrained to the
> range from -90 to +90 degrees. Location consumers MUST be prepared
> to normalize values outside this range. Values outside the range are
> normalized by clamping [...]
>
> If the values MUST be within those boundaries, doesn't it mean that a
> value that is out of the range is somewhat likely completely wrong (due
> to a broken implementation) and thus it would make sense to ignore it
> rather than try to normalize the value and make it appear as if it was
> valid? I'm not sure if I'd like to be liberal in what I accept when it
> comes to information that could literally be a matter of life and death.
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv


Posted by at

Re: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC 3825bis)

It seems like things are likely to be wrong in either case, assuming you're not at a pole. So I don't see any difference between one flavor of wrong and the other, at that level. At least clamping is less likely to cause problems at higher layers.

--Richard


On Jan 19, 2011, at 11:50 AM, Bernard Aboba wrote:

> Ari Keränen's review (see below) included a comment on issues arising from clamping of
> latitude/longitude values outside the range.
>
> Comments?
> ===========================================
> 2.3. Latitude and Longitude Fields
>
> Latitude values encoded by the DHCP server MUST be constrained to the
> range from -90 to +90 degrees. Location consumers MUST be prepared
> to normalize values outside this range. Values outside the range are
> normalized by clamping [...]
>
> If the values MUST be within those boundaries, doesn't it mean that a
> value that is out of the range is somewhat likely completely wrong (due
> to a broken implementation) and thus it would make sense to ignore it
> rather than try to normalize the value and make it appear as if it was
> valid? I'm not sure if I'd like to be liberal in what I accept when it
> comes to information that could literally be a matter of life and death.
>
> _______________________________________________
> 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

Posted by at

[Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC 3825bis)

Ari Keränen's review (see below) included a comment on issues arising from clamping of
latitude/longitude values outside the range. 

Comments?
===========================================
2.3. Latitude and Longitude Fields

Latitude values encoded by the DHCP server MUST be constrained to the
range from -90 to +90 degrees. Location consumers MUST be prepared
to normalize values outside this range. Values outside the range are
normalized by clamping [...]

If the values MUST be within those boundaries, doesn't it mean that a
value that is out of the range is somewhat likely completely wrong (due
to a broken implementation) and thus it would make sense to ignore it
rather than try to normalize the value and make it appear as if it was
valid? I'm not sure if I'd like to be liberal in what I accept when it
comes to information that could literally be a matter of life and death.

Posted by at

Friday, January 14, 2011

[Geopriv] I-D Action:draft-ietf-geopriv-rfc3825bis-15.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-15.txt
Pages : 33
Date : 2011-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. This document obsoletes RFC 3825.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-rfc3825bis-15.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.

Posted by at

Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04

On 13 Jan 2011, at 21:54, Thomson, Martin wrote:

> Ditto.

And I support it too, of course :)

Ray


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

Posted by at

Re: [Geopriv] empty conditions element in common policy (rfc4745)

On Thu, 2011-01-13 at 10:50 -0500, ext Richard L. Barnes wrote:
> > or something similar. It might be good to add this as errdata since i'm
> > pretty certain this can be seen in iop tests.
>
> I'm not familiar enough with the erratum process to say whether this is appropriate, but I agree that this seems like a good thing to clarify. It might make sense to write a brief I-D with clarifications to RFC 4745, especially if there are other interop issues.
>
> --Richard
>
The errdata process <http://www.rfc-editor.org/errata.php> is imo just
enough, since this is a pretty minor clarification where a one liner fix
will make the intended behavior unambiguous. I don't mind if someone
wants to make a bigger stab on this, but certainly, i'm _not_ proposing
that. Imo, for implementors, errdata is authoritative and fast enough
(instead of referring to some mailing list thread discussion).

The rfc authors have been silent though...

br Jari


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

Posted by at

Thursday, January 13, 2011

[Geopriv] FW: New Version Notification for draft-thomson-geopriv-location-obscuring-02

I've submitted a new version of the location obscuring draft.

Changes include:

- Added an improved method for generating random vectors that allows for less variation during interpolation. This means that the recommended grid size can be made much smaller (now 8 times the obscuring distance, down from 20).
- Refined the calculations around what grid size was necessary and the effect that changing the offset vector has on worst-case ability to reduce uncertainty area.
- Added an example.
- Wording and the usual editorial cleanup stuff.

My demonstration page is now live here, using the updated method:

<http://held-location.sourceforge.net/js_geoshape/maptest.html>

--

I've also developed a few tools for visualizing the interpolation process using Processing. The following are probably of most interest:

Random vector grid visualization
<http://held-location.sourceforge.net/randomVectorGrid/randomVectorGrid.jar>
Shows how random vectors are chosen and interpolated. Compares both interpolation methods.

Square peg interpolation visualization
<http://held-location.sourceforge.net/interpolation/interp.jar>
Shows how interpolation is used between two different points in the circle. Compares interpolation methods and demonstrates how the square peg method is used. I found the loops that form to be interesting.

--Martin

p.s. I'd link to the applets directly, but I couldn't be sure that they are safe - the applets caused every browser I have to die horribly. It seems like a Java problem. Strip the last part of the path off if you are game.

On 2011-01-14 at 16:25:38, IETF I-D Submission Tool wrote:
> A new version of I-D, draft-thomson-geopriv-location-obscuring-02.txt
> has been successfully submitted by Martin Thomson and posted to the
> IETF repository.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Posted by at

Re: [Geopriv] LIS discovery implementation thoughts

One additional note: Our client is not technically compliant with RFC 5986, since it doesn't validate the URI with a HELD request:
"
A Device that discovers a LIS URI MUST attempt to verify that the LIS
is able to provide location information. For the HELD protocol, the
Device verifies the URI by making a location request to the LIS.
"

--Richard


On Jan 13, 2011, at 11:45 PM, Richard L. Barnes wrote:

> Hey all,
>
> Just wanted to share some impressions of the LIS discovery process, including NAT traversal, based on our experience implementing this function in the igtk project [1]. (Note: The techniques here haven't yet been merged into the sourceforge version.)
>
> The basic flow-chart in RFC 5986 is pretty easy to implement, although it wasn't really clear what to do for step (3), "Check URI", beyond verifying that it's a well-formed URI. In pseudo-code, we ended up with something like this:
>
> foreach (NetworkInterface iface) {
> DomainIterator it(iface);
> while (it.hasNext()) {
> string lisUri = performDdds(it.next());
> if (valid(lisUri)) { return lisUri; }
> }
> }
>
> Here the DomainIterator supplies the following domains, if they are available:
> 1. Option 213 [NB: Not DHCPv6 capable]
> 2. Option 15
>
> The DomainIterator construct also allows us to easily extend the process to support NAT traversal. If neither of the above options works, the DomainIterator looks at the IP address for the interface, and if it's private (any of the IANA reserved ranges [2]), then it does a STUN request to find a public address. Using either the interface address or the STUN address, it then provides the following domains:
> 3. The reverse domain
> 4. The reverse domain with the first label dropped
> 5. The reverse domain with the first two labels dropped
>
> The entire LIS discovery service, which listens for network interface changes and emits alerts when it finds a new LIS URI, required 584 lines of C++. A very basic STUN client was another 293.
>
> So in a nutshell, extending a client from RFC 5986 to draft-thomson-geopriv-res-gw-lis-discovery was pretty trivial, just a matter of adding a few domains to the search list. We hope to have the code posted to the igtk site soon; if you're interested in an advance copy, let me know and I can send you an interim snapshot.
>
> --Richard
>
>
> [1] <http://igtk.sourceforge.net/>
> [2] <http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml>
> _______________________________________________
> 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

Posted by at

[Geopriv] LIS discovery implementation thoughts

Hey all,

Just wanted to share some impressions of the LIS discovery process, including NAT traversal, based on our experience implementing this function in the igtk project [1]. (Note: The techniques here haven't yet been merged into the sourceforge version.)

The basic flow-chart in RFC 5986 is pretty easy to implement, although it wasn't really clear what to do for step (3), "Check URI", beyond verifying that it's a well-formed URI. In pseudo-code, we ended up with something like this:

foreach (NetworkInterface iface) {
DomainIterator it(iface);
while (it.hasNext()) {
string lisUri = performDdds(it.next());
if (valid(lisUri)) { return lisUri; }
}
}

Here the DomainIterator supplies the following domains, if they are available:
1. Option 213 [NB: Not DHCPv6 capable]
2. Option 15

The DomainIterator construct also allows us to easily extend the process to support NAT traversal. If neither of the above options works, the DomainIterator looks at the IP address for the interface, and if it's private (any of the IANA reserved ranges [2]), then it does a STUN request to find a public address. Using either the interface address or the STUN address, it then provides the following domains:
3. The reverse domain
4. The reverse domain with the first label dropped
5. The reverse domain with the first two labels dropped

The entire LIS discovery service, which listens for network interface changes and emits alerts when it finds a new LIS URI, required 584 lines of C++. A very basic STUN client was another 293.

So in a nutshell, extending a client from RFC 5986 to draft-thomson-geopriv-res-gw-lis-discovery was pretty trivial, just a matter of adding a few domains to the search list. We hope to have the code posted to the igtk site soon; if you're interested in an advance copy, let me know and I can send you an interim snapshot.

--Richard


[1] <http://igtk.sourceforge.net/>
[2] <http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Posted by at

Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04

+1

Carl

> Now that we have a milestone to "submit recommendations for LIS
> discovery conducted by hosts behind residential gateways as
> Informational," I'd like to call for WG adoption of draft-thomson-
> geopriv-res-gw-lis-discovery-04. Please respond to the list by January
> 19, 2011 about adopting this document as a WG item.
>
> Thanks,
> Alissa
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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

Posted by at

Re: [Geopriv] Consensus call: Adoption of draft-thomson-geopriv-res-gw-lis-discovery-04

Ditto.

On 2011-01-13 at 14:42:48, Richard L. Barnes wrote:
> +1
>
> On Jan 12, 2011, at 7:55 PM, Winterbottom, James wrote:
>
> > I support the adoption of this document.
> >
> > ________________________________________
> > From: geopriv-bounces@ietf.org [geopriv-bounces@ietf.org] On Behalf
> Of Alissa Cooper [acooper@cdt.org]
> > Sent: Wednesday, January 12, 2011 8:18 AM
> > To: geopriv@ietf.org
> > Subject: [Geopriv] Consensus call: Adoption of draft-thomson-
> geopriv-res-gw-lis-discovery-04
> >
> > Now that we have a milestone to "submit recommendations for LIS
> > discovery conducted by hosts behind residential gateways as
> > Informational," I'd like to call for WG adoption of draft-thomson-
> > geopriv-res-gw-lis-discovery-04. Please respond to the list by
> January
> > 19, 2011 about adopting this document as a WG item.
> >
> > Thanks,
> > Alissa
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Posted by at

[Geopriv] Errata report on erratum 2066 to RFC5774 ("Considerations for Civic Addresses in the PIDF-LO") and errata 2521 and 2522 to RFC 5986 ("Discovering the Local Location Information Server")

======================================================================
RFC5774, "Considerations for Civic Addresses in the PIDF-LO:
Guidelines and IANA Registry Definition",
Source of RFC: geopriv (rai)

Errata ID: 2066

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-03-05

Section 1, 6th para says:

Section 3.4 of [RFC4776] also contains instructions on the creation
| of civic address considerations documents on page 8. This document
updates that section and replaces said instructions with Sections 4
and 5 of this memo.


It should say:

Section 3.4 of [RFC4776] also contains instructions on the creation
| of civic address considerations documents on page 9. This document
updates that section and replaces said instructions with Sections 4
and 5 of this memo.


Notes:

Rationale:
This indeed refers to the second paragraph on page _9_ of RFC 4776.
----------------------------------------------------------------------
Recommended status: (correct) Hold for document update
======================================================================
RFC5986, "Discovering the Local Location Information Server (LIS)"
Source of RFC: geopriv (rai)

Errata ID: 2521

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-09-15

Section 3.4,3rd para says:

DHCPv4 option 15 [RFC2132] provides an indication of the domain name
| that a host uses when resolving hostnames in DNS. This option is
used when the DHCPv4 access domain name is not available.

It should say:

DHCPv4 option 15 [RFC2132] provides an indication of the domain name
| that a host uses when resolving hostnames in the DNS. This option is
used when the DHCPv4 access domain name is not available.

Notes:

Rationale: missing article
----------------------------------------------------------------------
Recommended status: (correct) Hold for document update

This erratum is difficult to assess absolutely; the terms "DNS" and
"the DNS" are both used with this meaning. RFC 5986 uses "the DNS"
twice and "DNS" once, making it difficult to state which convention it
uses, and therefore, which uses are incorrect. In any case, the
editor of the revised document can resolve it.
======================================================================
RFC5986, "Discovering the Local Location Information Server (LIS)"
Source of RFC: geopriv (rai)

Errata ID: 2522

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-09-15

Section 5, pg.12 says:

| The domain name that used to authenticate the LIS is the domain name
input to the U-NAPTR process, not the output of that process
[RFC3958], [RFC4848]. As a result, the results of DNS queries do not
need integrity protection.

It should say:

| The domain name that is used to authenticate the LIS is the domain
name input to the U-NAPTR process, not the output of that process
[RFC3958], [RFC4848]. As a result, the results of DNS queries do not
need integrity protection.

Notes:

Rationale: missing verb: "is"
----------------------------------------------------------------------
Recommended status: (correct) Hold for document update

Either "is" should be inserted (to give "The domain name that is used
to ...") or "that" should be removed (to give "The domain name used
to ...". In any case, the editor of the revised document can resolve
it.
======================================================================

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

Posted by at

Re: [Geopriv] empty conditions element in common policy (rfc4745)

> But a programmatic way, if m means matching: ...

Actually, I was thinking of something like the following:

bool m = true;
for (int i=0; i<conditions.size() && m; ++i) {
m = m && conditions[i].test();
}

Either way, you have to iterate through the conditions.


> or something similar. It might be good to add this as errdata since i'm
> pretty certain this can be seen in iop tests.

I'm not familiar enough with the erratum process to say whether this is appropriate, but I agree that this seems like a good thing to clarify. It might make sense to write a brief I-D with clarifications to RFC 4745, especially if there are other interop issues.

--Richard

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

Posted by at
Subscribe to: Posts (Atom)