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”)