Hi all In the Legal Review it seems to assume that for assignments "that are reasonably assumed to be related to one individual user", that user is a natural person. A /32 can be a business.
There is a suggestion to allow geofeed for registrations over a certain size. What is the implication of this suggestion? Will the update software only allow the "geofeed:" attribute in the larger assignment objects? The update software is not going to validate the contents of the referenced URL. So a "geofeed:" attribute on a /24 (or larger) assignment object may reference a URL that contains geolocation data relating to a more specific /32. So are we saying the legal review is offering 'guidance' to resource holders not to include geolocation data for assignments smaller than /24, but the responsibility/liability is on the resource holder? I can see the logical argument behind the legal comment, but I don't see the practicality of monitoring or enforcement of this argument. cheers denis co-chair DB-WG On Fri, 12 Nov 2021 at 12:37, Edward Shryane via db-wg <[email protected]> wrote: > > Dear Colleagues, > > Following is an updated impact analysis for the implementation of the > "geofeed:" attribute in the RIPE database, which now also includes the Legal > analysis. I will also update the NWI page. > > The DB team are now working on the implementation, which will be included in > the next Whois release. > > Please reply with any feedback. > > Regards > Ed Shryane > RIPE NCC > > > Impact Analysis for Implementing the "geofeed:" Attribute > ============================================================ > > "geoloc:" Attribute > ---------------------- > Implementing the "geofeed:" attribute does not affect the "geoloc:" > attribute. No decision has been taken on the future of the "geoloc:" > attribute, a review can be done at a later date. > > "remarks:" Attribute > ----------------------- > Existing "remarks:" attributes in INETNUM or INET6NUM object types containing > a "geofeed: url" value will not be automatically converted to a "geofeed:" > attribute. > > The implementation will validate that an INETNUM or INET6NUM object may > contain at most a single geofeed reference, either a "remarks:" attribute > *or* a "geofeed:" attribute. More than one will result in an error on update. > > Any "remarks:" attributes in other object types will not be validated for > geofeed references. > > "geofeed:" Attribute > ----------------------- > The "geofeed:" attribute will be added to the INETNUM and INET6NUM object > types. It will be an optional, singly occurring attribute. > > The attribute value must consist only of a well-formed URL. Any other content > in the attribute value will result in a syntax error. > > "geofeed:" URL > ----------------- > The URL in the "geofeed:" attribute will be validated that it is well-formed > (i.e. syntactically correct). > > The URL must use the ASCII character set only (in the RIPE database, > non-Latin-1 characters will be substituted with a '?' character). > > Non-ASCII characters in the URL host name must be converted to ASCII using > Punycode in advance (before updating the RIPE database). > > Non-ASCII characters in the URL path must be converted using Percent-encoding > in advance. > > Only the HTTPS protocol is supported in the URL, otherwise an error is > returned. > > The reachability of the URL will not be checked. The content of the URL will > not be validated. > > Database dump and Split files > ---------------------------------- > The "geofeed:" attribute will be included in the nightly database dump and > split files. > > NRTM > -------- > The "geofeed:" attribute will be included in INETNUM and INET6NUM objects in > the NRTM stream. > > Whois Queries > ----------------- > The "geofeed:" attribute will appear by default in (filtered) INETNUM and > INET6NUM objects in Whois query responses, no additional query flag will be > needed. > > RDAP > ------------- > The "geofeed:" attribute will not appear in RDAP responses. A separate RDAP > profile will be needed to extend the response format to include geofeed. This > can be implemented at a later date. > > Documentation > --------------- > The RIPE database documentation will be updated, including the inet(6)num > object templates and attribute description (with a reference to the IETF > draft document). > > Other RIRs > ------------- > There is currently no coordinated plan to implement "geofeed:" across > regions. Other RIRs may implement "geofeed:" at a later date. > > Legal Review > --------------- > > From a legal point of view, the concern is whether the geofeed attribute can > be considered to be personal data, in which case the General Data Protection > Regulation (GDPR) will be applicable for its processing (according to GDPR > (Art 4(1)), "personal data are any information which are related to an > identified or identifiable natural person”). > > We understand that the purpose of the proposal to add the geofeed attribute > in the RIPE Database is not to identify the geolocation of individuals. > However, if the geofeed attribute is inserted for registrations of > assignments that are reasonably assumed to be related to one individual user, > then the attribute will be considered personal data. This is the case for > registrations of /32 IPv4 assignments (i.e. one IPv4 address). The same may > be considered for registrations of two or three IP addresses. > > For the geofeed attribute to not be considered personal data, it must only be > allowed to be added to registrations reasonably expected to be used by a > group of people (not an individual user). The size of such a registration may > be arguable. > > In order to be on the safe side, we suggest to allow the geofeed attribute to > registrations as follows: > - For inetnum objects, equal or larger than the minimum allocation by the > RIPE NCC, i.e. equal or larger than /24 > - For inet6num objects larger than the minimum recommended assignment to end > customer CPE devices, i.e. larger than /48 (please see here - > https://www.ripe.net/publications/docs/ripe-690#4-2--prefix-assignment-options > - “Best Current Operational Practice for Operators: IPv6 prefix assignment > for end-users - persistent vs non-persistent, and what size to choose”) > > >
