[Geopriv] geopriv-policy plans

We got together this morning to discuss the plans for geopriv-policy.

The plan was to create the following issues in the WG tracker:

- create a registry for location obscuring algorithms
- describe the mechanism for algorithm selection
- describe the goals (not requirements!) for algorithms
- select/define and describe the old algorithm (this requires making the algorithm complete)
- complete and describe Jorge's algorithm

Only the first three of these are absolutely critical for us to progress the draft. We want to do that by May 15.

We have commitments from myself and Jorge to do this, but we'll need WG feedback if we are going to complete these tasks by our self-imposed deadline of May 15.

--

Some of the goals and constraints that we discussed (and may have agreed on to varying degrees) were:

Constraints

- The algorithm must take only one policy input: a distance in meters. Other parameters need to be fixed in the definition of the algorithm.

- The algorithm must describe what to do with uncertainty on the input location(s).

- The algorithm must be accurate [duckham05] - that is, the reported location must enclose the known location at the time that it is reported

Goals

- The algorithm should protect a static known location.

- The algorithm should protect the known location when the target moves. I admit that this needs to be more specific.

- The algorithm should protect the known location when the target returns to the same approximate location multiple times.

- The algorithm should limit the knowledge that an adversary gains about known locations at different times or locations, if an adversary learns of a known location for a given reported location. That is, if an adversary finds a known location, they can't use that information to (perfectly) derive known locations from other reported locations.

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

[Geopriv] Relative location update

Thanks to Brian for updating the relative location draft. This is now pretty close to complete.

With these minor changes (which shouldn't take long), I'm happy with the document in its current state.

ADDITIONS

Section 4.8 notes that we need TLVs for dynamic components. This should be relatively simple.

x. Dynamic Location TLVs

Dynamic location elements use the definitions in [RFC5962].

x.x Orientation

The orientation of the target is described using one or two angles.

| type | len | angle | angle (optional) |

x.x Speed

The speed of the target is a scalar value in meters per second.

| type | len | speed |

x.x Heading

The heading, or direction of travel, is described using one or two angles.

| type | len | angle | angle (optional) |

NITS

Section 4.8 contains this note, that should be removed (the corresponding text is correct in Section 4.9, modulo the below):
If this TLV contains the reference location, then we need to
explicitly say that the shape TLVs in here use WGS84; and when the
shapes are outside of this, they use the relative:2d or relative:3d
forms.

Section 4.7 says that the baseline TLVs are in 3825. Is this supposed to be 4776 and 3825? (or maybe just even 4776 since 3825 technically doesn't have TLVs).

Text suggestion:
Baseline locations is described using the formats defined in [RFC4776] or [RFC3825bis].

Section 4.9 has a broken xref.

I'll check the examples and schema when I've got better access to tools.

--Martin

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

[Geopriv] WGLC: draft-ietf-geopriv-policy-uri-00

This is a GEOPRIV Working Group Last Call for comments on
draft-ietf-geopriv-policy-uri-00

Please send your comments to the list by 12 April 2011. As always,
please remember to send a note in if you've read the document and have
no other comments other than "its ready to go" - we need those as much
as we need "I found a problem."

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

[Geopriv] WGLC: draft-ietf-geopriv-deref-protocol-02

This is a GEOPRIV Working Group Last Call for comments on
draft-ietf-geopriv-deref-protocol-02

Please send your comments to the list by 12 April 2011. As always,
please remember to send a note in if you've read the document and have
no other comments other than "its ready to go" - we need those as much
as we need "I found a problem."

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

[Geopriv] Fwd: I-D Action:draft-ietf-geopriv-relative-location-01.txt

I have updated this draft.  It has a slew of changes that deal with more precise definitions of coordinates, etc, going back to a 1 byte length, and separating a 2D polygon from a 3D polygon with a separate type code.

Brian

Begin forwarded message:

From: Internet-Drafts@ietf.org

Date: March 28, 2011 12:15:02 PM GMT+02:00

To: i-d-announce@ietf.org

Cc: geopriv@ietf.org

Subject: I-D Action:draft-ietf-geopriv-relative-location-01.txt

Reply-To: internet-drafts@ietf.org

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           : Relative Location Representation
Author(s)       : M. Thomson, et al.
Filename        : draft-ietf-geopriv-relative-location-01.txt
Pages           : 34
Date            : 2011-03-28

This document defines an extension to PIDF-LO (RFC4119) for the
expression of location information that is defined relative to a
reference point.  The reference point may be expressed as a geodetic
or civic location, and the relative offset may be one of several
shapes.  Optionally, a reference to a secondary document (such as a
map image) can be included, along with the relationship of the map
coordinate system to the reference/offset coordinate system to allow
display of the map with the reference point and the relative offset.
Also included in this document is a Type/Length/Value (TLV)
representation of the relative location for use in other protocols
that use TLVs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-relative-location-01.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] I-D Action:draft-ietf-geopriv-relative-location-01.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 : Relative Location Representation
Author(s) : M. Thomson, et al.
Filename : draft-ietf-geopriv-relative-location-01.txt
Pages : 34
Date : 2011-03-28

This document defines an extension to PIDF-LO (RFC4119) for the
expression of location information that is defined relative to a
reference point. The reference point may be expressed as a geodetic
or civic location, and the relative offset may be one of several
shapes. Optionally, a reference to a secondary document (such as a
map image) can be included, along with the relationship of the map
coordinate system to the reference/offset coordinate system to allow
display of the map with the reference point and the relative offset.
Also included in this document is a Type/Length/Value (TLV)
representation of the relative location for use in other protocols
that use TLVs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-relative-location-01.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] draft-marshall-geopriv-location-transform-00

Carl:
Thank you for your comments. As we start to flesh this work out, we
will seek to pull in and align with existing definitions, ontologies,
etc., where feasible.

-roger.

-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
Behalf Of Carl Reed
Sent: Monday, March 21, 2011 4:24 PM
To: Thomson, Martin; geopriv@ietf.org;
draft-marshall-geopriv-location-transform@tools.ietf.org
Cc: George Percivall
Subject: Re: [Geopriv] draft-marshall-geopriv-location-transform-00

In terms of transforms, there is considerable standards work in this
area,
including terms and definitions, ontologies, and so forth.

For example, for coordinate reference system transforms (CRS):

From ISO 19111 (Joint OGC/ISO document) A coordinate transformation or
coordinate conversion operates on coordinates, not on coordinate
reference
systems. Coordinate operation has been modeled in ISO 19107 by the
operation
"Transform" of the GM_Object class. Changing the coordinates of a point
or
set of points referenced to a coordinate reference system associated
with
one datum to make them refer to another a coordinate reference system
associated with a different datum is called a datum transformation.
(Strictly, this is a misnomer: it is the coordinates that are being
transformed). In the case of vertical datums, the transformation
consists of
simply adding a shift to all height values - often the shift is
constant. In
the case of plane or spatial coordinates, a datum transformation often
takes
the form of a similarity or Helmert transformation, consisting of a
rotation
and scaling operation in addition to a simple translation. In the plane,
a
Helmert transformation has four parameters; in space, seven.

As can be seen, there are very specific rules and approaches to
coordinate
transformation.

In ISO 19119: Services, there is a taxonomy of geoprocessing services
including numerous transforms, such as vector to raster, raster to
vector,
address to point, point to address, conflation, and on and on.

The point is that Martin is correct, there are a potentially a very
large
number of geo transforms that can be applied to LO content. I need to
read
draft-marshall-geopriv-location-transform closely so that I can provide
more
specific input.

Regards

Carl

----- Original Message -----
From: "Thomson, Martin" <Martin.Thomson@commscope.com>
To: <geopriv@ietf.org>;
<draft-marshall-geopriv-location-transform@tools.ietf.org>
Sent: Wednesday, March 16, 2011 9:30 PM
Subject: [Geopriv] draft-marshall-geopriv-location-transform-00

> This new attempt on the old idea is a good sign that the authors are
> intent on getting this right. I like that.
>
> At this stage, there isn't a really enough detail to properly assess
the
> draft.
>
> I think that the basic model that is hinted at in Section 8 could be
> structured differently. The current suggestion has several points of
> articulation. Civic has a range of profiles, which is probably only
one
> layer; but geodetic locations have both CRS and shape. That leads to
a
> plethora of transformations when all combinations are considered.
>
> When each is combined, both input and output of the transformation
need to
> be described with a subset of: location type, civic address profile,
civic
> address language, geographic CRS, geodetic shape, and anything else
that
> is later added.
>
> Rather than specify a whole range of x-to-y transforms, in all the
> combinatorial glory that implies, this could be made quite simple.
The
> service accepts a location and a description of the location that is
> desired. The service either produces the desired form, or an error.
The
> error can indicate that the target form is not supported, or that the
> input form is not one of those that are supported for the output form
(or
> the range of other errors specific to the transformation). In either
> case, the service might be able to describe the forms that it desires.
>
> That all assumes that you are using a request-response model for the
> protocol, which would seem to be the case, but that detail is absent.
I
> can think of other models, some of which could have advantages. For
> instance, if you could imagine using REST and even HTTP content
> negotiation for the transformed object, it might work, particularly
when
> you are talking about producing civic addresses, which might be
manifested
> as discrete resources.
>
> --Martin
>
> p.s. I was surprised to see that James is now working for TCS..., or
not.
> _______________________________________________
> 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

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] draft-marshall-geopriv-location-transform-00

Martin:
I appreciate your comments. Please find my short responses inline.

-roger.

-----Original Message-----
From: Thomson, Martin [mailto:Martin.Thomson@commscope.com]
Sent: Wednesday, March 16, 2011 8:30 PM
To: geopriv@ietf.org;
draft-marshall-geopriv-location-transform@tools.ietf.org
Subject: draft-marshall-geopriv-location-transform-00

This new attempt on the old idea is a good sign that the authors are
intent on getting this right. I like that.

At this stage, there isn't a really enough detail to properly assess the
draft.

I think that the basic model that is hinted at in Section 8 could be
structured differently. The current suggestion has several points of
articulation. Civic has a range of profiles, which is probably only one
layer; but geodetic locations have both CRS and shape. That leads to a
plethora of transformations when all combinations are considered.

When each is combined, both input and output of the transformation need
to be described with a subset of: location type, civic address profile,
civic address language, geographic CRS, geodetic shape, and anything
else that is later added.

[rm - okay, I think this makes sense.]

Rather than specify a whole range of x-to-y transforms, in all the
combinatorial glory that implies, this could be made quite simple. The
service accepts a location and a description of the location that is
desired. The service either produces the desired form, or an error.
The error can indicate that the target form is not supported, or that
the input form is not one of those that are supported for the output
form (or the range of other errors specific to the transformation). In
either case, the service might be able to describe the forms that it
desires.

[rm - agree that simple is good.]

That all assumes that you are using a request-response model for the
protocol, which would seem to be the case, but that detail is absent. I
can think of other models, some of which could have advantages. For
instance, if you could imagine using REST and even HTTP content
negotiation for the transformed object, it might work, particularly when
you are talking about producing civic addresses, which might be
manifested as discrete resources.

[rm - okay, I don't think we're tied down to anything yet.]

--Martin

p.s. I was surprised to see that James is now working for TCS..., or
not.

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] HELD in Firefox

Update: Firefox 4.0 has been released, and contains the HELD code noted in the below message. (In particular, it only supports <Circle> in PIDF, and it uses a slightly old version of -measurements.) Instructions for enabling it are the same.

--Richard

On Jun 30, 2010, at 2:50 PM, Richard L. Barnes wrote:

> An FYI on implementation:
>
> The first pre-beta version of Firefox 4.0, released today, includes a minimal version of HELD, as a location provider for the W3C Geolocation API. The profile of HELD implemented is as follows:
> -- Requests have no <locationType>, but they do have a <measurements> object with a set of WiFi measurements
> -- The only responses that are used are ones that contain a <gs:Circle>, representing a point with an uncertainty radius.
> -- Civic addresses and location URIs are not used.
>
> HELD is not enabled by defuault. To use it:
> 1. Open about:config
> 2. Set geo.wifi.protocol = 1
> 3. Set geo.wifi.uri to the URI of a HELD server. For testing, I have been using <http://geopriv.dreamhosters.com/cgi-bin/lis4.pl>, which proxies requests through to the Google location server.
>
> Once this is set up, queries to the W3C Geolocation API should initiate a HELD query to the specified server.
>
> You can download the pre-release builds here:
> <http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/>
>
> Finally, of course, this being pre-beta software, there's a minor bug to fix. Inside the 'components' directory for Firefox, find NetworkGeolocationProvider.js, and change line 354 from this:
> switch (this.protocol) {
> to this:
> switch (protocol) {
> Everything should of course work perfectly :)
>
> --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

Re: [Geopriv] draft-marshall-geopriv-location-transform-00

In terms of transforms, there is considerable standards work in this area,
including terms and definitions, ontologies, and so forth.

For example, for coordinate reference system transforms (CRS):

From ISO 19111 (Joint OGC/ISO document) A coordinate transformation or
coordinate conversion operates on coordinates, not on coordinate reference
systems. Coordinate operation has been modeled in ISO 19107 by the operation
"Transform" of the GM_Object class. Changing the coordinates of a point or
set of points referenced to a coordinate reference system associated with
one datum to make them refer to another a coordinate reference system
associated with a different datum is called a datum transformation.
(Strictly, this is a misnomer: it is the coordinates that are being
transformed). In the case of vertical datums, the transformation consists of
simply adding a shift to all height values - often the shift is constant. In
the case of plane or spatial coordinates, a datum transformation often takes
the form of a similarity or Helmert transformation, consisting of a rotation
and scaling operation in addition to a simple translation. In the plane, a
Helmert transformation has four parameters; in space, seven.

As can be seen, there are very specific rules and approaches to coordinate
transformation.

In ISO 19119: Services, there is a taxonomy of geoprocessing services
including numerous transforms, such as vector to raster, raster to vector,
address to point, point to address, conflation, and on and on.

The point is that Martin is correct, there are a potentially a very large
number of geo transforms that can be applied to LO content. I need to read
draft-marshall-geopriv-location-transform closely so that I can provide more
specific input.

Regards

Carl

----- Original Message -----
From: "Thomson, Martin" <Martin.Thomson@commscope.com>
To: <geopriv@ietf.org>;
<draft-marshall-geopriv-location-transform@tools.ietf.org>
Sent: Wednesday, March 16, 2011 9:30 PM
Subject: [Geopriv] draft-marshall-geopriv-location-transform-00

> This new attempt on the old idea is a good sign that the authors are
> intent on getting this right. I like that.
>
> At this stage, there isn't a really enough detail to properly assess the
> draft.
>
> I think that the basic model that is hinted at in Section 8 could be
> structured differently. The current suggestion has several points of
> articulation. Civic has a range of profiles, which is probably only one
> layer; but geodetic locations have both CRS and shape. That leads to a
> plethora of transformations when all combinations are considered.
>
> When each is combined, both input and output of the transformation need to
> be described with a subset of: location type, civic address profile, civic
> address language, geographic CRS, geodetic shape, and anything else that
> is later added.
>
> Rather than specify a whole range of x-to-y transforms, in all the
> combinatorial glory that implies, this could be made quite simple. The
> service accepts a location and a description of the location that is
> desired. The service either produces the desired form, or an error. The
> error can indicate that the target form is not supported, or that the
> input form is not one of those that are supported for the output form (or
> the range of other errors specific to the transformation). In either
> case, the service might be able to describe the forms that it desires.
>
> That all assumes that you are using a request-response model for the
> protocol, which would seem to be the case, but that detail is absent. I
> can think of other models, some of which could have advantages. For
> instance, if you could imagine using REST and even HTTP content
> negotiation for the transformed object, it might work, particularly when
> you are talking about producing civic addresses, which might be manifested
> as discrete resources.
>
> --Martin
>
> p.s. I was surprised to see that James is now working for TCS..., or not.
> _______________________________________________
> 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] Protocol Action: 'Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information' to Proposed Standard (draft-ietf-geopriv-rfc3825bis-17.txt)

