Hi Job, Colleagues, Firstly, apologies for the delay in finding a solution to the /48 restriction on the geofeed implementation. Our Legal team have considered the concerns from a part of the community regarding the eligible size for “geofeed:” validation and concluded the following: Since resources with prefix size equal to the size distributed/registered by the RIPE NCC to a resource holder is not considered to be personal data, an equal prefix size may receive the “geofeed:” validation. Accordingly, we will allow "geofeed:" on ALLOCATED PA or top-level ASSIGNED PI (for IPv4) and ALLOCATED-BY-RIR on top-level ASSIGNED PI (for IPv6). We will also start enforcing the same validation on "remarks: geofeed" as on "geofeed:" for consistency. Please let us know what you think. We would like to implement these changes soon and include them in a new Whois release 1.103. Regards Ed Shryane RIPE NCC
On 3 Jan 2022, at 13:36, Job Snijders via db-wg <db-wg@ripe.net> wrote:
Dear all,
Like all good netizens, I tried to align information I publish in the RIPE database to reality, but there is an obstacle:
https://sobornost.net/~job/geofeed.png
"""Adding or modifying the "geofeed:" attribute of an object with a prefix length greater or equal to 48 is not allowed."""
No such restriction exists if you use the 'remarks: Geofeed' approach, as demonstrated here:
$ whois -h whois.ripe.net 2001:67c:208c::/48 | grep Geofeed remarks: Geofeed https://sobornost.net/geofeed.csv
I appreciate concerns about privacy, but I'm not wholly convinced restricting /48s from having a proper 'geofeed:' attribute is the best path forward.
How does the working group feel about this restriction? Is it useful? Should it be lifted? If the latter, what would be the process?
Kind regards,
Job
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg