Sounds good to me! Thanks, --Richard On Aug 16, 2011, at 8:53 PM, Terry Manderson wrote: > 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