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 <[email protected]> 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 -- 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
