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@xxxxxxx> 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@xxxxxxxx mailing lists by 2011-08-26. Exceptionally, comments may be >> sent to iesg@xxxxxxxx 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@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf