This seems weird, I would assume it should be greater than 48, not greater than or equal to 48. Ed, can you confirm if this is intended or not? Also I agree with Peter Hessler, you should always be able to add a geofeed attribute to all blocks assigned/allocated by the NCC. And to not make it a massive mess, if there is going to be a limit make it "not *greater than* 48" for v6 and "not *greater than* 24" for IPv4. If for some legal reason this is not an option, then I think an exception needs to be made for the top level resource allocated/assigned to the LIR/end user. -Cynthia On Mon, Jan 3, 2022 at 1:46 PM 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