Le vendredi 25 février 2022, Jeroen Massar via db-wg <db-wg@ripe.net> a écrit :

> On 20220225, at 10:20, Peter Hessler via db-wg <db-wg@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:

Hi Jeroen,

Thanks for your email, brother!

...if the legal assessment/advice is broken, as most

of the active members of this WG are saying, and if

RIPE NCC choose to add it within the "geofeed:"

attribute's implementation; then the situation

appears to be the same :-/

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.

...if the "remarks:" attribute is not targeted; then how to do with the same legal team's advice?

Which is why the restriction is so utterly pointless.

Are you saying that the implementer shall not

consider the legal advice for the "remarks:" attribute?

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

...though, i am of the view that it's difficult to

understand the rational of the legal team's advice

regarding the ability to add a URI as a value inside

an attribute..."geofeed:" & "remarks:" too(?)

Question: Is that URI a new type of personal data?

Thanks.

Shalom,

--sb.

Greets,
Jeroen

--

[...]

Best Regards !
__
baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure>
Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/>
__
#‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!»
‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
«Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)