- db-wg - mailman.ripe.net

2022-01 V2 Resource Holders Address
by denis walker 27 Jun '22

27 Jun '22

Colleagues I have listened to your comments in recent discussions and had some preliminary talks with the RIPE NCC about what could be implemented. So now we have a second version of my proposal on personal data. I was getting comments from people that LEAs need addresses for their investigations, but also people had serious privacy concerns about publishing their home address in the database. I was considering the idea of publishing addresses with restricted access. However it seems that it is almost impossible to confirm the identity of LEAs (even from within our own region, never mind globally) and perhaps other NGOs that could be eligible to access this restricted data. So that idea is not viable. Then there was an issue over data quality of the addresses currently published in the database. In the ORGANISATION object the address is assumed to be a postal address. This mandatory address is entered and managed by the resource holders. No verification is done on this address. In the database documentation it says: "This is a full postal address for the business contact represented by this organisation object." That could be anyone. They don't even need to be located in the country where the organisation operates it's business. Being so loosely defined, any kind of verification would be impossible. That makes this address almost meaningless. It is on the same level as the "country:" attribute in resource objects. It only has meaning to whoever manages the data. Also by having this unverifiable address mandatory, we are almost inviting those who don't want to be easily located to enter false data. Especially as it is almost impossible to identify any of this postal address data as being true or false. I am therefore suggesting we make this postal address an optional attribute. If any resource holder wishes to enter this optional postal address they can do so. But if it is a personal address they must not enter more than region and country. The full personal address of a natural person must not be entered into the database in any object type. Optional data, when provided, is more likely to be accurate. Making this address optional is in line with a recommendation of the RIPE Database Task Force. Some will still argue that false data is useful if 'bad actors' enter the same false data in different places. That offers investigators an opportunity to cross reference this (false) data over different objects using the free text search facility of the database. In some cases this may be the only way to make these data links. Doing this has many problems. We cannot justify preserving false data in the database to allow some people to use an 'accidental feature'. There is no guarantee the same false data will be used in multiple places. There is a defined purpose of the database that allows LEAs to use public information from the database as part of their investigations. This purpose is actually about granting permission to LEAs to use available data. It does not define any data to be published in the database for the sole benefit of LEAs. So there is no purpose requiring this postal address to be published in the database. Optional is therefore a convenience for anyone who wishes to enter it. cheers denis policy proposer

4 20

2022-01 New Version Policy Proposal (Personal Data in the RIPE Database)
by Angela Dall'Ara 24 Jun '22

24 Jun '22

Dear colleagues, RIPE policy proposal 2022-01, "Personal Data in the RIPE Database" is now available for discussion again. 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. This proposal has been updated following the last round of discussion and is now at version 2.0. Some of the differences from version 1.0 include: - Publishing only country and region for natural persons - Making the current postal address publication optional for all - Allowing for the publication of different types of addresses in the future You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2022-01 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-710 We encourage you to review this proposal and send your comments to db-wg(a)ripe.net before 15 July 2022. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

5 20

Re: [db-wg] [anti-abuse-wg] Proposal 2022-01
by denis walker 24 Jun '22

24 Jun '22

Yes Carlos you are absolutely right. There is no suggestion whatsoever that any membership will be revoked or any resources de-registered if any verification fails. Cheers denis Proposal author On Thu, 23 Jun 2022, 11:48 Carlos Friaças via anti-abuse-wg, < anti-abuse-wg(a)ripe.net> wrote: > > > Hi, please see inline. > > > On Thu, 23 Jun 2022, Ronald F. Guilmette wrote: > > > Just curious... How many of you folks have actually read sections 4.0, > 5.0, > > and 6.0 of this pending proposal from the Database Working Group? > > Read it just now. :-) > > > > https://www.ripe.net/participate/policies/proposals/2022-01 > > > > I suspect that many of you are going to want to read those sections > before > > you have your memberships revoked for non-compliance. > > I can't read any details about membership revokation. Also i don't see it > as implicit. > > The three sections make perfect sense to me. In section 6.0, if i > understood correctly this won't apply to legacy resources which are still > out of any contractual relationship -- which also seems fine. > > > Regards, > Carlos > > > > Regards, > > rfg > > > > -- > > > > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/anti-abuse-wg > > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/anti-abuse-wg >

