Hi there, 

Following others, this looks like a crazy situation. Reading the discussions for a long time it looks like you are turning around since months with contradictory actions and no clear convergence on the defined purposes. Nothing personal but just my opinion reading your discussions regularly.

I understand geofeeds may contain personal data but you manage the pointer not the content as others said.  Personal information from geofeeds is not collected nor processed.

Citing the answer from Maria "other geolocation information is already provided in the RIPE Database (i.e. geoloc, country code attributes in ORG and resource objects)", I am even more confused:
  • How can you guarantee a geoloc (latitude, longitude) is not personal information in that case? Following the recent discussions about the proposal to hide street addresses from the registry, this looks weird. A geoloc is entered by a user with no validation and nothing prevents people from putting coordinates to a location that identifies a real address (outside of this discussion, it's crazy to see geolocs pointing in the ocean, or maybe many subnets are in use on oil rigs...).

  • Is there really a consensus about what the country code in "resource objects" other than organizations mean?
    Citing your docs for inetnum object: "It has never been specified what this country represents. It could be the location of the head office of a multi-national company or where the server centre is based or the home of the End User. Therefore, it cannot be used in any reliable way to map IP addresses to countries.". Can we really consider this as geolocation information?
It's sad to see real solutions around geolocation (which helps users in many ways) overthought and killed in the eggs.

Kind regards,
Laurent Pellegrino

On Thu, Jul 28, 2022 at 3:57 PM Gert Doering via db-wg <db-wg@ripe.net> wrote:
Hi,

On Thu, Jul 28, 2022 at 01:33:07PM +0200, Maria Stafyla via db-wg wrote:
> As mentioned in the Legal Review Impact Analysis, if the geofeed
> attribute is inserted for registrations of assignments that are
> reasonably assumed to be related to one individual user, then the
> attribute will be considered as containing personal data and GDPR will
> apply. This is why we have proposed to implement restrictions.

I maintain that this part of the analysis is fundamentally flawed.

The size of an assignment does not have any correlation to the entity
that the prefix is assigned to - we can assign IPv4 /32s to corporate
customers, and we can assign IPv4 /28s to private end users, and this
is perfectly within the scope of the relevant RIPE policies.

Inventing restrictions based on "but it looks like!!" guesswork is
not what we are paying the RIPE NCC for.

*Especially* as the information entered is not PII itself, but
a pointer to a URL which could, as has been stated, contain anything
from "ZZ" to very detailed addresses, fully under control and fully
in the responsibility of the entity maintaining that list.


I have the nagging suspicion that people are not listening here, because
all this was already said months ago, and we're still running in circles.

Gert Doering
        -- totally not interested in geofeed:, but annoyed by arbitrary
           restrictions not in line with RIPE policies
--
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
--

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