[db-wg] 2022-01 Review Phase (Personal Data in the RIPE Database)

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 at 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 at 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://mailman.ripe.net/