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