The IESG has approved the following document:
- 'Dynamic Host Configuration Protocol Options for Coordinate-based
Location Configuration Information'
(draft-ietf-geopriv-rfc3825bis-17.txt) as a Proposed Standard

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

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-geopriv-rfc3825bis/

Technical Summary

This document is an update to the DHCP option format for coordinate-
based geolocation (RFC 3825). It clarifies the geospatial meaning of
the option, and adds an alternative interpretation (signaled by a
version field) that is more suitable for many use cases. While RFC
3825 applies only to DHCPv4, this document adds support for DHCPv6.

Working Group Summary

There is fairly wide consensus in the working group that this document
provides useful clarifications and extensions to the current RFC 3825
format for geolocation in DHCP.

Document Quality

The document has been reviewed by key participants from the GEOPRIV
working group.

Personnel

Richard Barnes is the document shepherd. Robert Sparks is the responsible Area Director.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

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

Hi Martin,

In our group, we had some discussion on obscuring location because we think
that it is a very interesting scientific problem. After doing some
literature research, I found the following publications, which cover the
topic of your draft.

[1] Duckham, M., Kulik, L., & Birtley, A. (2006). A Spatiotemporal Model of
Strategies and Counter Strategies for Location Privacy Protection. In
Geographic Information Science, 4th International Conference, GIScience
2006, pp. 47-64.
[2] http://portal.acm.org/citation.cfm?id=1569363
[3] http://portal.acm.org/citation.cfm?id=1770566
Including the references here in and the publications citing the references
above.

Based on this brief research overview, I strongly suggest to base the IETF
Geopriv work on location obfuscation on those solid research results. Maybe,
one of those researchers is willing to contribute to this WG. Do may ask
Matt Duckman. Isn't he a fellow countryman?

With best regards,
Christian

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Thomson, Martin
> Sent: Friday, January 14, 2011 7:07 AM
> To: geopriv@ietf.org
> Subject: [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

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

[Geopriv] Draft agenda for IETF 80

Here is the draft agenda for our session at IETF 80, please send
comments to the list today or tomorrow if you have any:

INTRO:
10m Chairs intro & administrivia

DISCUSSION OF DRAFTS IN IESG PROCESSING:
20m draft-ietf-geopriv-policy (H. Tschofenig)

WG DRAFT UPDATES:
20m draft-ietf-local-civic (B. Rosen)
20m draft-ietf-geopriv-res-gw-lis-discovery (R. Bellis)
10m draft-ietf-geopriv-held-measurements (M. Thomson)

NON-WG DRAFT PRESENTATIONS AND DISCUSSION:
20m draft-marshall-geopriv-location-transform-00 (R. Marshall)
10m draft-thomson-geopriv-http-geolocation (M. Thomson)

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

Re: [Geopriv] I-D Action:draft-ietf-geopriv-policy-23.txt

Hi,

Hannes and I have submitted a new version of the geopriv-policy draft.

http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-23.txt

Changes include:

a) Updated abstract
b) Updated introduction
c) Corrected typo in algorithm description
d) Removed all occurrence of "using protocol"
e) Added the pseudo-code to the appendix
f) Updated security consideration text.

we have addressed the issues brought up in the discussions. The
algorithm presented offers protection for static targets, (limited)
protection for moving targets, and protection for targets that
regularly visits a certain location. For further discussions and
other alternatives, see also
draft-thomson-geopriv-location-obscuring-02

I will be in Prague at the IETF meeting from Sunday until Tuesday, and
I will be happy to discuss the issues face to face with people
interested in the subject, and of course in the geopriv meeting on
Monday. Send me a mail if you want to meet in a small group (when?)
to discuss this.

On 3/14/11, Internet-Drafts@ietf.org <Internet-Drafts@ietf.org> wrote:
> 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 : Geolocation Policy: A Document Format for Expressing
> Privacy Preferences for Location Information
> Author(s) : H. Schulzrinne, et al.
> Filename : draft-ietf-geopriv-policy-23.txt
> Pages : 48
> Date : 2011-03-14
>
> This document defines an authorization policy language for
> controlling access to location information. It extends the Common
> Policy authorization framework to provide location-specific access
> control. More specifically, this document defines condition elements
> specific to location information in order to restrict access based on
> the current location of the Target.
>
> Furthermore, this document defines two algorithms for reducing the
> granularity of returned location information. The first algorithm is
> defined for usage with civic location information while the other one
> applies to geodetic location information. Both algorithms come with
> limitations, i.e. they provide location obfuscation under certain
> conditions and may therefore not be appropriate for all application
> domains.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-23.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 mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] draft-marshall-geopriv-location-transform-00

Martin:
Thank you for your comments. Ahead of more a thoughtful response, my apologies to James above all - for depicting him with said association - rather, I'm afraid it is my only a mistake in editing on my part.

-roger.

