Colleagues Now we move on to the more difficult issue of identifying resource holders. For any resource holder that is not a natural person I don't think there is a privacy issue. For natural persons we seem to have this conflict between privacy and public interest. The privacy issue is well understood. Publishing the name and address of a natural person in an open, public database can have severe consequences. But what is the public interest? To understand this question we have to dig deep into the purpose of the RIPE Database. Terms are thrown around with little consideration to what they actually mean. We all know the RIPE Database is a 'public registry', but what does that really mean? What is it a registry of, why does it need to register this, who needs to know what and why? After 30 years maybe we need to re-evaluate the fundamental purpose of this database. The database is a number, routing and reverse delegation registry. The routing and delegation elements generally don't include personal data, so we can put them to one side for the moment. What is the number registry? It 'documents' IP addresses (IPv4 and IPv6). It is arguable if ASNs are part of the number or routing registry. Although they are Internet resources, the "org:" attribute is optional so it is not possible to identify the resource holder of an ASN using the database. There are a number of reasons that have been given over the years for why this documentation is required. To ensure allocations and assignments are unique. To know what parts of allocations are 'in use' by end users. To identify who is responsible for a block of address space. To have a means of contacting network operators for several reasons. We have already discussed contacts, so the key issue here relating to both privacy and public interest is identifying who is responsible for a block of address space. Let's consider why this needs to be done and who needs to know. ORGANISATION and INET(6)NUM objects all reference contacts. So if there are any technical, administrative or abuse issues there are contacts who can handle these issues. We have already agreed that contacts must be contactable and they must only exist in the database if they are capable of addressing the related issues. So what is the reason for wanting or needing to be able to identify who is responsible for a block of address space and where to find them? Taking away all the issues that contacts can handle, are we down to purely legal matters? Is it for those cases involving criminal or abusive behaviour that someone wants to hold the responsible party accountable or liable? Are there research and investigatory reasons for identifying the holders of blocks? Do some people want to cross reference assignments held by individuals or organisations from multiple, different resource holders to monitor activities? If so, is it in the public interest and should it override privacy? Before we can decide on the priorities of privacy vs public interest, we need to understand what that public interest is. How does that public interest fit with the purpose of the database? We need to have this discussion now on the purpose of the database and the public interest, or not, in certain bits of data to decide if the identities of natural persons holding resources can, should, must be hidden from public view. cheers denis proposal author
Colleagues We had a good discussion on contact details, I am hoping we can do the same on resource holder identity. I know there is reluctance in the community to get into a deep discussion on the purposes of the RIPE Database. The Task Force sidestepped the issue as far as any public discussion is concerned. It is a difficult subject. The use of the database as a public registry is not in question. We do need an updated understanding of what that means. If no one is able to present the public interest case for publishing the name and address of natural persons holding resources then the privacy case takes priority. If we cannot justify publishing this personal information based on the purposes, then the GDPR says very clearly that we must not publish it. All personal details of natural persons holding resources will have to be removed from the database or hidden from public view. This will also apply to assignments as well. There are many assignments with name and full address details of natural persons in the "descr:" attributes. We will have to remove the "descr:" attributes where the assignee is a natural person or hide them from public view. We need to have this discussion now and reach a new consensus, no matter how difficult it is...otherwise privacy overrides all other concerns, which may be the new consensus anyway. cheers denis proposal author On Thu, 26 May 2022 at 16:29, denis walker <ripedenis@gmail.com> wrote:
Colleagues
Now we move on to the more difficult issue of identifying resource holders. For any resource holder that is not a natural person I don't think there is a privacy issue. For natural persons we seem to have this conflict between privacy and public interest. The privacy issue is well understood. Publishing the name and address of a natural person in an open, public database can have severe consequences. But what is the public interest?
To understand this question we have to dig deep into the purpose of the RIPE Database. Terms are thrown around with little consideration to what they actually mean. We all know the RIPE Database is a 'public registry', but what does that really mean? What is it a registry of, why does it need to register this, who needs to know what and why? After 30 years maybe we need to re-evaluate the fundamental purpose of this database.
The database is a number, routing and reverse delegation registry. The routing and delegation elements generally don't include personal data, so we can put them to one side for the moment. What is the number registry? It 'documents' IP addresses (IPv4 and IPv6). It is arguable if ASNs are part of the number or routing registry. Although they are Internet resources, the "org:" attribute is optional so it is not possible to identify the resource holder of an ASN using the database. There are a number of reasons that have been given over the years for why this documentation is required. To ensure allocations and assignments are unique. To know what parts of allocations are 'in use' by end users. To identify who is responsible for a block of address space. To have a means of contacting network operators for several reasons.
We have already discussed contacts, so the key issue here relating to both privacy and public interest is identifying who is responsible for a block of address space. Let's consider why this needs to be done and who needs to know. ORGANISATION and INET(6)NUM objects all reference contacts. So if there are any technical, administrative or abuse issues there are contacts who can handle these issues. We have already agreed that contacts must be contactable and they must only exist in the database if they are capable of addressing the related issues. So what is the reason for wanting or needing to be able to identify who is responsible for a block of address space and where to find them? Taking away all the issues that contacts can handle, are we down to purely legal matters? Is it for those cases involving criminal or abusive behaviour that someone wants to hold the responsible party accountable or liable? Are there research and investigatory reasons for identifying the holders of blocks? Do some people want to cross reference assignments held by individuals or organisations from multiple, different resource holders to monitor activities? If so, is it in the public interest and should it override privacy?
Before we can decide on the priorities of privacy vs public interest, we need to understand what that public interest is. How does that public interest fit with the purpose of the database? We need to have this discussion now on the purpose of the database and the public interest, or not, in certain bits of data to decide if the identities of natural persons holding resources can, should, must be hidden from public view.
cheers denis proposal author
30-05-2022 a las 13:17 +0200, denis walker writes:
If no one is able to present the public interest case for publishing the name and address of natural persons holding resources then the privacy case takes priority. If we cannot justify publishing this personal information based on the purposes, then the GDPR says very clearly that we must not publish it. All personal details of natural persons holding resources will have to be removed from the database or hidden from public view. This will also apply to assignments as well. There are many assignments with name and full address details of natural persons in the "descr:" attributes. We will have to remove the "descr:" attributes where the assignee is a natural person or hide them from public view.
Please note that GDPR has the concept of processing based on consent. It might not be necessary to remove them. And some of those affected, may want them to stay published. I agree, however, that *not* publishing the home address of those that hold a resource as a natural person is probably a good idea. 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. ====================================================================
On 31 May 2022, at 15:31, Ángel González Berdasco via db-wg <db-wg@ripe.net> wrote:
30-05-2022 a las 13:17 +0200, denis walker writes:
If no one is able to present the public interest case for publishing the name and address of natural persons holding resources then the privacy case takes priority. If we cannot justify publishing this personal information based on the purposes, then the GDPR says very clearly that we must not publish it. All personal details of natural persons holding resources will have to be removed from the database or hidden from public view. This will also apply to assignments as well. There are many assignments with name and full address details of natural persons in the "descr:" attributes. We will have to remove the "descr:" attributes where the assignee is a natural person or hide them from public view.
Please note that GDPR has the concept of processing based on consent. It might not be necessary to remove them. And some of those affected, may want them to stay published.
I agree, however, that *not* publishing the home address of those that hold a resource as a natural person is probably a good idea.
Consent is the key bit indeed. But people can also chose to not use the RIPE DB. Personally, I don't mind having my name + email address in there, whois is for my purposes primarily a assignment DB ("is it an eyeball, is it a VPS network, it is a bunch of evil VPNs") but most importantly a "who is" database and thus contact: who to contact for a given resource, when one sees bad things coming out of it, when they have MTU issues, etc etc etc. As such, I personally would love to see the options: A) Publish name + email B) Publish name + email + phone C) Publish name + email + phone + address ('all') Personally B would be my option, the internet does not need to know where I physically am, but mail forwarding exists for that, making it an option though makes it clear one does not want to share that data and that it is just a forwarding place. But the problem is that some (not me) people want is: D) Hide all details Which would make whois for a person (they cannot have roles, otherwise they are not people) look like: person: Anonymous Person 172784394902 remarks: RIPE anonymized person -- https://www.ripe.net/contact/hiddenperson remarks: Responsible LIR: xx.lirhandle -- <handle>-RIPE -- https://www.website.com # autopopulated from LIR email: person-172784394902@anon.ripe.net # forwarded mail nic-hdl: PERSON-172784394902-RIPE mnt-by: RIPE-NCC-ANON-MNT # Can't have own maintainer then either created: 2002-03-19T12:20:34Z last-modified: 2021-05-12T15:05:51Z source: RIPE # Filtered Thus email forwarding to not expose that data but still allowing contact and still allowing statistics/associations to be made based on the handle, but not private details to be released. (note that people can still drop all mail in /dev/null and chose to remain ignorant independent if the address is valid or goes anywhere at all; bad folks do not fix things) But I think it is a really bad idea; people who don't want to be named on the Internet already have options by hiding at a cloud provider or a VPS where they can borrow address space, they do not need to have their name in the RIPE DB. Note that such a policy would cause address space for the rest of the lifetime of IPv6 to be handled that way too; then just do not get your own prefix in the database. The above A/B/C ... yeah kinda makes sense; but option D, big nope from me. Greets, Jeroen
Hi Jeroen On Tue, 31 May 2022 at 16:20, Jeroen Massar via db-wg <db-wg@ripe.net> wrote:
On 31 May 2022, at 15:31, Ángel González Berdasco via db-wg <db-wg@ripe.net> wrote:
30-05-2022 a las 13:17 +0200, denis walker writes:
If no one is able to present the public interest case for publishing the name and address of natural persons holding resources then the privacy case takes priority. If we cannot justify publishing this personal information based on the purposes, then the GDPR says very clearly that we must not publish it. All personal details of natural persons holding resources will have to be removed from the database or hidden from public view. This will also apply to assignments as well. There are many assignments with name and full address details of natural persons in the "descr:" attributes. We will have to remove the "descr:" attributes where the assignee is a natural person or hide them from public view.
Please note that GDPR has the concept of processing based on consent. It might not be necessary to remove them. And some of those affected, may want them to stay published.
I agree, however, that *not* publishing the home address of those that hold a resource as a natural person is probably a good idea.
Consent is the key bit indeed. But people can also chose to not use the RIPE DB.
Personally, I don't mind having my name + email address in there, whois is for my purposes primarily a assignment DB ("is it an eyeball, is it a VPS network, it is a bunch of evil VPNs") but most importantly a "who is" database and thus contact: who to contact for a given resource, when one sees bad things coming out of it, when they have MTU issues, etc etc etc.
There was quite a discussion on contacts a few days ago on this mailing list. I am considering resource holders separate from contacts. It was generally accepted that contactable contacts are an important element of the database, but they don't need to be personal.
As such, I personally would love to see the options:
A) Publish name + email B) Publish name + email + phone C) Publish name + email + phone + address ('all')
Personally B would be my option, the internet does not need to know where I physically am, but mail forwarding exists for that, making it an option though makes it clear one does not want to share that data and that it is just a forwarding place.
For resource holders that are not natural persons and not operating a business from a home address, mandatory name, address and email with optional phone is probably a good option. Where the resource holder is a natural person, or operating a business from a home address, the question is, do we have a clearly defined purpose of the RIPE Database that requires the personal name and address to be published?
But the problem is that some (not me) people want is: D) Hide all details
Which would make whois for a person (they cannot have roles, otherwise they are not people) look like:
person: Anonymous Person 172784394902 remarks: RIPE anonymized person -- https://www.ripe.net/contact/hiddenperson remarks: Responsible LIR: xx.lirhandle -- <handle>-RIPE -- https://www.website.com # autopopulated from LIR email: person-172784394902@anon.ripe.net # forwarded mail nic-hdl: PERSON-172784394902-RIPE mnt-by: RIPE-NCC-ANON-MNT # Can't have own maintainer then either created: 2002-03-19T12:20:34Z last-modified: 2021-05-12T15:05:51Z source: RIPE # Filtered
I think maybe you are confusing resource holders and contacts here. There are different requirements for the two. cheers denis proposal author
Thus email forwarding to not expose that data but still allowing contact and still allowing statistics/associations to be made based on the handle, but not private details to be released. (note that people can still drop all mail in /dev/null and chose to remain ignorant independent if the address is valid or goes anywhere at all; bad folks do not fix things)
But I think it is a really bad idea; people who don't want to be named on the Internet already have options by hiding at a cloud provider or a VPS where they can borrow address space, they do not need to have their name in the RIPE DB.
Note that such a policy would cause address space for the rest of the lifetime of IPv6 to be handled that way too; then just do not get your own prefix in the database.
The above A/B/C ... yeah kinda makes sense; but option D, big nope from me.
Greets, Jeroen
--
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 Angel On Tue, 31 May 2022 at 15:31, Ángel González Berdasco via db-wg <db-wg@ripe.net> wrote:
30-05-2022 a las 13:17 +0200, denis walker writes:
If no one is able to present the public interest case for publishing the name and address of natural persons holding resources then the privacy case takes priority. If we cannot justify publishing this personal information based on the purposes, then the GDPR says very clearly that we must not publish it. All personal details of natural persons holding resources will have to be removed from the database or hidden from public view. This will also apply to assignments as well. There are many assignments with name and full address details of natural persons in the "descr:" attributes. We will have to remove the "descr:" attributes where the assignee is a natural person or hide them from public view.
Please note that GDPR has the concept of processing based on consent. It might not be necessary to remove them. And some of those affected, may want them to stay published.
Yes GDPR does allow for consent. However in a database with widely distributed data entry, knowing that consent has been given, and not withdrawn, by each data subject is very difficult to confirm by the data controller. Also it would be necessary for each data subject to be fully informed of the potential consequences of publishing their personal data in an open, public database. Even if some natural persons want their details published in the RIPE Database, for whatever reasons, unless there is a purpose that clearly states the 'need' to do this, it is not a good idea to do it. There are too many unknowns between the data controller and some of the data subjects to be able to allow this with any degree of certainty for the data controller. cheers denis proposal author
I agree, however, that *not* publishing the home address of those that hold a resource as a natural person is probably a good idea.
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
On Thu, May 26, 2022 at 7:30 AM denis walker via db-wg <db-wg@ripe.net> wrote:
Colleagues
Now we move on to the more difficult issue of identifying resource holders.
What do you mean by "resource holders"? Are you referring to someone who has resources allocated or assigned to them directly by the RIPE NCC? Or are you referring to someone whose resources come from an LIR or a level below that? [...]
Before we can decide on the priorities of privacy vs public interest, we need to understand what that public interest is. How does that public interest fit with the purpose of the database? We need to have this discussion now on the purpose of the database and the public interest, or not, in certain bits of data to decide if the identities of natural persons holding resources can, should, must be hidden from public view.
It would also be good to understand whether this issue relates to a tiny fraction of the registrations. What proportion of registrations and what proportion of the registered number resources are we discussing? Thanks, Leo
Hi Leo On Tue, 31 May 2022 at 21:04, Leo Vegoda <leo@vegoda.org> wrote:
On Thu, May 26, 2022 at 7:30 AM denis walker via db-wg <db-wg@ripe.net> wrote:
Colleagues
Now we move on to the more difficult issue of identifying resource holders.
What do you mean by "resource holders"? Are you referring to someone who has resources allocated or assigned to them directly by the RIPE NCC? Or are you referring to someone whose resources come from an LIR or a level below that?
Both are in scope here. Where the resources are allocated or assigned directly by the RIPE NCC, they reference a mandatory ORGANISATION object that includes a mandatory name and address of the resource holder. For assignments made by LIRs or from sub-allocations, the INET(6)NUM frequently includes a full name and address in the "descr:" attributes.
[...]
Before we can decide on the priorities of privacy vs public interest, we need to understand what that public interest is. How does that public interest fit with the purpose of the database? We need to have this discussion now on the purpose of the database and the public interest, or not, in certain bits of data to decide if the identities of natural persons holding resources can, should, must be hidden from public view.
It would also be good to understand whether this issue relates to a tiny fraction of the registrations. What proportion of registrations and what proportion of the registered number resources are we discussing?
It is almost impossible to write a script to analyse this unless the script can recognise a natural person's name. But for a general idea I flicked through the INETNUM split file on the FTP site and can see a large number of names and addresses of people in the assignment objects. cheers denis proposal author
Thanks,
Leo
Hi, On Tue, May 31, 2022 at 2:49 PM denis walker <ripedenis@gmail.com> wrote: [...]
It would also be good to understand whether this issue relates to a tiny fraction of the registrations. What proportion of registrations and what proportion of the registered number resources are we discussing?
It is almost impossible to write a script to analyse this unless the script can recognise a natural person's name. But for a general idea I flicked through the INETNUM split file on the FTP site and can see a large number of names and addresses of people in the assignment objects.
As the RIPE NCC will have contracts in place, they should be able to tell us what proportion of LIRs are natural people. With that information we can start to understand whether this can be addressed purely through database rules or needs multiple approaches. Kind regards, Leo
Hi Leo On Wed, 1 Jun 2022 at 00:22, Leo Vegoda <leo@vegoda.org> wrote:
Hi,
On Tue, May 31, 2022 at 2:49 PM denis walker <ripedenis@gmail.com> wrote:
[...]
It would also be good to understand whether this issue relates to a tiny fraction of the registrations. What proportion of registrations and what proportion of the registered number resources are we discussing?
It is almost impossible to write a script to analyse this unless the script can recognise a natural person's name. But for a general idea I flicked through the INETNUM split file on the FTP site and can see a large number of names and addresses of people in the assignment objects.
As the RIPE NCC will have contracts in place, they should be able to tell us what proportion of LIRs are natural people. With that information we can start to understand whether this can be addressed purely through database rules or needs multiple approaches.
That might be interesting to know but unless the RIPE NCC's internal database has a flag to indicate a natural person they would have the same problem. But the numbers are not the real question. Anyone can see by flicking through the split file there is a 'significant' number of objects with full name and address details of people. And if one of them is you it is very significant. We also know there are people who won't become a resource holder or even get an assignment because of the risk of their personal details being entered into the RIPE Database. So we always come back to the fundamental question, for what purpose do we publish the name and address of a natural person who is a resource holder or who has an assignment from an LIR? We can also differentiate here between publishing the details and storing the details not for public access. If and when we establish the purpose of this information we can look at technical solutions. We should also keep in mind that this information is completely separate from being able to contact the operator of a network. So we are trying to establish why anyone needs to know who is responsible, accountable, liable for a block of IP addresses...and who needs to know that. Technical solutions may address how they can access this information. cheers denis proposal author
Kind regards,
Leo
Hi Denis, On Tue, May 31, 2022 at 5:12 PM denis walker <ripedenis@gmail.com> wrote: [...]
That might be interesting to know but unless the RIPE NCC's internal database has a flag to indicate a natural person they would have the same problem.
I expect they do. Or a reasonable proxy, like whether they validated that the member exists via a company registry or a registry of natural people.
But the numbers are not the real question. Anyone can see by flicking through the split file there is a 'significant' number of objects with full name and address details of people. And if one of them is you it is very significant. We also know there are people who won't become a resource holder or even get an assignment because of the risk of their personal details being entered into the RIPE Database. So we always come back to the fundamental question, for what purpose do we publish the name and address of a natural person who is a resource holder or who has an assignment from an LIR?
We can also differentiate here between publishing the details and storing the details not for public access. If and when we establish the purpose of this information we can look at technical solutions. We should also keep in mind that this information is completely separate from being able to contact the operator of a network. So we are trying to establish why anyone needs to know who is responsible, accountable, liable for a block of IP addresses...and who needs to know that. Technical solutions may address how they can access this information.
I think we should try to establish if the proportion of natural people that are LIRs is so low that any policy will always be handling corner cases. If that is the case, it might be better to establish policy objectives and just delegate the specific implementation to the RIPE NCC. Kind regards, Leo
Hi Leo On Wed, 1 Jun 2022 at 16:27, Leo Vegoda <leo@vegoda.org> wrote:
Hi Denis,
On Tue, May 31, 2022 at 5:12 PM denis walker <ripedenis@gmail.com> wrote:
[...]
That might be interesting to know but unless the RIPE NCC's internal database has a flag to indicate a natural person they would have the same problem.
I expect they do. Or a reasonable proxy, like whether they validated that the member exists via a company registry or a registry of natural people.
But the numbers are not the real question. Anyone can see by flicking through the split file there is a 'significant' number of objects with full name and address details of people. And if one of them is you it is very significant. We also know there are people who won't become a resource holder or even get an assignment because of the risk of their personal details being entered into the RIPE Database. So we always come back to the fundamental question, for what purpose do we publish the name and address of a natural person who is a resource holder or who has an assignment from an LIR?
We can also differentiate here between publishing the details and storing the details not for public access. If and when we establish the purpose of this information we can look at technical solutions. We should also keep in mind that this information is completely separate from being able to contact the operator of a network. So we are trying to establish why anyone needs to know who is responsible, accountable, liable for a block of IP addresses...and who needs to know that. Technical solutions may address how they can access this information.
I think we should try to establish if the proportion of natural people that are LIRs is so low
It is not only LIRs. So many assignment objects also contain name and address in the "descr:" attributes. We know one large telco has about 700k customer assignments documented in the RIPE Database. Unfortunately I can't easily find one in the 4.2m entries in the INETNUM split file to see if they have entered the customer name and address in the INETNUM as well as in referenced PERSON objects. These types of issues also need to be addressed.
that any policy will always be handling corner cases. If that is the case, it might be better to establish policy objectives and just delegate the specific implementation to the RIPE NCC.
I do see this policy as determining the principles. If approved then there would need to be further community discussion on a migration plan. This is not going to be a quick, overnight fix. Ultimately technical details will drop down to the RIPE NCC. cheers denis proposal author
Kind regards,
Leo
Hi Denis, On Wed, Jun 1, 2022 at 8:16 AM denis walker <ripedenis@gmail.com> wrote: [...]
I think we should try to establish if the proportion of natural people that are LIRs is so low
It is not only LIRs. So many assignment objects also contain name and
Both problems result in the same outcome - information about individuals in the database. But they happen because of different processes. And so if we want to address them we should look at those processes separately. [...]
I do see this policy as determining the principles. If approved then there would need to be further community discussion on a migration plan. This is not going to be a quick, overnight fix. Ultimately technical details will drop down to the RIPE NCC.
I must admit I struggled to work out what the proposal published at https://www.ripe.net/participate/policies/proposals/2022-01 would change. Does the text define new policy objectives? If so, I couldn't find them. Regards, Leo
Hi Leo On Wed, 1 Jun 2022 at 18:03, Leo Vegoda <leo@vegoda.org> wrote:
Hi Denis,
On Wed, Jun 1, 2022 at 8:16 AM denis walker <ripedenis@gmail.com> wrote:
[...]
I think we should try to establish if the proportion of natural people that are LIRs is so low
It is not only LIRs. So many assignment objects also contain name and
Both problems result in the same outcome - information about individuals in the database. But they happen because of different processes. And so if we want to address them we should look at those processes separately.
I disagree that they are different processes. The process is to identify natural persons who hold blocks of address space. Whether they are LIRs holding allocations or End Users holding assignments, it is the same principle. But again it doesn't really matter. The policy proposal defines the principles. How those principles are applied to the process(es) is a matter for the migration/implementation plan.
[...]
I do see this policy as determining the principles. If approved then there would need to be further community discussion on a migration plan. This is not going to be a quick, overnight fix. Ultimately technical details will drop down to the RIPE NCC.
I must admit I struggled to work out what the proposal published at https://www.ripe.net/participate/policies/proposals/2022-01 would change. Does the text define new policy objectives? If so, I couldn't find them.
I think this is a matter of terminology. Principles: Principles are standards we use to guide our behavior in general. Principles guide action, guide decision, and a principle is meant to have broad application everywhere the conditions apply. Principles focus one’s ways and shape the means. They exist to be useful – over and over again. Objectives: Objectives are the ends. Objectives are whatever outcome you are trying to accomplish. They are always measurable and time bound. Ultimately, both principles and objectives can shape and guide your course. Objectives shape your course by what you’re steering towards. Destination naturally dictates direction. As you pursue objectives, principles cut in to shape which ways and roads you’ll take, how you shall proceed. Principles can also rule out certain ways as undesirable on principle. The policy proposal primarily defines the principles for the use of personal data in the RIPE Database. If the policy proposal is accepted, the objectives will be set out later in a migration plan and technical overview. This will define a number of steps to apply the principles to the database. cheers denis proposal author
Regards,
Leo
participants (4)
-
denis walker -
Jeroen Massar -
Leo Vegoda -
Ángel González Berdasco