2 1

test database
by denis walker 22 Jun '22

22 Jun '22

Hi Why can I not create an AUT-NUM object in the test database using the web UI? It is not in the drop down menu on the create page. That of course means I can't create ROUTE(6) objects either. So I can't do anything with the routing registry in test mode. Although there is an orange banner across the top of the page saying 'TEST Environment' all the left hand index items refer to the RIPE Database. This is confusing. I would prefer them to refer to the TEST Database. cheers denis co-chair DB-WG

2 4

2022-01 Policy Proposal, Personal Data in the RIPE Database V2
by William Sylvester 13 Jun '22

13 Jun '22

All, I wanted to notify the workgroup that there is a new version of the Personal Data Proposal coming, it would be best to save any comments for the discussion period of that version. Please let me know if you have any questions. Thanks, William DB-WG Co-Chair

1 0

rfc2770
by Max Tulyev 03 Jun '22

03 Jun '22

Hi All! May be you know, if you have a 16-bit ASN, you have a /24 IPv4 network reserved for you for multicast purposes. It is 233.asnum-hi-octets.asnum-lo-octets.0/24: https://datatracker.ietf.org/doc/html/rfc2770 My ASN is 29632, so the prefix is 233.115.192.0/24 I would like to start using it (well, for testing purposes now). To do so, I need a route object in the RIPE database. How can I create it?

5 6

2022-01 Resource holders identity
by denis walker 02 Jun '22

02 Jun '22

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

4 13

Re: [db-wg] 2022-01 Resource holders identity
by denis walker 31 May '22

31 May '22

Hi Tyrasuki On Tue, 31 May 2022 at 07:24, Tyrasuki <me(a)tyrasuki.be> wrote: > > Hi Denis, > > I assume yes, but has it already been suggested to go for a > middle-ground, and have resources possibly identified by for example, a > nickname / username? That could be quite complicated and not sure of the benefit. Especially with assignments. How would we know the same nickname was used each time for a specific person? > > As an example, I use Tyrasuki everywhere as my online nickname, and I > hold 4 PI assignments and 2 ASNs. But there is a PERSON and ORGANISATION object in the database with your full name and address details. These are linked to several INET(6)NUM and AUT-NUM objects. So your personal details are fully exposed. > > This would still make it possible for people to know I operate the > network, and I can then, on for example my personal site, list contact > details if I'd find this necessary. Contacts are not an issue. They can be fully documented without personal data (check out the thread on this list about contact details). cheers denis proposal author > > Or even on PeeringDB for that matter. :) > > (I might have possibly glimpsed over this a bit too quick if this was > already ruled out of the question) > > As for public interest, the only reason I could see it being relevant is > to know who to address in mails. > > PS: I am writing this directly instead of to the mailing list, as I'm > not sure if my points mentioned above make a lot of sense or not. (It's > currently 7:00 in the morning and I've been up all night debugging > hardware. :) ) > > Kind regards, > Tyrasuki > > https://tyrasuki.be > F587 F089 1655 A5E0 > > On 5/30/2022 1:17 PM, denis walker via db-wg wrote: > > 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(a)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 > > >

1 0

phone number required for person objects
by Cynthia Revström 26 May '22

26 May '22

Hi, TL;DR: stop requiring the "phone" attribute for person objects. This is something that I quickly brought up during the db-wg session at RIPE84 but thought would be good to bring up here as well. Currently you need to specify a phone number for person objects but not for role objects, which I think should be fixed (as in not require it for person objects either). While there is the argument to be made to not encourage use of person objects or whatever, I do think that we should make sure that they are functionally the same as to prevent people putting PII in role objects. This is so we can still keep track of how many personal contact objects there are, which would be more difficult if people used role objects for personal contacts. -Cynthia

6 20

2022-01 New Policy Proposal (Personal Data in the RIPE Database)
by Angela Dall'Ara 25 May '22

25 May '22

Dear colleagues, A new RIPE Policy proposal, 2022-01, "Personal Data in the RIPE Database" is now available for discussion. 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. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2022-01 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-710 We encourage you to review this proposal and send your comments to db-wg(a)ripe.net before 8 June 2022. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

5 8