Fwd: proposal: new attribute 'geofeed:
Hi Denis, all Please allow us some time to look into this and we will get back to you with our feedback next week. Kind regards, Maria Stafyla Senior Legal Counsel RIPE NCC
---------- Forwarded message --------- From: denis walker <ripedenis@gmail.com> Date: Thu, 7 Jan 2021 at 15:59 Subject: Re: [db-wg] Fwd: proposal: new attribute 'geofeed: To: Hank Nussbacher <hank@interall.co.il>, <legal@ripe.net> Cc: Database WG <db-wg@ripe.net>
HI Hank, colleagues
Whilst I can't answer your basic question, I could say that if the IETF approves a change to RPSL, with the RIPE Database data model based on RPSL, in principle we should implement the RPSL change.
Perhaps another question, to the RIPE NCC legal team, if I have a fixed IP address or block of addresses, is this geofeed location data personal data under the terms of GDPR?
cheers denis co-chair DB-WG
On Wed, 6 Jan 2021 at 07:01, hank--- via db-wg <db-wg@ripe.net> wrote:
I guess I am not understanding something. Why do we need a geofeed attribute? What problem are we trying to solve?
I understand why each block of IPs needs to be associated with a country, so that certain language specific auto-customizations will work. But what purpose is there to know that a /24 is in central Amsterdam? Is the purpose to assist marketers in geo-targetted sales? Is the purpose for network engineering (not sure what major problem we have that needs this)?
Is the purpose to know where you are so that in the event of an emergency (terror, tornado, etc) you can get emergency targeted alerts? If so, then the geofeed has to be at the /32 level and since many if not most IPs are mobile, and that is where you will get the alert from - from your cellphone provider, I still don't quite understand the reason for a geofeed tag.
Can someone clue me in?
Thanks, Hank
Caveat: The views expressed above are solely my own and do not express the views or opinions of my employer
Hi Denis, all, Thank you for your patience in this matter. We looked into this and the answer varies depending on the situation. Allocations and assignments can be made to either natural or legal persons. In the inetnums and inet6nums to be created the contact details of the relevant person will be inserted. For example, if a /27 IPv4 block is assigned to a legal person, the geofeed data will likely not constitute personal data. This will not be the case if an IPv4 /32 (single IP address) is assigned to a sole trader and the assignment is registered under the sole trader's name in the RIPE Database*. In this latter example, the inetnum will contain the contact details of the sole trader and the geofeed data will qualify as personal data. This is because personal data under GDPR is defined as any information that relates to an identified or identifiable natural person. Based on the above and before introducing the geofeed attribute, a full impact analysis of its implementation would have to be conducted by the RIPE NCC. If you have any questions, please let us know. Kind regards, Maria Stafyla Senior Legal Counsel RIPE NCC * Please note that the relevant RIPE Policy (https://www.ripe.net/publications/docs/ripe-733#62 <https://www.ripe.net/publications/docs/ripe-733#62>) is allowing not to register assignments on the end user's contact details but as part of the service provider's internal infrastructure. On 08/01/2021 11:27, Maria Stafyla wrote:
Hi Denis, all
Please allow us some time to look into this and we will get back to you with our feedback next week.
Kind regards,
Maria Stafyla Senior Legal Counsel RIPE NCC
---------- Forwarded message --------- From: denis walker <ripedenis@gmail.com> Date: Thu, 7 Jan 2021 at 15:59 Subject: Re: [db-wg] Fwd: proposal: new attribute 'geofeed: To: Hank Nussbacher <hank@interall.co.il>, <legal@ripe.net> Cc: Database WG <db-wg@ripe.net>
HI Hank, colleagues
Whilst I can't answer your basic question, I could say that if the IETF approves a change to RPSL, with the RIPE Database data model based on RPSL, in principle we should implement the RPSL change.
Perhaps another question, to the RIPE NCC legal team, if I have a fixed IP address or block of addresses, is this geofeed location data personal data under the terms of GDPR?
cheers denis co-chair DB-WG
On Wed, 6 Jan 2021 at 07:01, hank--- via db-wg <db-wg@ripe.net> wrote:
I guess I am not understanding something. Why do we need a geofeed attribute? What problem are we trying to solve?
I understand why each block of IPs needs to be associated with a country, so that certain language specific auto-customizations will work. But what purpose is there to know that a /24 is in central Amsterdam? Is the purpose to assist marketers in geo-targetted sales? Is the purpose for network engineering (not sure what major problem we have that needs this)?
Is the purpose to know where you are so that in the event of an emergency (terror, tornado, etc) you can get emergency targeted alerts? If so, then the geofeed has to be at the /32 level and since many if not most IPs are mobile, and that is where you will get the alert from - from your cellphone provider, I still don't quite understand the reason for a geofeed tag.
Can someone clue me in?
Thanks, Hank
Caveat: The views expressed above are solely my own and do not express the views or opinions of my employer
Dear Maria, On Wed, Jan 27, 2021 at 09:21:53AM +0100, Maria Stafyla via db-wg wrote:
Thank you for your patience in this matter.
We looked into this and the answer varies depending on the situation.
Allocations and assignments can be made to either natural or legal persons. In the inetnums and inet6nums to be created the contact details of the relevant person will be inserted.
For example, if a /27 IPv4 block is assigned to a legal person, the geofeed data will likely not constitute personal data. This will not be the case if an IPv4 /32 (single IP address) is assigned to a sole trader and the assignment is registered under the sole trader's name in the RIPE Database*. In this latter example, the inetnum will contain the contact details of the sole trader and the geofeed data will qualify as personal data.
This is because personal data under GDPR is defined as any information that relates to an identified or identifiable natural person.
Based on the above and before introducing the geofeed attribute, a full impact analysis of its implementation would have to be conducted by the RIPE NCC.
From the above it appears the reasoning stems from an assmumption that RIPE NCC hosts or publishes geofeed data. I believe this is not the case, the data in a geofeed file is whatever the hoster of the geofeed.csv file puts in the file.
The contents of the geofeed file (which is not published by RIPE NCC) are at the discretion of whoever hosts the geofeed file, this entity could be a sole trader or some other entity. It is the hoster's responsibility to comply with GDPR and other applicable laws. Can you confirm that merely listing an arbitary URL from within the RIPE database does not constitute personal data? An example is here: $ whois -h whois.ripe.net 2001:67c:208c:: | grep Geofeed remarks: Geofeed https://instituut.net/geofeed.csv The string 'Geofeed https://instituut.net/geofeed.csv' itself is not personal data, nor is it under control of the RIPE NCC. Can you confirm a hyperlink such as 'https://instituut.net/geofeed.csv' (or one step further, any content hosted at instituut.net) are outside the scope of the RIPE NCC? Kind regards, Job
HI Maria Thanks for the preliminary analysis. I do have a couple of questions below... On Wed, 27 Jan 2021 at 09:21, Maria Stafyla <mstafyla@ripe.net> wrote:
Hi Denis, all,
Thank you for your patience in this matter.
We looked into this and the answer varies depending on the situation.
Allocations and assignments can be made to either natural or legal persons. In the inetnums and inet6nums to be created the contact details of the relevant person will be inserted.
For example, if a /27 IPv4 block is assigned to a legal person, the geofeed data will likely not constitute personal data. This will not be the case if an IPv4 /32 (single IP address) is assigned to a sole trader and the assignment is registered under the sole trader's name in the RIPE Database*. In this latter example, the inetnum will contain the contact details of the sole trader and the geofeed data will qualify as personal data.
This is because personal data under GDPR is defined as any information that relates to an identified or identifiable natural person.
So in this situation, if this sole trader has a phone used exclusively for the business and a business email address and these are listed as their business contact details, are you saying the business phone and email are still classed as personal data? If that is true then anything 'relating' to the business is also 'relating' to the natural person and is therefore personal data. cheers denis co-chair DB-WG
Based on the above and before introducing the geofeed attribute, a full impact analysis of its implementation would have to be conducted by the RIPE NCC.
If you have any questions, please let us know.
Kind regards,
Maria Stafyla Senior Legal Counsel RIPE NCC
* Please note that the relevant RIPE Policy (https://www.ripe.net/publications/docs/ripe-733#62) is allowing not to register assignments on the end user's contact details but as part of the service provider's internal infrastructure.
On 08/01/2021 11:27, Maria Stafyla wrote:
Hi Denis, all
Please allow us some time to look into this and we will get back to you with our feedback next week.
Kind regards,
Maria Stafyla Senior Legal Counsel RIPE NCC
---------- Forwarded message --------- From: denis walker <ripedenis@gmail.com> Date: Thu, 7 Jan 2021 at 15:59 Subject: Re: [db-wg] Fwd: proposal: new attribute 'geofeed: To: Hank Nussbacher <hank@interall.co.il>, <legal@ripe.net> Cc: Database WG <db-wg@ripe.net>
HI Hank, colleagues
Whilst I can't answer your basic question, I could say that if the IETF approves a change to RPSL, with the RIPE Database data model based on RPSL, in principle we should implement the RPSL change.
Perhaps another question, to the RIPE NCC legal team, if I have a fixed IP address or block of addresses, is this geofeed location data personal data under the terms of GDPR?
cheers denis co-chair DB-WG
On Wed, 6 Jan 2021 at 07:01, hank--- via db-wg <db-wg@ripe.net> wrote:
I guess I am not understanding something. Why do we need a geofeed attribute? What problem are we trying to solve?
I understand why each block of IPs needs to be associated with a country, so that certain language specific auto-customizations will work. But what purpose is there to know that a /24 is in central Amsterdam? Is the purpose to assist marketers in geo-targetted sales? Is the purpose for network engineering (not sure what major problem we have that needs this)?
Is the purpose to know where you are so that in the event of an emergency (terror, tornado, etc) you can get emergency targeted alerts? If so, then the geofeed has to be at the /32 level and since many if not most IPs are mobile, and that is where you will get the alert from - from your cellphone provider, I still don't quite understand the reason for a geofeed tag.
Can someone clue me in?
Thanks, Hank
Caveat: The views expressed above are solely my own and do not express the views or opinions of my employer
Hi, (just my two cents) At the GDPR trainings/sessions i have been a part of, there is the "purpose" bit in GDPR. One natural person can choose to publish (its own) personal data if there is a purpose for it. In the RIPEdb case, the purpose seems obvious: to provide a worldwide reachable contact for a given resource. Also, if someone uses the same phone# for personal *and* business purposes, the choice to use that phone# or to find another exclusively business-oriented phone# should be that someone's choice... Regards, Carlos On Wed, 27 Jan 2021, denis walker via db-wg wrote:
HI Maria
Thanks for the preliminary analysis. I do have a couple of questions below...
On Wed, 27 Jan 2021 at 09:21, Maria Stafyla <mstafyla@ripe.net> wrote:
Hi Denis, all,
Thank you for your patience in this matter.
We looked into this and the answer varies depending on the situation.
Allocations and assignments can be made to either natural or legal persons. In the inetnums and inet6nums to be created the contact details of the relevant person will be inserted.
For example, if a /27 IPv4 block is assigned to a legal person, the geofeed data will likely not constitute personal data. This will not be the case if an IPv4 /32 (single IP address) is assigned to a sole trader and the assignment is registered under the sole trader's name in the RIPE Database*. In this latter example, the inetnum will contain the contact details of the sole trader and the geofeed data will qualify as personal data.
This is because personal data under GDPR is defined as any information that relates to an identified or identifiable natural person.
So in this situation, if this sole trader has a phone used exclusively for the business and a business email address and these are listed as their business contact details, are you saying the business phone and email are still classed as personal data? If that is true then anything 'relating' to the business is also 'relating' to the natural person and is therefore personal data.
cheers denis co-chair DB-WG
Based on the above and before introducing the geofeed attribute, a full impact analysis of its implementation would have to be conducted by the RIPE NCC.
If you have any questions, please let us know.
Kind regards,
Maria Stafyla Senior Legal Counsel RIPE NCC
* Please note that the relevant RIPE Policy (https://www.ripe.net/publications/docs/ripe-733#62) is allowing not to register assignments on the end user's contact details but as part of the service provider's internal infrastructure.
On 08/01/2021 11:27, Maria Stafyla wrote:
Hi Denis, all
Please allow us some time to look into this and we will get back to you with our feedback next week.
Kind regards,
Maria Stafyla Senior Legal Counsel RIPE NCC
---------- Forwarded message --------- From: denis walker <ripedenis@gmail.com> Date: Thu, 7 Jan 2021 at 15:59 Subject: Re: [db-wg] Fwd: proposal: new attribute 'geofeed: To: Hank Nussbacher <hank@interall.co.il>, <legal@ripe.net> Cc: Database WG <db-wg@ripe.net>
HI Hank, colleagues
Whilst I can't answer your basic question, I could say that if the IETF approves a change to RPSL, with the RIPE Database data model based on RPSL, in principle we should implement the RPSL change.
Perhaps another question, to the RIPE NCC legal team, if I have a fixed IP address or block of addresses, is this geofeed location data personal data under the terms of GDPR?
cheers denis co-chair DB-WG
On Wed, 6 Jan 2021 at 07:01, hank--- via db-wg <db-wg@ripe.net> wrote:
I guess I am not understanding something. Why do we need a geofeed attribute? What problem are we trying to solve?
I understand why each block of IPs needs to be associated with a country, so that certain language specific auto-customizations will work. But what purpose is there to know that a /24 is in central Amsterdam? Is the purpose to assist marketers in geo-targetted sales? Is the purpose for network engineering (not sure what major problem we have that needs this)?
Is the purpose to know where you are so that in the event of an emergency (terror, tornado, etc) you can get emergency targeted alerts? If so, then the geofeed has to be at the /32 level and since many if not most IPs are mobile, and that is where you will get the alert from - from your cellphone provider, I still don't quite understand the reason for a geofeed tag.
Can someone clue me in?
Thanks, Hank
Caveat: The views expressed above are solely my own and do not express the views or opinions of my employer
For example, if a /27 IPv4 block is assigned to a legal person, the geofeed data will likely not constitute personal data.
does a url pointing to the geofeed data constitute personal data? randy
participants (5)
-
Carlos Friaças -
denis walker -
Job Snijders -
Maria Stafyla -
Randy Bush