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

Dear db-wg,
Hope this email finds you in good health.

Please see my comments below, inline...

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

>
>
> > 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:


>
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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20220225/894d485f/attachment.html>