Subject: 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

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 16 Aug 2011 16:44:03 -0400

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
> [email-masked] mailing lists by 2011-08-26. Exceptionally, comments may be
> sent to [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Terry Manderson <[email-masked]>
Date: Tue, 16 Aug 2011 17:53:41 -0700

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]:

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" <[email-masked]> 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.
> 
> 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]:
> 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.
> "
> 
> 
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 16 Aug 2011 21:16:00 -0400

Sounds good to me!  Thanks,
--Richard