[db-wg] geofeed issue: can't add geofeed attribute to PI /48

> On 20220225, at 10:20, Peter Hessler via db-wg <db-wg at ripe.net> wrote:
> 
> On 2022 Feb 25 (Fri) at 10:05:15 +0100 (+0100), Job Snijders via db-wg wrote:
> :On 2022-02-25 07:48, Peter Hessler via db-wg wrote:
> :> Alternatively, I propose we *drop* the geofeed: attribute and remove it
> :> from the database.
> :
> :Can you motivate the suggestion?
> :
> :The suggestion appears like a regression to me, we both see value in
> :“geofeed:” (provided we can actually use it), right?
> :
> 
> The motivation is if the attribute is too restricted to be useful, then
> lets not encourage a broken implementation.

The attribute is not the technical problem, it is a legal party that restricts it because of mostly unfounded concerns: if a LIR has permission of a user to publish their info, then they should be able to. If a LIR does not have permission of the end-user, then the LIR is liable when they do publish.

Noting, that anybody can provide a geofeed.csv with even up to IPv4 /32 or IPv6 /128 (so single IP) level entries...

It is just a restriction in RIPE DB in the geofeed field, but not in remarks.

Which is why the restriction is so utterly pointless.

In the same way that one can always "lie"/misrepresent in the geofeed file, or give "less accurate" details (eg. saying you are in Amsterdam, while actually being in a small village like Zoetermeer) and given that traffic typically flows over Amsterdam in .nl (like most traffic in .ch is going over Zurich, as that is where peering/DSLAM termination etc happens), not unreasonable to do that that way.

But it could be that in a /24, there are /28s that are in different countries, thus it is needed to be able to specify that, especially because the large corporations base their ads on IP addresses, but also languages (instead of respecting this magic Accept-Language HTTP header...)

Greets,
 Jeroen