ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-grow-geomrt-04.txt> (Multi-threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) routing information export format with geo-location extensions) to Proposed Standard

2011-08-16 19:54:08
Hi Richard, 

Thanks for reading and reviewing.

There should be no rules attached to the location data in the GEOMRT format,
and as you point out there is (in MRT) no way to communicate these rule if
they were to exist.

That said, and augmenting your text only slightly, I will add the following
as a new 'Privacy Considerations' section of draft-ietf-grow-geomrt.

---

The GEOPRIV [RFC6280] architecture requires that privacy rules attached to a
location object be transmitted alongside the location information in the
object. If a BGP Collector adds location coordinates to an MRT record based
on GEOPRIV location objects, then it would have to include privacy rules as
well. Since the MRT geo-location format does support the the provision of
privacy rules, each location entry in an MRT object is assigned the
following default privacy rules [RFC4119]:

-- retransmission-allowed: True
-- retention-expires: 100 years from timestamp of the MRT object
-- ruleset-reference: Empty
-- note-well: Empty

Location information derived from a location object with more restrictive
privacy rules MUST NOT be included in a MRT geo-location record unless there
are non-technical measures in place that enforce and communicate the
constraints on the use of the location information in the MRT geo-location
format (e.g., contractual agreements between peers).

---

This supports the text in the security considerations section, but I think
it deserves its own section.

Ok with you?

Cheers
Terry

On 17/08/11 6:44 AM, "Richard L. Barnes" <rbarnes(_at_)bbn(_dot_)com> wrote:

It would be helpful to clarify the relationship between this work and other
IETF work on geolocation, namely GEOPRIV [RFC6280].  I don't think there's a
huge change required, but a simple paragraph could be helpful; suggested text
is below.

The first question is what role a geomrt router plays in the GEOPRIV system.
Given that a GeoMRT router is receiving location (somehow) from peers and
sending it back out, one could argue that it's a Location Server, and thus
needs to both (1) obey, and (2) forward any privacy rules attached to a
location object.  I wouldn't say it's a Viewer, since it's preserving the
location information as location information; I would think of a Viewer as
something that's going to use the location to do something else, like Yelp or
OpenTable, or even a location-based routing system (I hear they exist for
DTNs).

So in principle, location objects from which a geomrt router builds a geomrt
object could have rules attached that give less than full access, and in that
case, GEOPRIV would call for those rules to be sent along with the location
info in the geomrt object.

Now, there are two ways to respond to this situation:
1. Add privacy/rules fields to geomrt
2. Require that location info that feeds into a geomrt object not have rules
attached (i.e., it must be public)

ISTM that the latter approach makes more sense for this document, since this
format is largely intended for low-risk, publication-style information
sharing.  Suggested text (probably in Security Considerations):
"
The GEOPRIV architecture requires that rules attached to a location object be
transmitted alongside the location information in the object.  If a router
adds location to an MRT object based on GEOPRIV location objects, then it
would have to include rules as well.  Since the MRT geolocation format does
not include fields to carry privacy rules, each location entry in an MRT
object is assigned the following default privacy rules [RFC4119]:
-- retransmission-allowed: True
-- retention-expires: 100 years from timestamp of the MRT object
-- ruleset-reference: Empty
-- note-well: Empty
Location information derived from a location object with more restrictive
rules MUST NOT be included in an MRT object unless there are non-technical
measures in place  that enforce and communicate the constraints on the use of
the location information in the MRT object (e.g., contractual agreements
between peers).

Location information that originates from sources other than GEOPRIV location
objects (e.g., GPS chips, emails from peers) does not have the same formal
requirements, but should nonetheless be handled as potentially private
information requiring the  permission of the source before publication.
"


On Aug 12, 2011, at 11:23 AM, The IESG wrote:


The IESG has received a request from the Global Routing Operations WG
(grow) to consider the following document:
- 'Multi-threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP)
  routing information export format with geo-location extensions'
 <draft-ietf-grow-geomrt-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2011-08-26. Exceptionally, 
comments may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document updates the Multi-threaded Routing Toolkit (MRT) export
  format for Border Gateway Protocol (BGP) routing information by
  extending it to include optional terrestrial coordinates of a BGP
  Collector and its BGP Peers.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-grow-geomrt/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-grow-geomrt/


No IPR declarations have been submitted directly on this I-D.


_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf