Colleagues For now I want to focus on the privacy part of the proposal. I will come back to verification later. So below is my response to all the issues raised in the impact analysis (with references to verification removed for now). cheers denis proposal author
Impact Analysis
Note: to support understanding of the proposal, details of an impact analysis carried out by the RIPE NCC are included below. This analysis is based on existing data and should be viewed only as an indication of the potential impacts that might result if the proposal is accepted and implemented.
Executive Summary
If this proposal is accepted:
Personal data, especially personal contact details, will no longer be required for the RIPE Database to fulfil its purpose. Therefore, personal contacts can no longer be added to the RIPE Database.
It never was required, most people just entered it anyway.
Although the legality of having published data prior to this policy will not be affected, existing data will have to be re-evaluated based on this policy. The RIPE NCC will have to follow-up with resource holders to ensure they comply with the policy by removing all personal data from the database.
Personal contact data not personal data. Names and (partial) addresses are still recognised as necessary in some situations.
This will be required even if the resource holder or their contact person prefers to use personal data in the RIPE Database.
Many people don't realise the consequences of broadcasting their personal contact details to the world. Some people are coerced into entering personal details otherwise they are refused IP addresses.
This also means that:
8 million PERSON objects will need to be deleted or replaced;
We don't have 8 million PERSON objects in the database now. Does this number include deleted objects? They are not mentioned in the proposal.
In cases where the resource holder is a natural person, the person who creates/updates an object containing a postal address must explicitly confirm that they have their approval.
The proposal says they must hold documentary evidence, not explicitly confirm it. It has always been 'said' that consent must be given by data subjects to have their personal details entered into the database. How is that done today? A nod and a wink or is it written into a contract they sign?
The RIPE NCC has the right to follow up and ultimately deregister Internet number resources and terminate contractual agreements in the case of non-compliance with the RIPE policy and related RIPE NCC procedures.
This is the hard stick anyone can be hit with for non compliance with any policy. In practice, this stick is rarely if ever used for some policies, like having a working abuse-c email address.
A. RIPE NCC's Understanding of the Proposed Policy
It is the RIPE NCC’s understanding that by accepting this proposal, the community agrees that personal data, especially personal contact details, is no longer required for the specified purposes of the RIPE Database, except when it is to show who holds specific Internet number resources.
This policy will set requirements for the registration of personal data in the RIPE Database. This will exclude data referenced in database objects which are solely related to LEGACY resources not under direct or indirect contract with the RIPE NCC.
The publication of postal addresses will be optional for all organisations. Postal address will be limited to country and region for natural persons. All contacts will refer to roles instead of people, without referencing a postal address.
When applying to become a member you can specify a postal address (to be published in the database) separate to the legal address. This can be anyone's address (your grandmother maybe?), or a post box address or a false address. I believe all official communication from the NCC is done now by email. So anyone who currently does not want their real address published in the database is unlikely to give it. So postal address may as well be optional so those who want to supply it may give a real address. Natural persons completing this form should not be asked for the fine address detail. The Database Task Force also recommended to make postal address optional and eventually deprecated. (btw the member application form for a natural person does not actually ask for their legal address, just 'an address'.)
While membership termination or de-registration of resources could happen as a result of non-compliance with the policy, the RIPE NCC will focus on assisting LIRs to correct any non-compliant contacts.
The hard stick comment I mentioned above...
B. Impact of Policy on Registry and Addressing System
The RIPE NCC does not anticipate any significant impact on Internet number resource consumption, fragmentation or aggregation if this proposal is implemented.
C. Impact of Policy on RIPE NCC Operations/Services
The policy will require the RIPE NCC’s Member Services, Registration Services and Registry Monitoring teams to review and update their procedures. These new procedures can only be followed once the relevant web documentation has been updated and the LIR Portal and other internal systems aligned accordingly. This implementation work will affect staff availability for handling requests and performing their regular duties.
Most of this probably relates to verification.
RIPE NCC staff often refer to contacts registered in the RIPE Database, for instance: when establishing the chain of who has held legacy resources, when contacts in the LIR Portal are unresponsive, when asking if resources can be returned, or when trying to reach End Users who hold Provider Independent resources about a change of sponsorship. Once the policy is implemented, reaching the right person without knowing their name could become complicated, especially when phone numbers in the RIPE Databases lead to the switchboard or the reception of large organisations, or when sending emails to unspecified recipients. This could increase the number of resource holders that are unreachable or unresponsive and have their resources de-registered as a result.
This is more of an implementation detail. One of the subtle changes between v2 and v3 of the proposal is that I dropped the rejection of adding a name to a ROLE object. So for the implementation we could add a new, optional, multiple attribute to the ROLE object, something like "name:". The ROLE object should not include any personal contact details related to these named people. It should only contain the business contact data for this role. We have already acknowledged that 'name' is valid personal data to enter into the database when necessary, as in the case of a resource holder who is a natural person.
The policy could also impact the RIPE NCC's reporting and data analysis abilities if many organisations decide to omit or remove the postal address from their ORGANISATION objects. Although by no means perfect, this data often provides a rough idea of where the resource holder is located. This can be helpful when investigating Internet events and outages.
This is an example of where we have not been clear in privacy statements about how we process certain personal data. In the Privacy Terms relating to the membership application there is no mention of using the postal address for these purposes. Given that this address is not verified in any way, those who prefer not to supply it may give false details anyway. For the RIPE NCC they have access to the legal address held in the internal registry. That is more likely to be accurate. We now also have the legal country listed in the ORGANISATION object for resource holders. Also events and outages are more likely to relate to the resource objects than the address in the ORGANISATION object. This yet again highlights that we don't understand for what purpose the data in the database is used. If there is an argument for having the country and region of organisations and resources documented, which is not specific PII data, then this need should be explicitly documented and included in the mandatory registration data for either the organisation and/or resources.
Especially in the initial phase of implementation, a high number of tickets will be generated by LIRs' questions and complaints, asking how and why they need to correct their existing data. Extra effort will be required to inform LIRs about the need to keep registering persons as contacts in the LIR Portal alongside the new policy requirement to register only roles in the RIPE Database.
RIPE Database:
There will be no technical obstacles to apply the following changes to the RIPE Database:
Deprecate PERSON objects Remove the “address:” attribute from ROLE objects Modify the status of the “address:” attribute in ORGANISATION objects from mandatory to optional
There are currently more than 1.8 million PERSON objects in the RIPE Database that will need to be gradually deleted and replaced by ROLE objects. An indeterminable number of the 153,000 ROLE objects which refer to a person’s name will also need to be corrected.
Again the subtle change to V3 of the proposal does not prohibit the ROLE object taking a person's name, as long as the contact details relate to the business function.
It will not be possible to implement a technical solution that ensures:
ORGANISATION objects for legal entities and ROLE objects do not contain any personal data Name, country and region are the only personal data published in the RIPE Database in ORGANISATION objects referencing natural persons
I agree this cannot be technically verified or enforced. But as long as there is a policy stating these requirements, anyone whose personal data is wrongly used will have a case for enforcing corrections to the data. Currently, if you want address space you must agree to a high level of personal data being published in the database.
We will also be unable to prevent the registration of personal data in free-text attributes like “role:”, “remarks:”, “descr:” and “notify:”.
Same comment above applies here. There is no registration or operational requirement to enter personal data into many of the free text attributes. The "descr:" attribute is different. At the moment it is used to identify the End User who holds a block of address space. This generally includes a name and (partial) address. As an implementation detail this should be formalised into dedicated attributes for this purpose instead of overloading free text with structured data.
There are more than 122,000 organisations with Internet number resources in the RIPE Database. All of these will need to be validated. The “address:” attribute will need a new structured syntax that allows only the registration of country and region in ORGANISATION objects related to natural persons.
This is an implementation detail. We accept that the policy would be introduced in stages. One of the early stages could be to implement structured address attributes into the ORGANISATION and resource objects. These would then need to be used for all new objects and updated objects. Maybe also add a new attribute "user-type:" with values 'corporate' or 'person'.
Learning & Development:
Implementing this policy will require a full review and update of the learning goals, content, activities and visuals for the RIPE Database and LIR related face-to-face courses and webinars, RIPE Database e-learning course and microlearning videos, and the RIPE Database Certified Professionals exam.
These updates will impact the development and delivery of the L&D portfolio as a whole, as the team’s capacity for other activities will be considerably affected. This will limit the team’s ability to develop new courses and to maintain, deliver, and evaluate its existing ones.
The total expected time required for the updates is six to nine months of work, depending on whether updates to different courses can be done synchronously.
It's not clear how much of this work relates to the privacy changes and verification.
D. RIPE NCC Executive Board
While the board appreciates any attempt to clean up the database, we feel that a requirement to remove all person records from the database is taking things a step too far.
Whilst GDPR allows consensual processing of personal data, if you accept the Database Task Force's data management principles, data minimisation suggests we should not put data into the database that is not required for the purposes and not needed.
Specifically, with regards to this policy proposal:
It significantly reduces the usability for one of its core purpose - being able to contact resource holders about their number resources.
In what way does this proposal reduce contact with resource holders, never mind significantly? Currently you can contact a resource holder via their ORGANISATION object. The only difference with this proposal is that postal address will be optional and other contact details will not be personal. But they will still be present. Contacts will still exist and still be contactable. Again the only difference is that the contact details will not be personal.
It enforces business practices across all resource holders (for example role accounts) where this is not currently the case - especially since not all resources are held by organisations.
Most of the RIPE Database enforces business practices across all resource holders. The core of the registry is to register resource details. This is an enforced practice. All resource holders are considered to be 'organisations' from the database perspective. Even individual, natural persons. They all have an ORGANISATION object.
GDPR allows for the storing personal data for valid business reasons. This proposal requires removal of all PERSON records, regardless of valid business reasons.
There is a valid business reason (purpose) for storing names and (partial) addresses in the public registry (RIPE Database). There are no valid business reasons for storing other elements of personal data.
This proposal also covers legacy registrations under a (direct or indirect) contractual relationship with the RIPE NCC. The proposal does not provide any alternative or means of recourse if the RIPE NCC cannot reach these legacy holders.
There was a proposal many years ago (2007-01 I believe) to try to establish contact with all holders of resources documented in the RIPE Database. This policy implementation ran for several years. I can't remember if ALL resource holders were contacted in the end. Are you suggesting that this situation has deteriorated since the completion of that policy implementation? If there is a resource holder who cannot be identified or contacted, I am sure this is not the only policy that has no specific course of action for that situation.
It puts at risk the public chain of custody of Internet number resources.
I don't see how this proposal in any way impacts the public chain of custody of internet number resources.
We would welcome a discussion that focuses more on which parts of the data are publicly available, rather than a sweeping removal. Clean-up of person records that are not linked to any number resources has been standard practice for years.
My first version of this proposal did suggest making some of the data private. There was strong opposition to that idea. But again this proposal is not suggesting any sweeping removal of data. I suggest changing the data from personal based to business role based, not removal. Yes, the PERSON object type will be removed. But the contact data will remain as business ROLE data.
E. Legal Impact
The RIPE Database provides information about the legitimate holders of Internet number resources and their technical and administrative contacts. The contact details for both resource holders and their appointed contact persons consist of various information, such as names, (business) email addresses, (business) phone and fax numbers and (business) postal addresses.
Are you stressing the (business) aspect because of this policy or because you believe that should be the case now?
It is currently up to the resource holder to decide what contact details to add to the RIPE Database, and whether they wish to appoint a role/team or prefer a specific person to act as their contact for handling technical and administrative matters with regards to Internet number resources registered to them and their network.
As I pointed out above, all resource holders are considered to be 'organisations' from the database perspective. Even individual, natural persons. In the same way all contacts can be considered as a 'role' from the database perspective. Even individual, natural persons. The resource holder will still decide what elements of contact details to add (eg phone or email). The only difference is that they must not be personal.
When the processing of personal data is involved, this must adhere to some basic principles in order to comply with GDPR (not an exhaustive list):
Data must be processed on valid legal grounds Data must be processed for a specified, explicit and legitimate purpose Data must be relevant and limited to what is necessary Data must be kept no longer than needed for the purpose it was initially collected
Currently, the processing of personal data relating to resource holders is necessary for the performance of registry function. This function is carried out in the legitimate interest of the RIPE community and supports the smooth operation of the Internet globally (and is therefore in accordance with Article 6.1.f of the GDPR).
Firstly, the RIPE community is difficult to define. It has no membership. At any moment in time it can be a different set of random people from anywhere in the world. So I would think that 6.1.e would be more appropriate. Maintaining the registry is in the public interest. "Data must be relevant and limited to what is necessary". The only necessary personal data relating directly to a resource holder is their name and (partial) address and only if the resource holder is a natural person. For contacts the only necessary personal data is perhaps their name. For the rest of the data it is not 'necessary' for it to be personal.
Before adding a person’s contact details to the RIPE Database, resource holders must first obtain their consent (in accordance with Article 6.1.a of the GDPR).
6.1.a doesn't say if the consent should be written or if verbal consent is enough.
Although the resource holders themselves are responsible for the registration details they add to the RIPE Database, the RIPE NCC is responsible for operating it. Under GDPR, that creates shared responsibilities on the RIPE NCC’s side with regards to the personal data added and processed in the RIPE Database.
If this proposal becomes policy, it means that the RIPE community agrees that, although the purposes of the RIPE Database have not changed, personal data is no longer necessary for them to be fulfilled and generic contact details should suffice.
It never has been necessary. People just entered it without thinking about privacy and no one questioned it.
Even if the resource holder and/or their appointed contact persons wish themselves to add personal data to their contact details, because for example this better matches their business requirements, it will not be allowed under this policy.
Or to put it another way, those who have been coerced in the past to consent to publishing their personal details in a global, public database, or be refused address space, no longer need to give their consent. Even the procedure for the removal of personal contact details says: To change or remove Personal Contact Details may require: • Internet number resources to be returned to the appropriate Internet Registry • Registrant/Maintainer to lose control and/or right of usage of the Internet number resource This procedure makes no distinction between the different elements of personal data, ie name and phone number and (partial) address.
Existing registration details were added according to the - until now - valid consensus of the RIPE community that personal data is necessary to fulfil the purposes of the RIPE Database.
I would dispute that we have ever asked for a consensus from the community about the necessity of personal data to fulfil the purposes.
Accepting this proposal will not affect the legality of the existing registration details as they were made under the current status quo in which the processing of personal data is considered necessary for the defined purposes.
No one has ever considered if this type of personal data is necessary for the loosely defined purposes.
The policy requires the RIPE NCC to verify existing registration details as well. This means that all personal contact details will be replaced by generic email addresses. We will also explain to the resource holders that they are no longer allowed to enter any personal contact details anywhere in the RIPE Database.
Except for names and partial addresses for resource holders who are natural persons. And with the subtle change I made in V3 of the proposal, optionally names of contacts.
If this proposal is accepted, the postal address will become optional for all resource holders. Resource holders that are natural persons will only be allowed to register their country and region. In these cases, the party responsible for registering the natural person resource holder’s details in the database will have to obtain ‘documentary evidence’ that the holder has consented to their name and country/region being registered in the RIPE Database.
Is this not required now? How does anyone prove now that they have this consent?
At the moment, allowing the processing of the name and postal address of a natural person resource holder in the RIPE Database is on the legal basis of pursuing the legitimate interests of the RIPE community, and the mandate to perform the registry function. If this policy proposal is accepted, it means that the community agrees that although the name of the resource holder is needed at all times for the purposes of the RIPE Database, the postal address is not. The resource holder’s name will continue to be processed lawfully on the basis of pursuing the legitimate interests of the RIPE community and the mandate to perform the registry function, therefore their consent is not required. Consent will be the appropriate legal ground to justify the processing of their postal address. The RIPE NCC will have to technically ensure that whenever a resource holder withdraws their consent for this processing, they (or whoever maintains their registration data) will be able to remove it from the relevant objects.
In practice this is not as complicated as it sounds here. If we make the resource holder's postal address optional in the database, as recommended by the Database Task Force, these fields can be optional on the member application form. If a member applicant fills in these details, that can be consent to publish. The 'technically ensure' bit is simply making the address attribute optional in the ORGANISATION object. Note that this also applies to LIRs creating assignments for End Users. Here they typically put the End User's name and address in the "descr:" attribute. In the implementation this should be changed to properly structured optional name and address attributes in resource objects.
This will also have an effect on the historical RIPE Database records. The RIPE NCC will have to put processes in place so that historical resource holder postal addresses are not returned in historical queries for those who do not wish their postal address to be in the RIPE Database anymore.
These are implementation details. There are many things that can be done here.
Regarding the requirement to obtain ‘documentary evidence’, the RIPE Database Terms and Conditions (see Art 6.3) currently require the person adding data to the RIPE Database to make sure they have the appropriate legal grounds for doing so. Every time a database object is created or updated, the user agrees to the RIPE Database Terms and Conditions. In order to obtain ‘documentary evidence’, the RIPE NCC will consider how to obtain an explicit confirmation from the person who creates/updates a database object that they have the resource holder’s approval. This might require an additional step in the process of creating/updating database objects. To verify compliance with the policy, the RIPE NCC will have the right to ask the party who registered a resource holder’s details in the RIPE Database to submit this documentary evidence.
The RIPE NCC does not need this documentary consent unless the NCC is entering the data. If the resource holder is entering the data into the database the NCC does not need explicit confirmation.
Lastly, regarding the address, the policy mentions that ‘any valid address could be helpful’. The RIPE Database Requirements Task Force has identified four data management principles that should guide how users should insert data in the RIPE Database, one of them being ‘data consistency’. In light of this principle, the RIPE NCC sees the value of agreeing on the type of address resource holders are supposed to add if they wish to do so (e.g. legal, postal, network location).
Firstly these principles by the Database Task Force have not been discussed by the community and no consensus has been noted about them. However, I agree that if any address is entered into the database in any object type, a clear definition of what it means would be helpful to everyone.
The ultimate action the RIPE NCC may take in case of non-compliance with RIPE policies or RIPE NCC procedures is to deregister the relevant Internet number resources and terminate the relevant contractual agreement (e.g. RIPE NCC Standard Service Agreement, Legacy Agreement). The policy does not provide concrete timeframes for the RIPE NCC to allow existing resource holders to update their registration details in order to ensure compliance. For the sake of clarity and managing expectations, the RIPE NCC will have to clarify this in its implementation plan.
There has been a precedent set with a policy (I think 2007-01) which took several years to complete. Sometimes if the scale of a task is considerable, but has value in being done, flexibility on time scales is required.
The policy also requires all resource holders (both new and existing) to sign a declaration that confirms their agreement to this policy. The RIPE policies form is already an integral part of the RIPE NCC Standard Service Agreement (see Art. 6.1 of the SSA). Regarding Provider Independent resources, it is required in the RIPE policy ‘Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region’ that resources will be used in accordance with the RIPE policies. However, if this policy requires the RIPE NCC to ask for a separate signed declaration for compliance especially with this policy, this will create a precedent over the applicability of other RIPE policies.
Maybe this is something that needs to be considered for all policies. If you compare the number of resource holders with the number of people registered with the major mailing lists where policies are discussed, only a tiny fraction of them may be aware of new policies. An assertion that they have read and understood any new policy is not a bad idea. Maybe a form can be sent out with the annual bills listing what is new...
F. Implementation
Due to the large amount of work involved, the new policy will be implemented in phases and automated as much as possible, eventually involving new tools. There will be a long transitional period where only new data and/or updates will be affected, while old data will not be acted upon.
The RIPE NCC will not be able to ensure full compliance with the policy at any given time. This is because it is technically impossible to establish whether email addresses and phone numbers, as well as data registered as free text in the RIPE Database, are personal contacts.
With the information currently available, it is expected that implementation of the proposal, even with clear requirements, will have a very high impact in terms of the software development needed to facilitate policy changes. Internal and external processes and documentation will also need to be updated.
Not sure how much of this relates to privacy or verification.
Initially, PERSON objects will be deprecated.
Correcting existing ORGANISATION and ROLE objects containing personal data will be done when we receive external reports, during ARCs, and when handling tickets. This is expected to be an ongoing activity for years to come. Even if run as a dedicated project, it will not be possible to ensure the full compliance of the information entered as part of free text attributes. It is also worth noting that, should the community reverse this decision in the years to come, this would also be a significant project for the RIPE NCC.
It is expected that implementation of the policy can start after six to nine months from the date the proposal is accepted.
On Thu, 6 Oct 2022 at 09:25, Angela Dall'Ara via db-wg <db-wg@ripe.net> wrote:
Dear colleagues,
Policy proposal 2022-01, "Personal Data in the RIPE Database", is now in the Review Phase.
The goal of this proposal is to allow the publication of verified Personal Data in the RIPE Database only when they are justified by its purpose.
The proposal has been updated to version 3.0 after the last round of discussion.
This version differs from version 2.0 as follows:
- it is not explicitly proscribed to enter the name of a person in role objects
- the verification of fax numbers is not required
The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion.
You can find the proposal and impact analysis at:
https://www.ripe.net/participate/policies/proposals/2022-01
https://www.ripe.net/participate/policies/proposals/2022-01#impact-analysis
And the draft documents at:
https://www.ripe.net/participate/policies/proposals/2022-01/draft
As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue discussion of the proposal,
taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus.
It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
We encourage you to read the proposal, impact analysis and draft document and send any comments to <db-wg@ripe.net> before 4 November 2022.
Kind regards,
Angela Dall'Ara
Policy Officer
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