----- Original Message -----
From: Thomson, Martin [mailto:Martin.Thomson@commscope.com]
Sent: Wednesday, March 16, 2011 08:30 PM
To: geopriv@ietf.org <geopriv@ietf.org>; draft-marshall-geopriv-location-transform@tools.ietf.org <draft-marshall-geopriv-location-transform@tools.ietf.org>
Subject: draft-marshall-geopriv-location-transform-00

This new attempt on the old idea is a good sign that the authors are intent on getting this right. I like that.

At this stage, there isn't a really enough detail to properly assess the draft.

I think that the basic model that is hinted at in Section 8 could be structured differently. The current suggestion has several points of articulation. Civic has a range of profiles, which is probably only one layer; but geodetic locations have both CRS and shape. That leads to a plethora of transformations when all combinations are considered.

When each is combined, both input and output of the transformation need to be described with a subset of: location type, civic address profile, civic address language, geographic CRS, geodetic shape, and anything else that is later added.

Rather than specify a whole range of x-to-y transforms, in all the combinatorial glory that implies, this could be made quite simple. The service accepts a location and a description of the location that is desired. The service either produces the desired form, or an error. The error can indicate that the target form is not supported, or that the input form is not one of those that are supported for the output form (or the range of other errors specific to the transformation). In either case, the service might be able to describe the forms that it desires.

That all assumes that you are using a request-response model for the protocol, which would seem to be the case, but that detail is absent. I can think of other models, some of which could have advantages. For instance, if you could imagine using REST and even HTTP content negotiation for the transformed object, it might work, particularly when you are talking about producing civic addresses, which might be manifested as discrete resources.

--Martin

p.s. I was surprised to see that James is now working for TCS..., or not.

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] draft-marshall-geopriv-location-transform-00

This new attempt on the old idea is a good sign that the authors are intent on getting this right. I like that.

At this stage, there isn't a really enough detail to properly assess the draft.

I think that the basic model that is hinted at in Section 8 could be structured differently. The current suggestion has several points of articulation. Civic has a range of profiles, which is probably only one layer; but geodetic locations have both CRS and shape. That leads to a plethora of transformations when all combinations are considered.

When each is combined, both input and output of the transformation need to be described with a subset of: location type, civic address profile, civic address language, geographic CRS, geodetic shape, and anything else that is later added.

Rather than specify a whole range of x-to-y transforms, in all the combinatorial glory that implies, this could be made quite simple. The service accepts a location and a description of the location that is desired. The service either produces the desired form, or an error. The error can indicate that the target form is not supported, or that the input form is not one of those that are supported for the output form (or the range of other errors specific to the transformation). In either case, the service might be able to describe the forms that it desires.

That all assumes that you are using a request-response model for the protocol, which would seem to be the case, but that detail is absent. I can think of other models, some of which could have advantages. For instance, if you could imagine using REST and even HTTP content negotiation for the transformed object, it might work, particularly when you are talking about producing civic addresses, which might be manifested as discrete resources.

--Martin

p.s. I was surprised to see that James is now working for TCS..., or not.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] I-D Action:draft-ietf-geopriv-policy-23.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 : Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information
Author(s) : H. Schulzrinne, et al.
Filename : draft-ietf-geopriv-policy-23.txt
Pages : 48
Date : 2011-03-14

This document defines an authorization policy language for
controlling access to location information. It extends the Common
Policy authorization framework to provide location-specific access
control. More specifically, this document defines condition elements
specific to location information in order to restrict access based on
the current location of the Target.

Furthermore, this document defines two algorithms for reducing the
granularity of returned location information. The first algorithm is
defined for usage with civic location information while the other one
applies to geodetic location information. Both algorithms come with
limitations, i.e. they provide location obfuscation under certain
conditions and may therefore not be appropriate for all application
domains.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-23.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] Protocol Action: 'An Architecture for Location and Location Privacy in Internet Applications' to BCP (draft-ietf-geopriv-arch-03.txt)

The IESG has approved the following document:
- 'An Architecture for Location and Location Privacy in Internet
Applications'
(draft-ietf-geopriv-arch-03.txt) as a BCP

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

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-geopriv-arch/

Technical Summary

This document describes an architecture for privacy-preserving
location-based services in the Internet, focusing on authorization,
security, and privacy requirements for the data formats and protocols used
by these services. It updates RFCs 3693 and 3694, the GEOPRIV Requirements
and Threat Analysis, to reflect current WG thinking and terminology usage.

Working Group Summary

As location-based services have proliferated, the WG has found the need
for a single document that clearly articulates the GEOPRIV architecture
and terminology. This document was drafted to suit that need, and the
process of revising it allowed the WG as a whole to crystallize its
thinking about the architecture in practice and how terminology has
changed since the WG's early days.

Note that the chairs are the document editors and one of the chairs is
acting as shepherd. The ADs called consensus during the working group's
last call. The discussion during that last call was not controversial.

Document Quality

This document has received significant review by many members of the
GEOPRIV working group and has been discussed in the ECRIT working group.

Personnel

Alissa Cooper is the document shepherd.
Robert Sparks is the responsible AD.

RFC Editor Note

(applies to -03)

Please add the following two paragraphs to section 4.2.4 just after the description of the example LO override policy and before the paragraph that begins "Different policies may be applicable in different scenarios.":

<NEW>
The default combination policy for an LS that receives multiple rule sets is to combine them according to procedures in Section 10 of RFC 4745 [RFC4745]. Privacy rules always grant access, i.e., the default is to deny access and rules specify conditions under which access is allowed. Thus, when an LS is provided more than one policy document that applies to a given LO, it has been instructed to provide access when any of the rules apply. That is, the "Union" policy is the default policy for a LS with multiple sources of policy. An LS MAY choose to apply a more restrictive policy by ignoring some of the grants of permission in the privacy rules provided. The "Intersection" and "Override" policies above are of this latter character.

Protocols that are used for managing rules should allow an RM to retrieve from the LS the set of rules that will ultimately be applied. For example, in the basic HTTP-based protocol defined in [I-D.ietf-geopriv-policy-uri], an RM can use a GET request to retrieve the policy being applied by the LS and a PUT request to specify new rules.
</NEW>

Please correct the following nits (identified by Francis Dupont, GENART reviewer)

The acronyms LR and LO should be read as letters, hence "an LR" and "an LO" should be used
consistently throughout.

Section 1.3, page 6: delete the word "siloed"

Section 2.2 page 10: Recpients -> Recipients

Section 3.1.1 page 15: alamanac -> almanac

Section 3.2.4 page 22: trused -> trusted

Section 4 page 24: the LO need -> needs

Section 4 page 26: entites -> entities and undesireable -> undesirable

Section 4 page 26: confidentility -> confidentiality

Section 5.2 page 29: mutually untrusting components -> components that do not trust each other

Section 6 page 34 (LO): latitiude -> latitude
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] I-D Action:draft-ietf-geopriv-res-gw-lis-discovery-01.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-01.txt
Pages : 19
Date : 2011-03-14

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-01.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] draft -res-gw-lis-discovery updated to -01

An update to draft-geopriv-gw-lis-discovery has just been posted, diffs at:

<http://tools.ietf.org/rfcdiff?url2=draft-ietf-geopriv-res-gw-lis-discovery-01.txt>

