NWI-13 Geofeed Legal Analysis
Dear colleagues, Following the legal update we provided on NWI-13: Geofeed at the DB WG session at RIPE 84, here is our analysis in case further discussion on this topic is needed. Executive Summary: -The RIPE Database is meant to contain specific information for its documented purposes. -Information inserted in the geofeed attribute could in some cases qualify as personal data. -The current purposes could explain geolocation information to be inserted only for ‘scientific research into network operations and topology’. -This purpose does not justify the processing of personal data; therefore restrictions had to be put in place to avoid the processing of unnecessary personal data. -The restrictions are now implemented based on the status of the registration. -If the purposes of the RIPE Database have changed in the meantime, this should be established via the community processes and documented. In that case we will re-evaluate the situation and the need for restrictions. Until then, the restrictions remain necessary. Legal Analysis: The RIPE Database is meant to contain specific information for the purposes that are defined in the RIPE Database Terms and Conditions. In terms of the _personal data_ inserted in there, the purpose that justifies its publication is to facilitate the coordination of network operations for the smooth and uninterrupted operation of Internet; this purpose explains why contact details of resource holders or their appointed contact persons are required. Before any new type of personal data is permitted to be inserted in the RIPE Database, we must evaluate if their processing is required for the purposes already defined and their processing can be considered in line with the basic personal data processing principles. Although it is the responsibility of the party inserting personal data to ensure that they have the appropriate legal grounds before doing so, the RIPE NCC has also shared responsibilities with regards to the personal data in the RIPE Database. This is because the RIPE NCC is the party that is making the RIPE Database available and implements the instructions given by the RIPE community. 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. These restrictions are essential to avoid any processing of personal data that is not required or necessary for the *currently defined* purposes of the RIPE Database and to limit the RIPE NCC's liability as a party with shared responsibilities in relation to the personal data inserted in the RIPE Database. Regarding the _(non-personal) data _inserted in the RIPE Database, it is also paramount that only data that is needed for the defined purposes of the RIPE Database is inserted. According to the RIPE Database Terms and Conditions, introducing the geofeed attribute (with restrictions) would be considered in line and acceptable to be used only for scientific research into network operations and topology (see Art. 3). We also understand that the purposes the RIPE Database must fulfil are not static but evolve over time. The RIPE Database Requirements Task Force has recently concluded its work and, with regard to geolocation, it has established that, although there is an active user group for geolocation data, geolocation itself is not an objective that the RIPE Database should fulfil. If the community's interests have changed since then and it is now agreed that geolocation is one of the purposes the RIPE Database must fulfil, this should be decided via the community's processes and reflected in the RIPE Database Terms and Conditions. In line with the data management principles proposed by the RIPE Database Requirements Task Force, it would be prudent to approach this issue holistically, taking into account that other geolocation information is already provided in the RIPE Database (i.e. geoloc, country code attributes in ORG and resource objects). On the basis of a new purpose for the geolocation information, we could then reassess the situation to understand whether the restrictions on the geofeed attribute are still necessary or whether it is justified to process personal data for this purpose. Kind regards, Maria Stafyla Senior Legal Counsel RIPE NCC
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
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
Hi, On 28/07/2022 15:52, Randy Bush via db-wg wrote:
and, being a researcher, i have no clue about this research spin at all.
I also don't understand where the research context is coming from. Usually, researchers don't have the need to correct the geolocation of so many prefixes to require something like geofeeds. And I really don't understand why the geofeed attribute would not be covered by the current purpose of the RIPE database, as described in the article 3. Geofeed matches "Facilitating coordination between network operators (network problem resolution, outage notification etc.)" Geofeed wants to correct geolocation problems. The geofeed attribute is exactly a way to "coordinate between network operators" (with, or without, the intermediation of geolocation providers). Geolocation problems impact the availability/performance of content/services. The medium is the network. Geolocation problems are network problems. On 28/07/2022 16:58, Laurent Pellegrino via db-wg wrote:
It's sad to see real solutions around geolocation (which helps users in many ways) overthought and killed in the eggs.
In general, the solution has not been killed. It would have been nice to have a neat "geofeed" attribute. However, geofeeds are successfully used with remarks in LACNIC, APNIC, AFRINIC, and RIPE. Comments are used in ARIN. Add a remark/comment "Geofeed https://url-to-my-file" and you are good to go. At the moment most of the data is produced with this approach anyway. Ciao, Massimo
Hi Massimo On Fri, 29 Jul 2022 at 04:11, Massimo Candela via db-wg <db-wg@ripe.net> wrote:
Hi,
On 28/07/2022 15:52, Randy Bush via db-wg wrote:
and, being a researcher, i have no clue about this research spin at all.
I also don't understand where the research context is coming from. Usually, researchers don't have the need to correct the geolocation of so many prefixes to require something like geofeeds.
I think this was an attempt by the legal team to find some way to justify having the "geofeed:" attribute based on the current defined purposes.
And I really don't understand why the geofeed attribute would not be covered by the current purpose of the RIPE database, as described in the article 3.
Geofeed matches "Facilitating coordination between network operators (network problem resolution, outage notification etc.)"
Geofeed wants to correct geolocation problems. The geofeed attribute is exactly a way to "coordinate between network operators" (with, or without, the intermediation of geolocation providers). Geolocation problems impact the availability/performance of content/services. The medium is the network. Geolocation problems are network problems.
No, "geofeed:" is not covered by this purpose. It may be provided by network operators but it is not 'used' by them. It has nothing to do with 'network problem resolution, outage notification etc'. It is, as I suggested, data that is used by external services. As are all the other items I mentioned in that list.
On 28/07/2022 16:58, Laurent Pellegrino via db-wg wrote:
It's sad to see real solutions around geolocation (which helps users in many ways) overthought and killed in the eggs.
In general, the solution has not been killed.
It would have been nice to have a neat "geofeed" attribute. However, geofeeds are successfully used with remarks in LACNIC, APNIC, AFRINIC, and RIPE. Comments are used in ARIN.
Add a remark/comment "Geofeed https://url-to-my-file" and you are good to go. At the moment most of the data is produced with this approach anyway.
This is not the way to go. We should never accept the overloading of a free text attribute with structured data as a solution to any problem. Let's fix the core problem and bring the purposes into line with the contents and usage of the database. cheers denis co-chair DB-WG
Ciao, Massimo
--
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
I'm not against making the purpose of the database more explicit towards geolocation data. I was just commenting that I don't see why the current generic purposes are not good enough (especially since we have a bunch of other attributes, including "geoloc"). On 29/07/2022 11:22, denis walker wrote:
Geofeed wants to correct geolocation problems. The geofeed attribute is exactly a way to "coordinate between network operators" (with, or without, the intermediation of geolocation providers). Geolocation problems impact the availability/performance of content/services. The medium is the network. Geolocation problems are network problems.
No, "geofeed:" is not covered by this purpose. It may be provided by network operators but it is not 'used' by them.
And by who is used?
It has nothing to do with 'network problem resolution
This is a weird statement. The network has a physical/geographical component, is not just topology and protocols. We have CDNs doing great moneys by offering solutions to this problem.
It is, as I suggested, data that is used by external services.
The data is not -used- by external services! There are external services, like geolocation providers, aggregating it, but the data is -used- by other network operators on the other side. Even more, some operators started collecting geofeed data directly, without the intermediation of geolocation providers. A great example of it is Google. The producer and the final user is always a network operator. ISP -> content content -> CDN content -> transit ISP -> geoloc provider -> content etc. Ciao, Massimo
On Fri, 29 Jul 2022, 16:04 Massimo Candela, <massimo@ntt.net> wrote:
I'm not against making the purpose of the database more explicit towards geolocation data. I was just commenting that I don't see why the current generic purposes are not good enough (especially since we have a bunch of other attributes, including "geoloc").
My argument is that none of that bunch of attributes are explicitly covered by the current purposes in a clear and obvious way.
On 29/07/2022 11:22, denis walker wrote:
Geofeed wants to correct geolocation problems. The geofeed attribute is exactly a way to "coordinate between network operators" (with, or without, the intermediation of geolocation providers). Geolocation problems impact the availability/performance of content/services. The medium is the network. Geolocation problems are network problems.
No, "geofeed:" is not covered by this purpose. It may be provided by network operators but it is not 'used' by them.
And by who is used?
I think I've been suitably corrected on this point :) Cheers denis Co- chair DB-WG
It has nothing to do with 'network problem resolution
This is a weird statement. The network has a physical/geographical component, is not just topology and protocols.
We have CDNs doing great moneys by offering solutions to this problem.
It is, as I suggested, data that is used by external services.
The data is not -used- by external services!
There are external services, like geolocation providers, aggregating it, but the data is -used- by other network operators on the other side.
Even more, some operators started collecting geofeed data directly, without the intermediation of geolocation providers. A great example of it is Google.
The producer and the final user is always a network operator.
ISP -> content content -> CDN content -> transit ISP -> geoloc provider -> content etc.
Ciao, Massimo
It is apparent to me that I shall long regret having been too busy over the past 2.5 years, just trying to survive the global pandemic, to have involved myself with the formulation of the legislation which the RIPE Database Requirements Task Force has now, apparently, set in stone. At this point I guess it is all I can do to ask whether or not biographical sketches of the six task force members listed here: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf are available online anywhere. I am most particularly keen to know how many, if any of them, could be fairly said to have represented the interests of either law enforcement or transparency advocates. Regards, rfg
Hi Ronald, I do not think that this is the issue here and I think I probably agree with you and most others on the db-wg when it comes to geofeed. I think this is possibly at least in part a misunderstanding between the db-wg/db team and the ncc legal team. The purposes could change to include geodata if there is consensus to do that, but that is not the stage we are at currently. -Cynthia On Thu, Jul 28, 2022 at 9:39 PM Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
It is apparent to me that I shall long regret having been too busy over the past 2.5 years, just trying to survive the global pandemic, to have involved myself with the formulation of the legislation which the RIPE Database Requirements Task Force has now, apparently, set in stone.
At this point I guess it is all I can do to ask whether or not biographical sketches of the six task force members listed here:
https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf
are available online anywhere.
I am most particularly keen to know how many, if any of them, could be fairly said to have represented the interests of either law enforcement or transparency advocates.
Regards, rfg
--
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
In message <CAKw1M3PZPzwJHoNyGrSAY_2azHeZpTw4aVw7GwCLhmT_qt2CiA@mail.gmail.com> =?UTF-8?Q?Cynthia_Revstr=C3=B6m?= <me@cynthia.re> wrote:
The purposes could change...
No, they couldn't. It appears that the RIPE Database Requirements Task Force issued its "final report" sometime late last year, and now the wheels have ground on further to bring us to the point where RIPE legal has issued an official proclamation to the effect that everything that does not comport with the Task Force's final list of defined purposes _must_ be jetisoned and thrown overboard. That would appear to be the short version of where things stand now. Based upon the principal of stare decisis, it would seem to be a bit late in the game to try to roll back any of what has already been adjudicated. Regards, rfg
I am not sure how you came to that conclusion, the way I read Maria's email didn't make me come to a conclusion anything like that. Maria said:
The RIPE Database is meant to contain specific information for the purposes that are defined in the RIPE Database Terms and Conditions.
The RIPE DB T&C and the DBTF report are not the same and the RIPE DB T&C could be amended. Maria also says:
If the community's interests have changed since then and it is now agreed that geolocation is one of the purposes the RIPE Database must fulfil, this should be decided via the community's processes and reflected in the RIPE Database Terms and Conditions.
I feel like this directly goes against what you are saying, it seems very clear to me that it is possible to change the purposes. -Cynthia On Fri, Jul 29, 2022 at 3:29 AM Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
In message <CAKw1M3PZPzwJHoNyGrSAY_2azHeZpTw4aVw7GwCLhmT_qt2CiA@mail.gmail.com> =?UTF-8?Q?Cynthia_Revstr=C3=B6m?= <me@cynthia.re> wrote:
The purposes could change...
No, they couldn't.
It appears that the RIPE Database Requirements Task Force issued its "final report" sometime late last year, and now the wheels have ground on further to bring us to the point where RIPE legal has issued an official proclamation to the effect that everything that does not comport with the Task Force's final list of defined purposes _must_ be jetisoned and thrown overboard.
That would appear to be the short version of where things stand now.
Based upon the principal of stare decisis, it would seem to be a bit late in the game to try to roll back any of what has already been adjudicated.
Regards, rfg
--
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
On Thu, Jul 28, 2022 at 9:50 PM, Cynthia Revström <db-wg@ripe.net> wrote:
I am not sure how you came to that conclusion, the way I read Maria's email didn't make me come to a conclusion anything like that.
Maria said:
The RIPE Database is meant to contain specific information for the purposes that are defined in the RIPE Database Terms and Conditions.
The RIPE DB T&C and the DBTF report are not the same and the RIPE DB T&C could be amended.
Maria also says:
If the community's interests have changed since then and it is now agreed that geolocation is one of the purposes the RIPE Database must fulfil, this should be decided via the community's processes and reflected in the RIPE Database Terms and Conditions.
I feel like this directly goes against what you are saying, it seems very clear to me that it is possible to change the purposes.
I'll also note that Maria's initial email said: "personal data that is not required or necessary for the currently defined purposes of the RIPE Database" with "currently defined" written in big, bold, flashy letters. It then continues with the paragraph you have quoted above: "If the community's interests have changed since then and it is now agreed that geolocation is one of the purposes the RIPE Database must fulfil, this should be decided via the community's processes…" I happen to think that Geofeed could easily fall into: "Publishing routing policies by network operators (IRR)" — part of my "routing policy" is that 192.0.2.0/24 is in Cologne, and that seems useful for you to know to build your policy as well and / or "Facilitating coordination between network operators (network problem resolution, outage notification etc.)" — you are seeing long latency to 192.0.2.0/24? Geofeeds tells you that that is in Warsaw, so when you contact me you can say something like "200ms seems like a long time to get from Berlin to Warsaw… perhaps we can not route this through Singapore??"" and / or "Scientific research into network operations and topology" — you are doing Internet measurements on latency. Why does traceroute to 192.0.2.0/24 take 3ms and 203.0.113.0/24 take 89ms? Well, Geofeeds tells you that one is in Akureyri and the other is in Lisbon. Seems like worth knowing… But, the bolding of "currently defined" and the "If the community's interests have changed since then…" seems to imply that it is at least worth discussing if we can add Denis suggestion of ""The RIPE Database may contain data that an agreed set of external services may use, require or rely on." and if it does actually need "a resolution by the GM to change the T&C", etc. Even if we successfully argue that Geofeeds fits into one of the above examples, it does seem like having the T&C reflect what people want to be able to use the DB for… W
-Cynthia
On Fri, Jul 29, 2022 at 3:29 AM Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
In message <CAKw1M3PZPzwJHoNyGrSAY_2azHeZpTw4aVw7GwCLhmT_qt2CiA@mail. gmail.com> =?UTF-8?Q?Cynthia_Revstr=C3=B6m?= <me@cynthia.re> wrote:
The purposes could change...
No, they couldn't.
It appears that the RIPE Database Requirements Task Force issued its "final report" sometime late last year, and now the wheels have ground on further to bring us to the point where RIPE legal has issued an official proclamation to the effect that everything that does not comport with the Task Force's final list of defined purposes _must_ be jetisoned and thrown overboard.
That would appear to be the short version of where things stand now.
Based upon the principal of stare decisis, it would seem to be a bit late in the game to try to roll back any of what has already been adjudicated.
Regards, rfg
--
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
Colleagues My vacation is almost over and I have a lot of emails to reply to so I will start with the topic of the day, geofeed. We have to think out of the box here. You are all approaching this issue from the same wrong angle. There is no point criticizing the legal team for doing their job. The answer was actually in that review..."If the purposes of the RIPE Database have changed". So the answer is simple, we add a new purpose to the RIPE Database. The only problem is we have never done this before in any formal way. We have no precedent, no process or procedure for doing this. I am hoping someone at the RIPE NCC can help us with establishing a process for doing this, maybe the legal team, senior management team, Daniel, the Executive Board if we need a resolution to be put to a GM... So let's first take a step back. The purposes of the RIPE Database have become the elephant in the room, no one wants to talk about them. The Database Task Force (DB-TF) completely sidestepped the issue. I did warn them several times that this must be addressed, but they ignored me (sorry guys). I tried to raise the issue at RIPE 83 but I was heavily criticized for doing so. I could see 2 or 3 years ago that this was a problem that would have to be addressed soon. Now we can no longer ignore the issue. What are the purposes now? We had the original purposes defined in the mid 1990s. These are the ones the DB-TF worked with. But they were reviewed in 2010 by the Data Protection Task Force (DPTF). As a member of the DPTF I wrote the initial draft of the RIPE Database Terms & Conditions (T&C). This included a list of purposes in Article 3. These extended the original set of purposes. The wording was tweaked by the DPTF and the community and consensus was reached on this set of purposes. But there wasn't a lot of discussion about the actual purposes, just the wording. So the first question to answer is, do we take the set of purposes listed in Article 3 of the T&C as the definitive list of current purposes, regardless of what the DB-TF considered? The next question is, what new purpose would we add to cover geofeed? Again I did make a recommendation to the DB-TF about this. I suggested something like: "The RIPE Database may contain data that an agreed set of external services may use, require or rely on." This purpose would cover: -"geofeed:" -"geoloc:" -"language:" -"abuse-c:" -IRT object -use of ROLE objects for contacts for external services like RIPE Atlas None of the above list are covered by any of the purposes currently defined in the T&C. We would then have to define somewhere the 'agreed set of external services'. If we want to add a new purpose we then need to establish a procedure for doing this with community consent. There is no policy on the purposes of the RIPE Database so the PDP would not work here. As the RIPE Database is a service provided by the RIPE NCC and covered by a set of legally binding T&C, it may need a resolution by the GM to change the T&C. There is also the issue of how any new purpose may (legally) impact on the existing data contained within the database and any consent that has been given for the use of that data. Daniel said in Iceland that it is "time to stop tinkering around the edges of the RIPE Database and address some of the fundamental issues". I think this is an appropriate moment to add a new purpose and work through the whole process of doing so. Maybe we can sort it out by RIPE 85 in case we do need to involve the GM. I suspect we may do this again once we establish the process. cheers denis co-chair DB-WG On Thu, 28 Jul 2022 at 13:33, Maria Stafyla via db-wg <db-wg@ripe.net> wrote:
Dear colleagues,
Following the legal update we provided on NWI-13: Geofeed at the DB WG session at RIPE 84, here is our analysis in case further discussion on this topic is needed.
Executive Summary:
- The RIPE Database is meant to contain specific information for its documented purposes.
- Information inserted in the geofeed attribute could in some cases qualify as personal data.
- The current purposes could explain geolocation information to be inserted only for ‘scientific research into network operations and topology’.
- This purpose does not justify the processing of personal data; therefore restrictions had to be put in place to avoid the processing of unnecessary personal data.
- The restrictions are now implemented based on the status of the registration.
- If the purposes of the RIPE Database have changed in the meantime, this should be established via the community processes and documented. In that case we will re-evaluate the situation and the need for restrictions. Until then, the restrictions remain necessary.
Legal Analysis:
The RIPE Database is meant to contain specific information for the purposes that are defined in the RIPE Database Terms and Conditions.
In terms of the _personal data_ inserted in there, the purpose that justifies its publication is to facilitate the coordination of network operations for the smooth and uninterrupted operation of Internet; this purpose explains why contact details of resource holders or their appointed contact persons are required.
Before any new type of personal data is permitted to be inserted in the RIPE Database, we must evaluate if their processing is required for the purposes already defined and their processing can be considered in line with the basic personal data processing principles.
Although it is the responsibility of the party inserting personal data to ensure that they have the appropriate legal grounds before doing so, the RIPE NCC has also shared responsibilities with regards to the personal data in the RIPE Database. This is because the RIPE NCC is the party that is making the RIPE Database available and implements the instructions given by the RIPE community.
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.
These restrictions are essential to avoid any processing of personal data that is not required or necessary for the currently defined purposes of the RIPE Database and to limit the RIPE NCC's liability as a party with shared responsibilities in relation to the personal data inserted in the RIPE Database.
Regarding the _(non-personal) data _inserted in the RIPE Database, it is also paramount that only data that is needed for the defined purposes of the RIPE Database is inserted.
According to the RIPE Database Terms and Conditions, introducing the geofeed attribute (with restrictions) would be considered in line and acceptable to be used only for scientific research into network operations and topology (see Art. 3).
We also understand that the purposes the RIPE Database must fulfil are not static but evolve over time.
The RIPE Database Requirements Task Force has recently concluded its work and, with regard to geolocation, it has established that, although there is an active user group for geolocation data, geolocation itself is not an objective that the RIPE Database should fulfil.
If the community's interests have changed since then and it is now agreed that geolocation is one of the purposes the RIPE Database must fulfil, this should be decided via the community's processes and reflected in the RIPE Database Terms and Conditions.
In line with the data management principles proposed by the RIPE Database Requirements Task Force, it would be prudent to approach this issue holistically, taking into account that other geolocation information is already provided in the RIPE Database (i.e. geoloc, country code attributes in ORG and resource objects).
On the basis of a new purpose for the geolocation information, we could then reassess the situation to understand whether the restrictions on the geofeed attribute are still necessary or whether it is justified to process personal data for this purpose.
Kind regards,
Maria Stafyla Senior Legal Counsel RIPE NCC
--
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
the purpose has been for operational use since dirt was invented. the geofeed: attribute points to data which operators, namely content providers, need. maybe we do not need to make a bureaucratic mountain out of a molehill. randy
After having looked closer at Article 3 of the RIPE DB T&C[1], I have to agree with Denis and the legal team, geofeed doesn't really fit into any of those purposes. I should have done this earlier but I have to admit that I had never properly read the RIPE DB T&C before and it was quite dumb of me to comment without doing that, so apologies to the legal team for what I said earlier. So I do think we might need to update the T&C for geofeed to be covered. [1]: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms -Cynthia On Fri, Jul 29, 2022 at 2:55 AM Randy Bush via db-wg <db-wg@ripe.net> wrote:
the purpose has been for operational use since dirt was invented. the geofeed: attribute points to data which operators, namely content providers, need. maybe we do not need to make a bureaucratic mountain out of a molehill.
randy
--
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
On 29/07/2022 03:55, Randy Bush via db-wg wrote:
the purpose has been for operational use since dirt was invented. the geofeed: attribute points to data which operators, namely content providers, need. maybe we do not need to make a bureaucratic mountain out of a molehill.
randy
+1. We can argue it but operators like Google already require it otherwise your IPs might be reassigned to another country. See: https://www.iucc.ac.il/en/blog/2021-05-google-geo-location/ for when Google placed all Israeli academic IPs inside Iceland. For Google, RFC8805 is bible and if you don't have a configured CSV for them to parse you might find your IPs being reassigned to some other country (as documented in numerous NANOG postings over the past 2 years). -Hank
Hi Randy On Fri, 29 Jul 2022 at 02:55, Randy Bush via db-wg <db-wg@ripe.net> wrote:
the purpose has been for operational use since dirt was invented. the
The term 'operational use' has never actually been defined. But if we were to define it then I suspect it will be more about network operators solving technical problems with keeping networks online.
geofeed: attribute points to data which operators, namely content providers, need.
Content providers 'not=' network operators.
maybe we do not need to make a bureaucratic mountain out of a molehill.
Welcome to the modern world. Like it or not, legal considerations have much more influence on technical life now than they did in the early days of the internet. We have to live with this and work with it rather than try to fight against it. The solution is simple in principle...we bring the purposes of the database into line with the content and usage. The need to do this has been on the horizon for a long time... cheers denis co-chair DB-WG
randy
--
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
the purpose has been for operational use since dirt was invented. the The term 'operational use' has never actually been defined. But if we were to define it then I suspect it will be more about network operators solving technical problems with keeping networks online.
the network is for the users. and they want their mtv. and they can not have their mtv unless the content providers geolocate them.
maybe we do not need to make a bureaucratic mountain out of a molehill. Welcome to the modern world.
i will resist this bait randy
On Fri, 29 Jul 2022, 16:00 Randy Bush, <randy@psg.com> wrote:
the purpose has been for operational use since dirt was invented. the The term 'operational use' has never actually been defined. But if we were to define it then I suspect it will be more about network operators solving technical problems with keeping networks online.
the network is for the users. and they want their mtv. and they can not have their mtv unless the content providers geolocate them.
A lot of this discussion is about interpreting one defined purpose trying to make everything fit in order to 'get around' a legal review. That legal review is based on the RIPE NCC legal team doing what they are paid for...to protect the RIPE NCC from legal action. If the purpose was so clear we would not be doing this dance. If it's not that clear a legal council making a challenge against the NCC has room to manoeuvre. It makes sense to have a clearly defined purpose. Then there is no argument. Cheers denis Co- chair DB-WG
maybe we do not need to make a bureaucratic mountain out of a molehill. Welcome to the modern world.
i will resist this bait
randy
A lot of this discussion is about interpreting one defined purpose trying to make everything fit in order to 'get around' a legal review.
another interpretation is that this discussion is trying to bridge a rather shocking gap between ncc legal, one db-wg-co-chair, and how the operational internet actually works. i have no problem with you going off into a db-omphaloskepsis task force. but, in the meantime some of us have an internet to run. randy
On Fri, 29 Jul 2022, 17:29 Randy Bush, <randy@psg.com> wrote:
A lot of this discussion is about interpreting one defined purpose trying to make everything fit in order to 'get around' a legal review.
another interpretation is that this discussion is trying to bridge a rather shocking gap between ncc legal, one db-wg-co-chair, and how the operational internet actually works.
i have no problem with you going off into a db-omphaloskepsis task force. but, in the meantime some of us have an internet to run.
Well of course as you are all so busy running this Internet you can completely ignore my suggestion to review the purposes and make them clear and simple to understand with definitions and without unnecessary interpretation and then continue to run round in circles arguing over legal reviews. You can even take the DBTF report, ripe-767, as gospel and then you only have 4 purposes to worry about instead of the 6 in the T&C. Perhaps that will make all operators lives easier and you'll get everything operators want from the database. Cheers denis Co-chair DB-WG
randy
In message <CAKvLzuHJwzDv38XS-+FamE183MqzG6Cvq-wio_KhRkSV3UY1OQ@mail.gmail.com>, denis walker <ripedenis@gmail.com> wrote:
A lot of this discussion is about interpreting one defined purpose trying to make everything fit in order to 'get around' a legal review. That legal review is based on the RIPE NCC legal team doing what they are paid for...to protect the RIPE NCC from legal action...
I have often opined that any competent attorney can make a reasonably good case for never even getting out of bed in the morning, let alone going in to work, because of the potential for litigation that may arise therefrom. The legally safest course of action is always to do absolutely nothing. (It is just rather unfortunate that abject poverty and starvation may ensue.) As regards to the "Legal Analysis" that was posted here recently, to my eyes it looked rather less like a legal analysis than it did a personal political manefesto. All sorts of bold assertions were made of the form "this must be this way" and "that must be that way" but with nary a single reference to any applicable statue or precedent. (Perhaps the author did have an abundance of such references, but just omitted them in an effort to dumb down the content for its intended audience.) Regards, rfg
On 29 Jul 2022, at 10:31, denis walker via db-wg wrote:
Content providers 'not=' network operators.
I'm not sure how to read this, Denis. If you mean that there are network operators who are not content providers, I agree. If you mean that content providers are not to be considered network operators, I think you are making a false dichotomy. Niall
The field is OPTIONAL in the schema. Therefore the maintainer surely has "consented" to publication of the URL to geo, if the field exists: It isn't pre-filled. The consent question here, is the maintainer and their obligations in law, and the role of the RIPE NCC in offering a publication service to the maintainer. The downstream consent question, is about a CSV format file held elsewhere. The field is not PII. The contents of the geofeed file, which is NOT in the RIPE NCC service might or might not be, but this is at worst, an indirect pointer. The field is about addresses, it contains no necessary PII in abstract. if I publish http://some.where/~ggm/geofeed.csv then the URL has PII, Is that really held to be a problem? Remember, I consented to posting the URL, I had to hold the maintainer password, the NCC didn't make me do it. The field is operationally helpful to operators of IP address services, BGP speakers, network operators. If a delegate of an address has a concern, their first port of call is the publisher of the geofeed file itself, not the RIPE NCC. I don't understand why the T&C have been interpreted to demand re-writing to fix something, when this is a field which has obvious utility, and low risk, given it is voluntary, and not prefilled or mandated, and does not actually represent any PII breach in and of itself. Truly, I think that a process has driven down a one-way street which wasn't on the route plan, and isn't helping forward progress. I think the wrong question has been posed, and very probably answered correctly, but in the wrong context by legals. I think that if they understood context, they might re-consider. I do not see why explicit language change process burdens are needed to understand the operational utility of this field in the schema. -George
Hi George On Fri, 29 Jul 2022, 16:12 George Michaelson via db-wg, <db-wg@ripe.net> wrote:
The field is OPTIONAL in the schema. Therefore the maintainer surely has "consented" to publication of the URL to geo, if the field exists: It isn't pre-filled. The consent question here, is the maintainer and their obligations in law, and the role of the RIPE NCC in offering a publication service to the maintainer. The downstream consent question, is about a CSV format file held elsewhere.
The field is not PII. The contents of the geofeed file, which is NOT in the RIPE NCC service might or might not be, but this is at worst, an indirect pointer. The field is about addresses, it contains no necessary PII in abstract. if I publish http://some.where/~ggm/geofeed.csv then the URL has PII, Is that really held to be a problem? Remember, I consented to posting the URL, I had to hold the maintainer password, the NCC didn't make me do it.
The legal team will have to answer this question but is facilitating a service that leads to the identification of an individual the same (in law) as providing the PII directly?
The field is operationally helpful to operators of IP address services, BGP speakers, network operators. If a delegate of an address has a concern, their first port of call is the publisher of the geofeed file itself, not the RIPE NCC.
I don't understand why the T&C have been interpreted to demand re-writing to fix something, when this is a field which has obvious utility, and low risk, given it is voluntary, and not prefilled or mandated, and does not actually represent any PII breach in and of itself.
Does it do any harm to review the current wording of the purposes and how they can be interpreted and perhaps make them more explicitly cover how the database is used? Cheers denis Co-chair DB-WG
Truly, I think that a process has driven down a one-way street which wasn't on the route plan, and isn't helping forward progress. I think the wrong question has been posed, and very probably answered correctly, but in the wrong context by legals. I think that if they understood context, they might re-consider. I do not see why explicit language change process burdens are needed to understand the operational utility of this field in the schema.
-George
--
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
Hi, <de-lurk> my name is Frank Habicht, not having enable in RIPE region, but Eastern Africa and active in AfriNIC etc... Wanted to stay out of this, but to me this thread is turning sad and "funny" at the same time... On 29/07/2022 18:24, denis walker via db-wg wrote: ...
The legal team will have to answer this question but is facilitating a service that leads to the identification of an individual the same (in law) as providing the PII directly?
Guess we have to accept that the legal team rules supreme, but I fail to understand how this "facilitating a service that leads to..." is the problem. To me this seems similar to the next building having a sign "BANK" on it - that facilitates bank robberies (illegal activities) just the same.
Does it do any harm to review the current wording of the purposes and how they can be interpreted and perhaps make them more explicitly cover how the database is used?
can at the very least the operationally useful status quo be maintained until all the committees have finished the review? please. PS: i believe some content providers operate routers, and i believe some network operators can have an operational interest in geography. I also believe that a geofeed in a /29 inetnum can point to data of /20 granularity - covering multiple customers in one city. which should be highly legal. Thanks, Frank Habicht <lurk>
On 29-07-2022 17:24 +0200, denis walker wrote:
The field is not PII. The contents of the geofeed file, which is NOT in the RIPE NCC service might or might not be, but this is at worst, an indirect pointer. The field is about addresses, it contains no necessary PII in abstract. if I publish http://some.where/~ggm/geofeed.csv then the URL has PII, Is that really held to be a problem? Remember, I consented to posting the URL, I had to hold the maintainer password, the NCC didn't make me do it.
The legal team will have to answer this question but is facilitating a service that leads to the identification of an individual the same (in law) as providing the PII directly?
I think this is murky. GDPR still considers pointers to information to be Personal data. If you have some personal data (let's say the customer Name) on a tablem you can't "remove" if by creating a table of Names and storing in the customer table the id of the name instead of the value. If the url was hosted by RIPE, I would consider its contents to be part of the database as well, and covered by it. However, here the url (which may or may not contain PII) is handled by the user (ti simplify, as it's unlikely they will not be hosting it themselves). The RIPE db would contain a pointer, inserted by the user (if so he wants, as it's optional), to a different database whose contents and access are handled by the user itself. I think it can be considered a different db whose controller is the person it might be identifying. To further complicate things, a person that would already be identifiable without the geofeed attribute. So while I completely agree with not requiring any natural person to reveal where they live (in an accurate way), the process of implementing restrictions at RIPE whois fo allowing or not this optional attribute, itself based on some fragile heuristics, seems overkill. I think we would be better off adding a general purpose of
* Providing a structural way in which to share additional optional information that the Registrant may wish to make available to third parties about their entries.
That's extremely broad, but as long as it on optional attributes (that can be based on user consent) I think it should be fine, and it would be in line with the actual expectations of the community. If a group of network operators wanted to make their lyrical tastes in their person objects, we (the community) should be able to focus on the merits of the requested feature (how many people want it, how would that impact the operation of the database, what would be the cost of implementing it on the server, is this an appropriate place for the information to be included…), without worrying if a preference for limericks could be considered personal identifying information that -despite the user opting-in to publish that- has not a legal basis that allows RIPE to host it. Best regards -- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/ PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ==================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ==================================================================== In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to dpd@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad. ====================================================================
Content providers 'not=' network operators.
given the state of the actual operational internet, this is a rather shocking statement from a ripe wg co-chair. randy
On Fri, 29 Jul 2022, 16:08 Randy Bush, <randy@psg.com> wrote:
Content providers 'not=' network operators.
given the state of the actual operational internet, this is a rather shocking statement from a ripe wg co-chair.
I was probably being a bit loose with my definitions but are you saying that ALL content providers are network operators?
randy
I was probably being a bit loose with my definitions but are you saying that ALL content providers are network operators?
i eagerly await your counter-example randy
On Fri, 29 Jul 2022, 16:41 Randy Bush, <randy@psg.com> wrote:
I was probably being a bit loose with my definitions but are you saying that ALL content providers are network operators?
i eagerly await your counter-example
It was a question not a statement. Cheers denis Co- chair DB-WG
randy
I was probably being a bit loose with my definitions but are you saying that ALL content providers are network operators?
i eagerly await your counter-example
It was a question not a statement.
I guess Randy is indicating it's for you to argue by providing a counter-example because it doesn't really conform to what appears to be common interpretation of the term. Regards, - Håvard
On 29 Jul 2022, at 1:55, Randy Bush via db-wg wrote:
the purpose has been for operational use since dirt was invented. the geofeed: attribute points to data which operators, namely content providers, need.
That seems to me to fall within the scope of the purpose "Facilitating Internet operations and coordination" mentioned in ripe-767 at https://www.ripe.net/publications/docs/ripe-767#6-4-purpose--facilitating-in.... If this became consensus here in the DB WG, a simple NWI might be the next step.
maybe we do not need to make a bureaucratic mountain out of a molehill.
Indeed. Niall (trying to leave my hat off)
Hi Niall On Fri, 29 Jul 2022, 14:42 Niall O'Reilly via db-wg, <db-wg@ripe.net> wrote:
On 29 Jul 2022, at 1:55, Randy Bush via db-wg wrote:
the purpose has been for operational use since dirt was invented. the geofeed: attribute points to data which operators, namely content providers, need.
That seems to me to fall within the scope of the purpose "Facilitating Internet operations and coordination" mentioned in ripe-767 at
https://www.ripe.net/publications/docs/ripe-767#6-4-purpose--facilitating-in... .
Sorry Niall but what is written in ripe-767 is an interpretation of the purposes by the members of the DBTF. Part of what they say is based on the suggestion I gave them. The actual purpose is defined in the T&C and is different to what is written in ripe-767.
If this became consensus here in the DB WG, a simple NWI might be the next step.
maybe we do not need to make a bureaucratic mountain out of a molehill.
Indeed.
It would be useful to establish a process for changing the purposes. Cheers denis Co-chair DB-WG
Niall (trying to leave my hat off)
--
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
On 29 Jul 2022, at 15:22, denis walker wrote:
Hi Niall
On Fri, 29 Jul 2022, 14:42 Niall O'Reilly via db-wg, <db-wg@ripe.net> wrote:
On 29 Jul 2022, at 1:55, Randy Bush via db-wg wrote:
the purpose has been for operational use since dirt was invented. the geofeed: attribute points to data which operators, namely content providers, need.
That seems to me to fall within the scope of the purpose "Facilitating Internet operations and coordination" mentioned in ripe-767 at
https://www.ripe.net/publications/docs/ripe-767#6-4-purpose--facilitating-in... .
Sorry Niall but what is written in ripe-767 is an interpretation of the purposes by the members of the DBTF. Part of what they say is based on the suggestion I gave them. The actual purpose is defined in the T&C and is different to what is written in ripe-767.
Which reads, "Facilitating coordination between network operators (network problem resolution, outage notification etc.)." What Randy wrote, quoted further up, seems to me to fall just as well within the scope of this statement of purpose. What's your point? Niall
Hi Denis, You raise some very good points and I agree with you that we should update the purposes and establish procedures for doing so. Also could someone explain to me how I should interpret Article 8.3, does that mean that the T&C can be altered by the Policy Development Process? Article 8.3: "Changes can also be effected through the Policy Development Process." Given what you said in your email I assume this is not the case but I don't know what else it would mean. P.S. I assume "Daniel" is referring to dfk? -Cynthia On Fri, Jul 29, 2022 at 2:33 AM denis walker via db-wg <db-wg@ripe.net> wrote:
Colleagues
My vacation is almost over and I have a lot of emails to reply to so I will start with the topic of the day, geofeed. We have to think out of the box here. You are all approaching this issue from the same wrong angle. There is no point criticizing the legal team for doing their job. The answer was actually in that review..."If the purposes of the RIPE Database have changed". So the answer is simple, we add a new purpose to the RIPE Database. The only problem is we have never done this before in any formal way. We have no precedent, no process or procedure for doing this. I am hoping someone at the RIPE NCC can help us with establishing a process for doing this, maybe the legal team, senior management team, Daniel, the Executive Board if we need a resolution to be put to a GM...
So let's first take a step back. The purposes of the RIPE Database have become the elephant in the room, no one wants to talk about them. The Database Task Force (DB-TF) completely sidestepped the issue. I did warn them several times that this must be addressed, but they ignored me (sorry guys). I tried to raise the issue at RIPE 83 but I was heavily criticized for doing so. I could see 2 or 3 years ago that this was a problem that would have to be addressed soon. Now we can no longer ignore the issue.
What are the purposes now? We had the original purposes defined in the mid 1990s. These are the ones the DB-TF worked with. But they were reviewed in 2010 by the Data Protection Task Force (DPTF). As a member of the DPTF I wrote the initial draft of the RIPE Database Terms & Conditions (T&C). This included a list of purposes in Article 3. These extended the original set of purposes. The wording was tweaked by the DPTF and the community and consensus was reached on this set of purposes. But there wasn't a lot of discussion about the actual purposes, just the wording.
So the first question to answer is, do we take the set of purposes listed in Article 3 of the T&C as the definitive list of current purposes, regardless of what the DB-TF considered?
The next question is, what new purpose would we add to cover geofeed? Again I did make a recommendation to the DB-TF about this. I suggested something like:
"The RIPE Database may contain data that an agreed set of external services may use, require or rely on."
This purpose would cover: -"geofeed:" -"geoloc:" -"language:" -"abuse-c:" -IRT object -use of ROLE objects for contacts for external services like RIPE Atlas
None of the above list are covered by any of the purposes currently defined in the T&C. We would then have to define somewhere the 'agreed set of external services'.
If we want to add a new purpose we then need to establish a procedure for doing this with community consent. There is no policy on the purposes of the RIPE Database so the PDP would not work here. As the RIPE Database is a service provided by the RIPE NCC and covered by a set of legally binding T&C, it may need a resolution by the GM to change the T&C. There is also the issue of how any new purpose may (legally) impact on the existing data contained within the database and any consent that has been given for the use of that data.
Daniel said in Iceland that it is "time to stop tinkering around the edges of the RIPE Database and address some of the fundamental issues". I think this is an appropriate moment to add a new purpose and work through the whole process of doing so. Maybe we can sort it out by RIPE 85 in case we do need to involve the GM. I suspect we may do this again once we establish the process.
cheers denis co-chair DB-WG
On Thu, 28 Jul 2022 at 13:33, Maria Stafyla via db-wg <db-wg@ripe.net> wrote:
Dear colleagues,
Following the legal update we provided on NWI-13: Geofeed at the DB WG session at RIPE 84, here is our analysis in case further discussion on this topic is needed.
Executive Summary:
- The RIPE Database is meant to contain specific information for its documented purposes.
- Information inserted in the geofeed attribute could in some cases qualify as personal data.
- The current purposes could explain geolocation information to be inserted only for ‘scientific research into network operations and topology’.
- This purpose does not justify the processing of personal data; therefore restrictions had to be put in place to avoid the processing of unnecessary personal data.
- The restrictions are now implemented based on the status of the registration.
- If the purposes of the RIPE Database have changed in the meantime, this should be established via the community processes and documented. In that case we will re-evaluate the situation and the need for restrictions. Until then, the restrictions remain necessary.
Legal Analysis:
The RIPE Database is meant to contain specific information for the purposes that are defined in the RIPE Database Terms and Conditions.
In terms of the _personal data_ inserted in there, the purpose that justifies its publication is to facilitate the coordination of network operations for the smooth and uninterrupted operation of Internet; this purpose explains why contact details of resource holders or their appointed contact persons are required.
Before any new type of personal data is permitted to be inserted in the RIPE Database, we must evaluate if their processing is required for the purposes already defined and their processing can be considered in line with the basic personal data processing principles.
Although it is the responsibility of the party inserting personal data to ensure that they have the appropriate legal grounds before doing so, the RIPE NCC has also shared responsibilities with regards to the personal data in the RIPE Database. This is because the RIPE NCC is the party that is making the RIPE Database available and implements the instructions given by the RIPE community.
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.
These restrictions are essential to avoid any processing of personal data that is not required or necessary for the currently defined purposes of the RIPE Database and to limit the RIPE NCC's liability as a party with shared responsibilities in relation to the personal data inserted in the RIPE Database.
Regarding the _(non-personal) data _inserted in the RIPE Database, it is also paramount that only data that is needed for the defined purposes of the RIPE Database is inserted.
According to the RIPE Database Terms and Conditions, introducing the geofeed attribute (with restrictions) would be considered in line and acceptable to be used only for scientific research into network operations and topology (see Art. 3).
We also understand that the purposes the RIPE Database must fulfil are not static but evolve over time.
The RIPE Database Requirements Task Force has recently concluded its work and, with regard to geolocation, it has established that, although there is an active user group for geolocation data, geolocation itself is not an objective that the RIPE Database should fulfil.
If the community's interests have changed since then and it is now agreed that geolocation is one of the purposes the RIPE Database must fulfil, this should be decided via the community's processes and reflected in the RIPE Database Terms and Conditions.
In line with the data management principles proposed by the RIPE Database Requirements Task Force, it would be prudent to approach this issue holistically, taking into account that other geolocation information is already provided in the RIPE Database (i.e. geoloc, country code attributes in ORG and resource objects).
On the basis of a new purpose for the geolocation information, we could then reassess the situation to understand whether the restrictions on the geofeed attribute are still necessary or whether it is justified to process personal data for this purpose.
Kind regards,
Maria Stafyla Senior Legal Counsel RIPE NCC
--
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
On 29-07-2022 02:32 +0200, denis walker wrote:
This purpose would cover: -"geofeed:" -"geoloc:" -"language:" -"abuse-c:" -IRT object -use of ROLE objects for contacts for external services like RIPE Atlas
None of the above list are covered by any of the purposes currently defined in the T&C. We would then have to define somewhere the 'agreed set of external services'.
FWIW, I think abuse-c and IRT could be covered by: - Facilitating coordination between network operators (network problem resolution, outage notification etc.) since abuse originating from the network can be considered a "network problem". Interestingly, the purpose - Providing information about the Registrant and Maintainer of Internet number resources when the resources are suspected of being used for unlawful activities, to parties who are authorised under the law to receive such information. fells short since "the team who actually deals with issues in this network" (abuse, noc, etc.) is often neither the Registrant itself nor the Maintainer. Best regards -- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/ PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ==================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ==================================================================== In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to dpd@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad. ====================================================================
Hi Ángel On Fri, 29 Jul 2022, 16:36 Ángel González Berdasco via db-wg, < db-wg@ripe.net> wrote:
On 29-07-2022 02:32 +0200, denis walker wrote:
This purpose would cover: -"geofeed:" -"geoloc:" -"language:" -"abuse-c:" -IRT object -use of ROLE objects for contacts for external services like RIPE Atlas
None of the above list are covered by any of the purposes currently defined in the T&C. We would then have to define somewhere the 'agreed set of external services'.
FWIW, I think abuse-c and IRT could be covered by:
- Facilitating coordination between network operators (network problem resolution, outage notification etc.)
since abuse originating from the network can be considered a "network problem".
To me it's the 'could' that is the problem. A clear specific purpose takes the doubt out of many of the interpretations of this generalised purpose.
Interestingly, the purpose
- Providing information about the Registrant and Maintainer of Internet number resources when the resources are suspected of being used for unlawful activities, to parties who are authorised under the law to receive such information.
fells short since "the team who actually deals with issues in this network" (abuse, noc, etc.) is often neither the Registrant itself nor the Maintainer.
I agree. I made many mistakes writing the original T&C, especially involving the 'maintainer'. These have never been discussed or fixed since.
Cheers denis Co- chair DB-WG
Best regards
-- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/
PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys
====================================================================
INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union.
====================================================================
In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to dpd@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad.
====================================================================
--
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
Dear colleagues, We are following the discussion on updating the purposes of the RIPE Database to accommodate geolocation. Until then we need to perform validation according to the legal analysis based on the current purpose. If there are updates on the discussion on the purposes of the database, we will re-evaluate the situation. In the meantime, this is how we plan to update the validation of the "geofeed:" attribute: (1) Firstly, the current validation based on prefix size is inadequate as it doesn't account for the intended use. We will replace the validation by prefix size with validation by "status:" value. (2) Resources allocated or assigned by the RIPE NCC to a resource holder are not considered personal data and can use "geofeed:", including: inetnum: ALLOCATED PA, ASSIGNED PI inet6num: ALLOCATED-BY-RIR, ASSIGNED PI (3) Resources with a "status:" not intended for individual assignment can also use "geofeed:" including: inetnum: SUB-ALLOCATED PA, AGGREGATED-BY-LIR, LIR-PARTITIONED PA, ASSIGNED ANYCAST inet6num: ALLOCATED-BY-LIR, AGGREGATED-BY-LIR, ASSIGNED ANYCAST (4) Resources that are reasonably assumed to be related to one individual user cannot use the "geofeed:" attribute. inetnum: ASSIGNED PA inet6num: ASSIGNED (5) LEGACY resources are not in scope. If there is interest in using "geofeed:" with legacy resources we can evaluate. We intend to implement these changes in the next Whois release. Regards, Ed Shryane RIPE NCC
On 28 Jul 2022, at 13:33, Maria Stafyla via db-wg <db-wg@ripe.net> wrote:
Dear colleagues,
Following the legal update we provided on NWI-13: Geofeed at the DB WG session at RIPE 84, here is our analysis in case further discussion on this topic is needed.
Hi, On Fri, Jul 29, 2022 at 02:33:07PM +0200, Edward Shryane via db-wg wrote:
We are following the discussion on updating the purposes of the RIPE Database to accommodate geolocation. Until then we need to perform validation according to the legal analysis based on the current purpose. If there are updates on the discussion on the purposes of the database, we will re-evaluate the situation. In the meantime, this is how we plan to update the validation of the "geofeed:" attribute:
(1) Firstly, the current validation based on prefix size is inadequate as it doesn't account for the intended use. We will replace the validation by prefix size with validation by "status:" value.
In which way would "status:" differenciate between business customers and personal end users?
(4) Resources that are reasonably assumed to be related to one individual user cannot use the "geofeed:" attribute. inetnum: ASSIGNED PA inet6num: ASSIGNED
"ASSIGNMENT" = "one *individual* user" is not a valid assumption. It's a customer. Maybe. It might be an enterprise with 100 offices, or Joe Random Personal User. Why is nobody listening here? Gert Doering -- NetMaster -- 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
Why is nobody listening here?
preconceived models which do not match what ops actually do yet another artifact of thinking there are green, blue, magenta, ... IP addresses randy
(5) LEGACY resources are not in scope. If there is interest in using "geofeed:" with legacy resources we can evaluate.
inetnum: 147.28.0.0 - 147.28.15.255 netname: RGNET-RSCH-147-0 country: EE org: ORG-RO47-RIPE admin-c: RB45695-RIPE tech-c: RB45695-RIPE abuse-c: AR52766-RIPE status: LEGACY notify: rw@rg.net mnt-by: MAINT-RGNET mnt-by: RIPE-NCC-LEGACY-MNT remarks: Geofeed https://rg.net/geofeed created: 2020-10-20T23:45:00Z last-modified: 2020-11-12T13:16:12Z source: RIPE randy
Dear Colleagues, There was no support expressed in replies to my proposal to improve the "geofeed:" validation rules (see below, from July). Given this, the DB team will leave the current validation rules as-is, pending the outcome of the discussion on "geofeed:" and the database T&C's. Regards Ed Shryane RIPE NCC
On 29 Jul 2022, at 14:33, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear colleagues,
We are following the discussion on updating the purposes of the RIPE Database to accommodate geolocation. Until then we need to perform validation according to the legal analysis based on the current purpose. If there are updates on the discussion on the purposes of the database, we will re-evaluate the situation. In the meantime, this is how we plan to update the validation of the "geofeed:" attribute:
(1) Firstly, the current validation based on prefix size is inadequate as it doesn't account for the intended use. We will replace the validation by prefix size with validation by "status:" value.
(2) Resources allocated or assigned by the RIPE NCC to a resource holder are not considered personal data and can use "geofeed:", including: inetnum: ALLOCATED PA, ASSIGNED PI inet6num: ALLOCATED-BY-RIR, ASSIGNED PI
(3) Resources with a "status:" not intended for individual assignment can also use "geofeed:" including: inetnum: SUB-ALLOCATED PA, AGGREGATED-BY-LIR, LIR-PARTITIONED PA, ASSIGNED ANYCAST inet6num: ALLOCATED-BY-LIR, AGGREGATED-BY-LIR, ASSIGNED ANYCAST
(4) Resources that are reasonably assumed to be related to one individual user cannot use the "geofeed:" attribute. inetnum: ASSIGNED PA inet6num: ASSIGNED
(5) LEGACY resources are not in scope. If there is interest in using "geofeed:" with legacy resources we can evaluate.
We intend to implement these changes in the next Whois release.
Regards, Ed Shryane RIPE NCC
On 28 Jul 2022, at 13:33, Maria Stafyla via db-wg <db-wg@ripe.net> wrote:
Dear colleagues,
Following the legal update we provided on NWI-13: Geofeed at the DB WG session at RIPE 84, here is our analysis in case further discussion on this topic is needed.
--
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
Hi Maria There has been quite a discussion in the last 24 hours from various angles about interpretation of terminology and purposes and context. Perhaps this is a good moment to pause and allow the legal team to review the discussion and see if anything that has been said affects your analysis. Cheers denis Co-chair DB-WG On Thu, 28 Jul 2022, 13:33 Maria Stafyla via db-wg, <db-wg@ripe.net> wrote:
Dear colleagues,
Following the legal update we provided on NWI-13: Geofeed at the DB WG session at RIPE 84, here is our analysis in case further discussion on this topic is needed.
Executive Summary:
- The RIPE Database is meant to contain specific information for its documented purposes.
- Information inserted in the geofeed attribute could in some cases qualify as personal data.
- The current purposes could explain geolocation information to be inserted only for ‘scientific research into network operations and topology’.
- This purpose does not justify the processing of personal data; therefore restrictions had to be put in place to avoid the processing of unnecessary personal data.
- The restrictions are now implemented based on the status of the registration.
- If the purposes of the RIPE Database have changed in the meantime, this should be established via the community processes and documented. In that case we will re-evaluate the situation and the need for restrictions. Until then, the restrictions remain necessary.
Legal Analysis:
The RIPE Database is meant to contain specific information for the purposes that are defined in the RIPE Database Terms and Conditions.
In terms of the _personal data_ inserted in there, the purpose that justifies its publication is to facilitate the coordination of network operations for the smooth and uninterrupted operation of Internet; this purpose explains why contact details of resource holders or their appointed contact persons are required.
Before any new type of personal data is permitted to be inserted in the RIPE Database, we must evaluate if their processing is required for the purposes already defined and their processing can be considered in line with the basic personal data processing principles.
Although it is the responsibility of the party inserting personal data to ensure that they have the appropriate legal grounds before doing so, the RIPE NCC has also shared responsibilities with regards to the personal data in the RIPE Database. This is because the RIPE NCC is the party that is making the RIPE Database available and implements the instructions given by the RIPE community.
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.
These restrictions are essential to avoid any processing of personal data that is not required or necessary for the *currently defined* purposes of the RIPE Database and to limit the RIPE NCC's liability as a party with shared responsibilities in relation to the personal data inserted in the RIPE Database.
Regarding the _(non-personal) data _inserted in the RIPE Database, it is also paramount that only data that is needed for the defined purposes of the RIPE Database is inserted.
According to the RIPE Database Terms and Conditions, introducing the geofeed attribute (with restrictions) would be considered in line and acceptable to be used only for scientific research into network operations and topology (see Art. 3).
We also understand that the purposes the RIPE Database must fulfil are not static but evolve over time.
The RIPE Database Requirements Task Force has recently concluded its work and, with regard to geolocation, it has established that, although there is an active user group for geolocation data, geolocation itself is not an objective that the RIPE Database should fulfil.
If the community's interests have changed since then and it is now agreed that geolocation is one of the purposes the RIPE Database must fulfil, this should be decided via the community's processes and reflected in the RIPE Database Terms and Conditions.
In line with the data management principles proposed by the RIPE Database Requirements Task Force, it would be prudent to approach this issue holistically, taking into account that other geolocation information is already provided in the RIPE Database (i.e. geoloc, country code attributes in ORG and resource objects).
On the basis of a new purpose for the geolocation information, we could then reassess the situation to understand whether the restrictions on the geofeed attribute are still necessary or whether it is justified to process personal data for this purpose.
Kind regards,
Maria Stafyla Senior Legal Counsel RIPE NCC
--
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
participants (16)
-
Cynthia Revström -
denis walker -
Edward Shryane -
Frank Habicht -
George Michaelson -
Gert Doering -
Hank Nussbacher -
Havard Eidnes -
Laurent Pellegrino -
Maria Stafyla -
Massimo Candela -
Niall O'Reilly -
Randy Bush -
Ronald F. Guilmette -
Warren Kumari -
Ángel González Berdasco