The primary changes are:

- removed section describing use by third parties

- expanded text on use of the process with private address space

- addition of /56 to the IPv6 query list, since it's expected to

  be a common assignment size

Ray

[Geopriv] RFC 6155 on Use of Device Identity in HTTP-Enabled Location Delivery (HELD)

A new Request for Comments is now available in online RFC libraries.

RFC 6155

Title: Use of Device Identity in
HTTP-Enabled Location Delivery (HELD)
Author: J. Winterbottom, M. Thomson,
H. Tschofenig, R. Barnes
Status: Standards Track
Stream: IETF
Date: March 2011
Mailbox: james.winterbottom@andrew.com,
martin.thomson@andrew.com,
Hannes.Tschofenig@gmx.net, rbarnes@bbn.com
Pages: 27
Characters: 58542
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-geopriv-held-identity-extensions-06.txt

URL: http://www.rfc-editor.org/rfc/rfc6155.txt

When a Location Information Server receives a request for location
information (using the locationRequest message), described in the
base HTTP-Enabled Location Delivery (HELD) specification, it uses the
source IP address of the arriving message as a pointer to the
location determination process. This is sufficient in environments
where the location of a Device can be determined based on its IP
address.

Two additional use cases are addressed by this document. In the
first, location configuration requires additional or alternative
identifiers from the source IP address provided in the request. In
the second, an entity other than the Device requests the location of
the Device.

This document extends the HELD protocol to allow the location request
message to carry Device identifiers. Privacy and security
considerations describe the conditions where requests containing
identifiers are permitted. [STANDARDS-TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements. Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
http://www.ietf.org/mailman/listinfo/ietf-announce
http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

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

[Geopriv] draft -measurements updated to -03

I've just posted an update to the -measurements draft.

I realized that I'd already found useful references for most of the measurements, which was the major shortcoming identified for -identity. This version includes updated references for measurements, though it was only the cellular stuff that was lacking in this regard, the other measurements are (in my opinion) adequately referenced.

Diff here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-geopriv-held-measurements-03.txt
Though the changes to xml2rfc mean that there are lots of differences in whitespace highlighted in the document.

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

[Geopriv] I-D Action:draft-ietf-geopriv-held-measurements-03.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 : Using Device-provided Location-Related Measurements in Location Configuration Protocols
Author(s) : M. Thomson, J. Winterbottom
Filename : draft-ietf-geopriv-held-measurements-03.txt
Pages : 74
Date : 2011-03-10

A method is described by which a Device is able to provide location-
related measurement data to a LIS within a request for location
information. Location-related measurement information are
observations concerning properties related to the position of a
Device, which could be data about network attachment or about the
physical environment. When a LIS generates location information for
a Device, information from the Device can improve the accuracy of the
location estimate. A basic set of location-related measurements are
defined, including common modes of network attachment as well as
assisted Global Navigation Satellite System (GNSS) parameters.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-held-measurements-03.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] I-D Action:draft-ietf-geopriv-local-civic-01.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 : Specifying Civic Address Extensions in PIDF-LO
Author(s) : J. Winterbottom, et al.
Filename : draft-ietf-geopriv-local-civic-01.txt
Pages : 17
Date : 2011-03-10

New fields are occasionally added to civic addresses. A backwardly-
compatible mechanism for adding civic address elements to the Geopriv
civic address format is described. A formal mechanism for handling
unsupported extensions when translating between XML and DHCP civic
address forms is defined for entities that need to perform this
translation. Intial extensions for some new elements are also
defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-local-civic-01.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] local-civic registry management policy

Yes, that is correct. The type is only a column in the registry and the SHOULD IMPLEMENT statement for Type A. There is no other significance to Type.

Note that the Type column in the registry would start with all 5139 tags defined as Type A.

I am not suggesting two registries. This document would rework the existing CAtypes registry. My proposed change would add one more column to that registry containing "A" or "B".

I am not suggesting any changes to encoding.

Brian

On Mar 9, 2011, at 1:00 AM, Winterbottom, James wrote:

> I think you may be talking past each other a bit here.
>
> I think Brian is saying that the XML and DHCP encodings we have in the document are fine as is, and that his Type-As and Type-Bs are encoded exactly the same way. The only difference is that every implementation SHOULD be expected to understand everything in 5139 + any Type-As that find their way into the new registry.
>
> Is this right Brian?
>
> Cheers
> James
>
>
>
>
>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
>> Of Thomson, Martin
>> Sent: Wednesday, 9 March 2011 2:28 PM
>> To: Brian Rosen
>> Cc: geopriv@ietf.org WG
>> Subject: Re: [Geopriv] local-civic registry management policy
>>
>> On 2011-03-09 at 12:42:34, Brian Rosen wrote:
>>> I'm not following the "convert" issue. Who is converting what?
>>
>> You are pulling my leg, right?
>>
>> Conversion between DHCP and XML formats was crucial in reaching the
>> current solution. Without that particular wrinkle, we wouldn't even have
>> this draft.
>> _______________________________________________
>> 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] local-civic registry management policy

I think you may be talking past each other a bit here.

I think Brian is saying that the XML and DHCP encodings we have in the document are fine as is, and that his Type-As and Type-Bs are encoded exactly the same way. The only difference is that every implementation SHOULD be expected to understand everything in 5139 + any Type-As that find their way into the new registry.

Is this right Brian?

Cheers
James

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
> Of Thomson, Martin
> Sent: Wednesday, 9 March 2011 2:28 PM
> To: Brian Rosen
> Cc: geopriv@ietf.org WG
> Subject: Re: [Geopriv] local-civic registry management policy
>
> On 2011-03-09 at 12:42:34, Brian Rosen wrote:
> > I'm not following the "convert" issue. Who is converting what?
>
> You are pulling my leg, right?
>
> Conversion between DHCP and XML formats was crucial in reaching the
> current solution. Without that particular wrinkle, we wouldn't even have
> this draft.
> _______________________________________________
> 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] local-civic registry management policy

On 2011-03-09 at 12:42:34, Brian Rosen wrote:
> I'm not following the "convert" issue. Who is converting what?

You are pulling my leg, right?

Conversion between DHCP and XML formats was crucial in reaching the current solution. Without that particular wrinkle, we wouldn't even have this draft.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] local-civic registry management policy

You can always re-register with an RFC to upgrade to Type A. You don't need to change the namespace to do that. IANA would simply change the reference and the type value, fully backwards compatible.

We could say that explicitly if you like.

There is no interoperability issue with two types. The ONLY functional difference is the SHOULD IMPLEMENT. That doesn't create interop problems.

The judgement is the IETFs (PS RFC), not IANAs.

I'm not following the "convert" issue. Who is converting what?

Brian

On Mar 8, 2011, at 6:02 PM, Thomson, Martin wrote:

> OK, so you DO want to re-run the arguments.
>
> Having two types of registry is more harmful to interoperability.
>
> On 2011-03-09 at 09:37:46, Brian Rosen wrote:
>> There is only one registry. There are two types of registrations. The
>> only difference is the level of scrutiny. The functional difference
>> is SHOULD IMPLEMENT Type A.
>
> Whether or not something should be implemented is not a judgment that we (or IANA) either need or want to make. The current text doesn't make that decision necessary.
>
> Worse, if you have two classes of registration, once the decision is made it's permanent.
>
> So you have to discuss how to choose which applies for a particular registration. For instance, your "Type A" doesn't convert properly unless it is understood by the converter.
>
> --Martin

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

Re: [Geopriv] local-civic registry management policy

OK, so you DO want to re-run the arguments.

Having two types of registry is more harmful to interoperability.

On 2011-03-09 at 09:37:46, Brian Rosen wrote:
> There is only one registry. There are two types of registrations. The
> only difference is the level of scrutiny. The functional difference
> is SHOULD IMPLEMENT Type A.

Whether or not something should be implemented is not a judgment that we (or IANA) either need or want to make. The current text doesn't make that decision necessary.

Worse, if you have two classes of registration, once the decision is made it's permanent.

So you have to discuss how to choose which applies for a particular registration. For instance, your "Type A" doesn't convert properly unless it is understood by the converter.

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

Re: [Geopriv] local-civic registry management policy

There is only one registry. There are two types of registrations. The only difference is the level of scrutiny. The functional difference is SHOULD IMPLEMENT Type A.

If you don't do this, then a large class of civic locations won't be able to be handled by most clients. A good example is the prefix fields. There are many countries where there is some alpha numeric prefix before the numeric house number. If most clients can't handle that, all of those addresses won't be correctly located.

On the other hand, the bridge ID is an example of the Type B registrations. We only care about uniqueness. Implementation will be specific for the use case.

Brian

On Mar 8, 2011, at 5:10 PM, Winterbottom, James wrote:

> +1 to this.
>
> I thought that we had got agreement on a single registry and what was required for this. I see no benefit in a secondary registry.
>
> Cheers
> James
>
>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
>> Of Thomson, Martin
>> Sent: Wednesday, 9 March 2011 8:51 AM
>> To: Brian Rosen; Ted Hardie
>> Cc: geopriv@ietf.org WG
>> Subject: Re: [Geopriv] local-civic registry management policy
>>
>> This proposal fundamentally changes the mechanism in the draft.
>>
>> If you want to re-open the discussion, then I guess that's fair game. I'm
>> against it.
>>
>> --Martin
>>
>> On 2011-03-09 at 02:08:43, Brian Rosen wrote:
>>> Somewhere before this section:
>>>
>>> New CAtypes have a myriad of uses. This document classifies usage
>>> into two classes:
>>> Type A: CAtypes that are more widely used to encode civic addresses,
>>> and most clients should be able to use the extension
>>>
>>> Type B: CAtypes that are special purpose, and both the client and
>>> server have to be constructed specifically for the use case the
>>> extension was designed for, and consequently relatively few clients
>>> will be able to use the extension CAtype
>>>
>>> The CAtypes defined in [RFC4119] and [RFC5139] are examples of Type A
>>> CAtypes.
>>>
>>> The CAtypes registry is modified by this document to contain an
>>> indication of which type of extension CAtype the entry is. All
>>> clients implementing PIDF-LO SHOULD implement all Type A extension
>>> CAtypes, recognizing that a newly defined Type A extension CAtype
>>> marked may not be implemented by a client until that client is updated
>>> and some clients may be constructed for special purposes where it is
>>> known that a Type A CAtype will not be encountered.
>>>
>>>
>>> In this section, replace the text noted with:
>>>
>>> The CAtypes registry is altered to so that it's management policy
>>> [RFC5226] for Type A registrations (see Section [?]) is "Standards
>>> Action". If a Type A registration is made, the specification column
>>> in the registry will contain a reference to an RFC.
>>>
>>>
>>> Type B registrations require "Expert Review". A specification is
>>> optional. If it is provided, it must meet the rules for
>>> "Specification Required".
>>>
>>> Registrations requests to IANA for this registry must specify whether
>>> a Type A or Type B registration is desired. All entries presently in
>>> the registry are Type A.
>>>
>>>
>>>
>>>
>>> On Mar 7, 2011, at 5:43 PM, Ted Hardie wrote:
>>>
>>>> Hi Brian,
>>>>
>>>> Forgive the top posting, but I'd like to encourage you to go ahead
>>> and
>>>> post suggested language. It's hard for me to parse how what you
>>>> discuss below would fit into the document, and exact language would
>>>> improve that a good bit.
>>>>
>>>> thanks,
>>>>
>>>> Ted
>>>>
>>>> On Mon, Mar 7, 2011 at 12:36 PM, Brian Rosen <br@brianrosen.net>
>>> wrote:
>>>>> In -local-civic, the text on registration currently states:
>>>>> The "CAtypes" registry is altered to operate on a registration
>>> policy
>>>>> of "Expert Review", and optionally "Specification Required"
>>>>> [RFC5226].
>>>>>
>>>>> The registration rules for "Specification Required" are followed
>>> only
>>>>> if a registration includes a reference to a specification.
>>>>> Registrations can be made without a specification reference.
>>>>>
>>>>>
>>>>> I think this came about because of my yammering about two different
>>> kinds of extensions:
>>>>> 1) Truly local extensions, where an app has to be created
>>>>> specifically around the use case and the extension. These are more
>>>>> special purpose applications
>>>>> 2) Generally applicable extensions that are used relatively widely,
>>>>> and for which most implementations should be able to use them
>>>>>
>>>>> We expect, for example, that any implementation of civic address
>>> would be able to handle ALL of the CAtypes in the current registry,
>>> and implementors of a location source can reasonably expect that a
>>> PIDF containing any or all of these elements would work.
>>>>>
>>>>> I posit that we haven't had enough countries writing their civic
>>> address encodings as recommended in 5774, and we will find some
>>> additional elements like Street Type Prefix, and Lamp Post, which are
>>> more commonly used.
>>>>>
>>>>> What I would like to see is two ways to add a new element to the
>>> registry: one which is basically FCFS, expert review to avoid
>>> duplicates, and the other is specification required, expert review for
>>> general applicability. We would the say that all implementations
>>> SHOULD be able to correctly handle any of the latter elements, just
>>> like they handle the elements now in 5139.
>>>>>
>>>>> The definition of the registry in the current draft of local-civic
>>> is okay, the working of Management Policy is what I want to change.
>>>>>
>>>>> I will propose exact wording for this section if this
>>> differentiation makes sense.
>>>>>
>>>>> Brian
>>>>>
>>>>> _______________________________________________
>>>>> 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] local-civic registry management policy

+1 to this.

I thought that we had got agreement on a single registry and what was required for this. I see no benefit in a secondary registry.

Cheers
James

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
> Of Thomson, Martin
> Sent: Wednesday, 9 March 2011 8:51 AM
> To: Brian Rosen; Ted Hardie
> Cc: geopriv@ietf.org WG
> Subject: Re: [Geopriv] local-civic registry management policy
>
> This proposal fundamentally changes the mechanism in the draft.
>
> If you want to re-open the discussion, then I guess that's fair game. I'm
> against it.
>
> --Martin
>
> On 2011-03-09 at 02:08:43, Brian Rosen wrote:
> > Somewhere before this section:
> >
> > New CAtypes have a myriad of uses. This document classifies usage
> > into two classes:
> > Type A: CAtypes that are more widely used to encode civic addresses,
> > and most clients should be able to use the extension
> >
> > Type B: CAtypes that are special purpose, and both the client and
> > server have to be constructed specifically for the use case the
> > extension was designed for, and consequently relatively few clients
> > will be able to use the extension CAtype
> >
> > The CAtypes defined in [RFC4119] and [RFC5139] are examples of Type A
> > CAtypes.
> >
> > The CAtypes registry is modified by this document to contain an
> > indication of which type of extension CAtype the entry is. All
> > clients implementing PIDF-LO SHOULD implement all Type A extension
> > CAtypes, recognizing that a newly defined Type A extension CAtype
> > marked may not be implemented by a client until that client is updated
> > and some clients may be constructed for special purposes where it is
> > known that a Type A CAtype will not be encountered.
> >
> >
> > In this section, replace the text noted with:
> >
> > The CAtypes registry is altered to so that it's management policy
> > [RFC5226] for Type A registrations (see Section [?]) is "Standards
> > Action". If a Type A registration is made, the specification column
> > in the registry will contain a reference to an RFC.
> >
> >
> > Type B registrations require "Expert Review". A specification is
> > optional. If it is provided, it must meet the rules for
> > "Specification Required".
> >
> > Registrations requests to IANA for this registry must specify whether
> > a Type A or Type B registration is desired. All entries presently in
> > the registry are Type A.
> >
> >
> >
> >
> > On Mar 7, 2011, at 5:43 PM, Ted Hardie wrote:
> >
> > > Hi Brian,
> > >
> > > Forgive the top posting, but I'd like to encourage you to go ahead
> > and
> > > post suggested language. It's hard for me to parse how what you
> > > discuss below would fit into the document, and exact language would
> > > improve that a good bit.
> > >
> > > thanks,
> > >
> > > Ted
> > >
> > > On Mon, Mar 7, 2011 at 12:36 PM, Brian Rosen <br@brianrosen.net>
> > wrote:
> > >> In -local-civic, the text on registration currently states:
> > >> The "CAtypes" registry is altered to operate on a registration
> > policy
> > >> of "Expert Review", and optionally "Specification Required"
> > >> [RFC5226].
> > >>
> > >> The registration rules for "Specification Required" are followed
> > only
> > >> if a registration includes a reference to a specification.
> > >> Registrations can be made without a specification reference.
> > >>
> > >>
> > >> I think this came about because of my yammering about two different
> > kinds of extensions:
> > >> 1) Truly local extensions, where an app has to be created
> > >> specifically around the use case and the extension. These are more
> > >> special purpose applications
> > >> 2) Generally applicable extensions that are used relatively widely,
> > >> and for which most implementations should be able to use them
> > >>
> > >> We expect, for example, that any implementation of civic address
> > would be able to handle ALL of the CAtypes in the current registry,
> > and implementors of a location source can reasonably expect that a
> > PIDF containing any or all of these elements would work.
> > >>
> > >> I posit that we haven't had enough countries writing their civic
> > address encodings as recommended in 5774, and we will find some
> > additional elements like Street Type Prefix, and Lamp Post, which are
> > more commonly used.
> > >>
> > >> What I would like to see is two ways to add a new element to the
> > registry: one which is basically FCFS, expert review to avoid
> > duplicates, and the other is specification required, expert review for
> > general applicability. We would the say that all implementations
> > SHOULD be able to correctly handle any of the latter elements, just
> > like they handle the elements now in 5139.
> > >>
> > >> The definition of the registry in the current draft of local-civic
> > is okay, the working of Management Policy is what I want to change.
> > >>
> > >> I will propose exact wording for this section if this
> > differentiation makes sense.
> > >>
> > >> Brian
> > >>
> > >> _______________________________________________
> > >> 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] local-civic registry management policy

This proposal fundamentally changes the mechanism in the draft.

If you want to re-open the discussion, then I guess that's fair game. I'm against it.

--Martin

On 2011-03-09 at 02:08:43, Brian Rosen wrote:
> Somewhere before this section:
>
> New CAtypes have a myriad of uses. This document classifies usage
> into two classes:
> Type A: CAtypes that are more widely used to encode civic addresses,
> and most clients should be able to use the extension
>
> Type B: CAtypes that are special purpose, and both the client and
> server have to be constructed specifically for the use case the
> extension was designed for, and consequently relatively few clients
> will be able to use the extension CAtype
>
> The CAtypes defined in [RFC4119] and [RFC5139] are examples of Type A
> CAtypes.
>
> The CAtypes registry is modified by this document to contain an
> indication of which type of extension CAtype the entry is. All
> clients implementing PIDF-LO SHOULD implement all Type A extension
> CAtypes, recognizing that a newly defined Type A extension CAtype
> marked may not be implemented by a client until that client is updated
> and some clients may be constructed for special purposes where it is
> known that a Type A CAtype will not be encountered.
>
>
> In this section, replace the text noted with:
>
> The CAtypes registry is altered to so that it's management policy
> [RFC5226] for Type A registrations (see Section [?]) is "Standards
> Action". If a Type A registration is made, the specification column
> in the registry will contain a reference to an RFC.
>
>
> Type B registrations require "Expert Review". A specification is
> optional. If it is provided, it must meet the rules for
> "Specification Required".
>
> Registrations requests to IANA for this registry must specify whether
> a Type A or Type B registration is desired. All entries presently in
> the registry are Type A.
>
>
>
>
> On Mar 7, 2011, at 5:43 PM, Ted Hardie wrote:
>
> > Hi Brian,
> >
> > Forgive the top posting, but I'd like to encourage you to go ahead
> and
> > post suggested language. It's hard for me to parse how what you
> > discuss below would fit into the document, and exact language would
> > improve that a good bit.
> >
> > thanks,
> >
> > Ted
> >
> > On Mon, Mar 7, 2011 at 12:36 PM, Brian Rosen <br@brianrosen.net>
> wrote:
> >> In -local-civic, the text on registration currently states:
> >> The "CAtypes" registry is altered to operate on a registration
> policy
> >> of "Expert Review", and optionally "Specification Required"
> >> [RFC5226].
> >>
> >> The registration rules for "Specification Required" are followed
> only
> >> if a registration includes a reference to a specification.
> >> Registrations can be made without a specification reference.
> >>
> >>
> >> I think this came about because of my yammering about two different
> kinds of extensions:
> >> 1) Truly local extensions, where an app has to be created
> >> specifically around the use case and the extension. These are more
> >> special purpose applications
> >> 2) Generally applicable extensions that are used relatively widely,
> >> and for which most implementations should be able to use them
> >>
> >> We expect, for example, that any implementation of civic address
> would be able to handle ALL of the CAtypes in the current registry,
> and implementors of a location source can reasonably expect that a
> PIDF containing any or all of these elements would work.
> >>
> >> I posit that we haven't had enough countries writing their civic
> address encodings as recommended in 5774, and we will find some
> additional elements like Street Type Prefix, and Lamp Post, which are
> more commonly used.
> >>
> >> What I would like to see is two ways to add a new element to the
> registry: one which is basically FCFS, expert review to avoid
> duplicates, and the other is specification required, expert review for
> general applicability. We would the say that all implementations
> SHOULD be able to correctly handle any of the latter elements, just
> like they handle the elements now in 5139.
> >>
> >> The definition of the registry in the current draft of local-civic
> is okay, the working of Management Policy is what I want to change.
> >>
> >> I will propose exact wording for this section if this
> differentiation makes sense.
> >>
> >> Brian
> >>
> >> _______________________________________________
> >> 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] local-civic registry management policy

Somewhere before this section:

New CAtypes have a myriad of uses. This document classifies usage into two classes:
Type A: CAtypes that are more widely used to encode civic addresses, and most clients should be able to use the extension

Type B: CAtypes that are special purpose, and both the client and server have to be constructed specifically for the use case the extension was designed for, and consequently relatively few clients will be able to use the extension CAtype

The CAtypes defined in [RFC4119] and [RFC5139] are examples of Type A CAtypes.

The CAtypes registry is modified by this document to contain an indication of which type of extension CAtype the entry is. All clients implementing PIDF-LO SHOULD implement all Type A extension CAtypes, recognizing that a newly defined Type A extension CAtype marked may not be implemented by a client until that client is updated and some clients may be constructed for special purposes where it is known that a Type A CAtype will not be encountered.

In this section, replace the text noted with:

The CAtypes registry is altered to so that it's management policy [RFC5226] for Type A registrations (see Section [?]) is "Standards Action". If a Type A registration is made, the specification column in the registry will contain a reference to an RFC.

Type B registrations require "Expert Review". A specification is optional. If it is provided, it must meet the rules for "Specification Required".

Registrations requests to IANA for this registry must specify whether a Type A or Type B registration is desired. All entries presently in the registry are Type A.

On Mar 7, 2011, at 5:43 PM, Ted Hardie wrote:

> Hi Brian,
>
> Forgive the top posting, but I'd like to encourage you to go ahead and
> post suggested language. It's hard for me to parse how what you
> discuss below would fit into the document, and exact language would
> improve that a good bit.
>
> thanks,
>
> Ted
>
> On Mon, Mar 7, 2011 at 12:36 PM, Brian Rosen <br@brianrosen.net> wrote:
>> In -local-civic, the text on registration currently states:
>> The "CAtypes" registry is altered to operate on a registration policy
>> of "Expert Review", and optionally "Specification Required"
>> [RFC5226].
>>
>> The registration rules for "Specification Required" are followed only
>> if a registration includes a reference to a specification.
>> Registrations can be made without a specification reference.
>>
>>
>> I think this came about because of my yammering about two different kinds of extensions:
>> 1) Truly local extensions, where an app has to be created specifically around the use case and the extension. These are more special purpose applications
>> 2) Generally applicable extensions that are used relatively widely, and for which most implementations should be able to use them
>>
>> We expect, for example, that any implementation of civic address would be able to handle ALL of the CAtypes in the current registry, and implementors of a location source can reasonably expect that a PIDF containing any or all of these elements would work.
>>
>> I posit that we haven't had enough countries writing their civic address encodings as recommended in 5774, and we will find some additional elements like Street Type Prefix, and Lamp Post, which are more commonly used.
>>
>> What I would like to see is two ways to add a new element to the registry: one which is basically FCFS, expert review to avoid duplicates, and the other is specification required, expert review for general applicability. We would the say that all implementations SHOULD be able to correctly handle any of the latter elements, just like they handle the elements now in 5139.
>>
>> The definition of the registry in the current draft of local-civic is okay, the working of Management Policy is what I want to change.
>>
>> I will propose exact wording for this section if this differentiation makes sense.
>>
>> Brian
>>
>> _______________________________________________
>> 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] local-civic registry management policy

Hi Brian,

Forgive the top posting, but I'd like to encourage you to go ahead and
post suggested language. It's hard for me to parse how what you
discuss below would fit into the document, and exact language would
improve that a good bit.

thanks,

Ted

On Mon, Mar 7, 2011 at 12:36 PM, Brian Rosen <br@brianrosen.net> wrote:
> In -local-civic, the text on registration currently states:
>   The "CAtypes" registry is altered to operate on a registration policy
>   of "Expert Review", and optionally "Specification Required"
>   [RFC5226].
>
>   The registration rules for "Specification Required" are followed only
>   if a registration includes a reference to a specification.
>   Registrations can be made without a specification reference.
>
>
> I think this came about because of my yammering about two different kinds of extensions:
> 1) Truly local extensions, where an app has to be created specifically around the use case and the extension.  These are more special purpose applications
> 2) Generally applicable extensions that are used relatively widely, and for which most implementations should be able to use them
>
> We expect, for example, that any implementation of civic address would be able to handle ALL of the CAtypes in the current registry, and implementors of a location source can reasonably expect that a PIDF containing any or all of these elements would work.
>
> I posit that we haven't had enough countries writing their civic address encodings as recommended in 5774, and we will find some additional elements like Street Type Prefix, and Lamp Post, which are more commonly used.
>
> What I would like to see is two ways to add a new element to the registry: one which is basically FCFS, expert review to avoid duplicates, and the other is specification required, expert review for general applicability.  We would the say that all implementations SHOULD be able to correctly handle any of the latter elements, just like they handle the elements now in 5139.
>
> The definition of the registry in the current draft of local-civic is okay, the working of Management Policy is what I want to change.
>
> I will propose exact wording for this section if this differentiation makes sense.
>
> Brian
>
> _______________________________________________
> 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] local-civic registry management policy

In -local-civic, the text on registration currently states:
The "CAtypes" registry is altered to operate on a registration policy
of "Expert Review", and optionally "Specification Required"
[RFC5226].

The registration rules for "Specification Required" are followed only
if a registration includes a reference to a specification.
Registrations can be made without a specification reference.

I think this came about because of my yammering about two different kinds of extensions:
1) Truly local extensions, where an app has to be created specifically around the use case and the extension. These are more special purpose applications
2) Generally applicable extensions that are used relatively widely, and for which most implementations should be able to use them

We expect, for example, that any implementation of civic address would be able to handle ALL of the CAtypes in the current registry, and implementors of a location source can reasonably expect that a PIDF containing any or all of these elements would work.

I posit that we haven't had enough countries writing their civic address encodings as recommended in 5774, and we will find some additional elements like Street Type Prefix, and Lamp Post, which are more commonly used.

What I would like to see is two ways to add a new element to the registry: one which is basically FCFS, expert review to avoid duplicates, and the other is specification required, expert review for general applicability. We would the say that all implementations SHOULD be able to correctly handle any of the latter elements, just like they handle the elements now in 5139.

The definition of the registry in the current draft of local-civic is okay, the working of Management Policy is what I want to change.

I will propose exact wording for this section if this differentiation makes sense.

Brian

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