- db-wg - mailman.ripe.net

2022-01 Personal data in the RIPE Database Next Steps
by William Sylvester 04 Aug '22

04 Aug '22

Dear Database Working Group Members, The four-week discussion phase for the policy proposal "2022-01 Personal data in the RIPE Database" ended on 15 July. In agreement with the proposer, we have decided tomove the proposal into the Review Phase but postponed its start to the end of August. This was done keeping in mind that the upcoming vacation period might prevent participation in the discussion and the timely publication of the RIPE NCC Impact Analysis. Please note that the RIPE Database WG Co-Chair Denis Walker is the author of this policy proposal, hence he is not taking part in the decisions regarding consensus. The RIPE NCC Policy Officer will announce the start of the Review phase together with the publication of the policy draft and impact analysis. For reference, here’s a short summary of the discussion so far: Ronald Guilmette posted many messages strongly opposing the proposal, advocating instead for the accurate verification of WHOIS data and for not publishing personal data for privacy reasons only in special legitimate cases. His main points of disagreement were: a) The transparency of the database would suffer, affecting LEAs’ and researchers’ work. b) The postal address is managed solely by the resource holder and not by the RIPE NCC. c) The postal address can already be concealed using, e.g., a PO box. d) Only a minority in the community is asking for the postal address not to be published, which doesn’t justify the effort and cost of implementation. e) More contact details might fall under the same new proposed rule in the future. f) Accepting the proposal would change the historical practice of the RIPE Database. g) There is no legal basis for the proposed changes. The proposer addressed the concerns above as follows: a) The transparency achieved is questionable if it's based on unverified data. b) End Users are not always aware that their address has been entered in the RIPE Database by the LIR. c) Addresses like those of PO boxes do not help LEAs orresearchers. d) Implementation could be supported using the existing ARCs. e) There is no mention of further changes in the proposal. f) Historical practice should not be treated as a requirement. g) Legal aspects should be further clarified by the RIPE NCC legal team. Niels Bakker supported the proposal as it would allow the RIPE NCC to offer a way to prevent LIRs from entering End Users’ personal data in the RIPE Database. Some ideas for modifying the proposal were posted: - Ronald Guilmette suggested to address the verification of contact details entered in the RIPE Database with a separate proposal that he would support, provided that the implementation challenges, costs, and consequences for non-compliance would be clarified. This would split the existing proposal in two: VERIFICATION and REDACTION. - Sylvain Baya, contributed to the discussion and also postedlinks to RIPE Labs articles published in the past about the proposal’s topics. He supported Ronald’s suggestion of allowing the RIPE NCC to accept the requests of exemption from publication of the Personally Identifiable Information (PII) made by natural persons who need Internet resources and can legally demonstrate their privacy requirement. Sylvain also suggested splitting the subject into a set of proposals: one about the general principles for processing data within the RIPE Database, one about *insertion* of PII within the RIPE Database, one about the *query* of the RIPE Database and one for handling the current PII present into the RIPE Database. - Leo Vegoda suggested clearly separating the sections defining a principle from those defining its implementation. - Cynthia Revström supported the proposal and suggested rewording the proposal clarifying that entering the full home address is never justified and that the default should be no address at all for individuals. The assumption should be that any address an individual is operating from is a home address unless the individual themselves clearly say that it is not. Please let me know if you have any questions. Kind regards, William db-wg Co-Chair

1 0

Re: [db-wg] NWI-13 Geofeed Legal Analysis
by Lutz Donnerhacke 28 Jul '22

28 Jul '22

So the geofeed attribute will be deleted from the database? Do you have a timeframe for this implementation? Von: db-wg <db-wg-bounces(a)ripe.net> Im Auftrag von Maria Stafyla via db-wg Gesendet: Donnerstag, 28. Juli 2022 13:33 An: db-wg(a)ripe.net Betreff: [db-wg] NWI-13 Geofeed Legal Analysis Dear colleagues, Following the legal update we provided on NWI-13: Geofeed at the DB WG session at RIPE 84, here is our analysis in case further discussion on this topic is needed. Executive Summary: - The RIPE Database is meant to contain specific information for its documented purposes. - Information inserted in the geofeed attribute could in some cases qualify as personal data. - The current purposes could explain geolocation information to be inserted only for ‘scientific research into network operations and topology’. - This purpose does not justify the processing of personal data; therefore restrictions had to be put in place to avoid the processing of unnecessary personal data. - The restrictions are now implemented based on the status of the registration. - If the purposes of the RIPE Database have changed in the meantime, this should be established via the community processes and documented. In that case we will re-evaluate the situation and the need for restrictions. Until then, the restrictions remain necessary. Legal Analysis: The RIPE Database is meant to contain specific information for the purposes that are defined in the RIPE Database Terms and Conditions. In terms of the _personal data_ inserted in there, the purpose that justifies its publication is to facilitate the coordination of network operations for the smooth and uninterrupted operation of Internet; this purpose explains why contact details of resource holders or their appointed contact persons are required. Before any new type of personal data is permitted to be inserted in the RIPE Database, we must evaluate if their processing is required for the purposes already defined and their processing can be considered in line with the basic personal data processing principles. Although it is the responsibility of the party inserting personal data to ensure that they have the appropriate legal grounds before doing so, the RIPE NCC has also shared responsibilities with regards to the personal data in the RIPE Database. This is because the RIPE NCC is the party that is making the RIPE Database available and implements the instructions given by the RIPE community. As mentioned in the Legal Review Impact Analysis, if the geofeed attribute is inserted for registrations of assignments that are reasonably assumed to be related to one individual user, then the attribute will be considered as containing personal data and GDPR will apply. This is why we have proposed to implement restrictions. These restrictions are essential to avoid any processing of personal data that is not required or necessary for the currently defined purposes of the RIPE Database and to limit the RIPE NCC's liability as a party with shared responsibilities in relation to the personal data inserted in the RIPE Database. Regarding the _(non-personal) data _inserted in the RIPE Database, it is also paramount that only data that is needed for the defined purposes of the RIPE Database is inserted. According to the RIPE Database Terms and Conditions, introducing the geofeed attribute (with restrictions) would be considered in line and acceptable to be used only for scientific research into network operations and topology (see Art. 3). We also understand that the purposes the RIPE Database must fulfil are not static but evolve over time. The RIPE Database Requirements Task Force has recently concluded its work and, with regard to geolocation, it has established that, although there is an active user group for geolocation data, geolocation itself is not an objective that the RIPE Database should fulfil. If the community's interests have changed since then and it is now agreed that geolocation is one of the purposes the RIPE Database must fulfil, this should be decided via the community's processes and reflected in the RIPE Database Terms and Conditions. In line with the data management principles proposed by the RIPE Database Requirements Task Force, it would be prudent to approach this issue holistically, taking into account that other geolocation information is already provided in the RIPE Database (i.e. geoloc, country code attributes in ORG and resource objects). On the basis of a new purpose for the geolocation information, we could then reassess the situation to understand whether the restrictions on the geofeed attribute are still necessary or whether it is justified to process personal data for this purpose. Kind regards, Maria Stafyla Senior Legal Counsel RIPE NCC

4 3

IRT object postal address
by denis walker 24 Jul '22

24 Jul '22

Colleagues During the conversion we had some time ago about contacts we concluded that no one is going to visit a contact or post them a letter. The IRT object also had a mandatory address attribute that is defined in the documentation as: "This is a full postal address for the business contact represented by this irt object." Does anyone think we actually need a postal address for a contact for a CSIRT team? Cheers denis

5 7

Re: [db-wg] IRT object postal address (denis walker)
by William Weber 22 Jul '22

22 Jul '22

As cybercriminal i wholeheartedly support the idea of removing all personal data from the RIPE DB. That would make my life so much easier. -- William On Fri, Jul 22, 2022 at 12:00 PM <db-wg-request(a)ripe.net> wrote: > Send db-wg mailing list submissions to > db-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.ripe.net/mailman/listinfo/db-wg > or, via email, send a message with subject or body 'help' to > db-wg-request(a)ripe.net > > You can reach the person managing the list at > db-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of db-wg digest..." > > > Today's Topics: > > 1. Re: IRT object postal address (denis walker) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 21 Jul 2022 15:41:58 +0200 > From: denis walker <ripedenis(a)gmail.com> > To: "Ronald F. Guilmette" <rfg(a)tristatelogic.com> > Cc: Database WG <db-wg(a)ripe.net> > Subject: Re: [db-wg] IRT object postal address > Message-ID: > < > CAKvLzuE+RoNgGXL8TU3r4E5dOtOd3uweB9UzFJhgnOmpBruU+g(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Ronald > > (For those who don't read long emails...) The bottom line is that this > proposal recommends to remove postal addresses of contacts, not > publish the 'full' postal address of natural persons holding > resources, replace personal data with business data and generally > bring the contents of the RIPE Database into line with the defined > purposes. > > --- > Now to answer Ronald's points... > > You have your own (hidden) agenda Ronald, which is fine. But don't > expect everyone to fall into line behind you. Most people know your > tactics. Repeat the same nonsense and conspiratorial theories over and > over and over again until people believe they must be true. You lock > onto a phrase or even a word and create an entire fear mongering story > around it. Then keep asking the same irrelevant questions and > demanding answers. This is not how to have a professional discussion, > it is a Trump/Johnson style campaign. > > Let's kill off some of your fear stories. I am NOT against > accountability, NOT helping cybercriminals, NOT proposing anonymity, > NOT obfuscating half the database, NOT proposing secrecy and NOT > avoiding transparency. > > As for GDPR, the only person obsessed with it is you Ronald. It is not > even mentioned in the proposed policy text. You use it to confuse all > discussions on the content of the database. GDPR is only one of the > factors concerning the content of the RIPE Database. There are defined > purposes for the database. As the RIPE Database Task Force pointed > out, we should minimise the amount of data needed to fulfil those > defined purposes. That is the overriding principle governing what > should go into the database and what remains in the database. > > Most people did accept that in order to resolve internet operational > issues (one of the main purposes of the database) no one is going to > visit or post a letter to a contact in the RIPE Database. Therefore > contacts don't need postal addresses. Whilst you may feel there is a > need for a postal address for a contact for an IRT object, as Nick > said, the opinions of CSIRT teams are more relevant. > > You have said yourself many times that the database is full of > garbage. When you demand irrelevant data and force people to enter > information they prefer not to provide which is not even covered by > the database purposes, you increase the chances of some people > entering false or misleading information. The only 'crusade' I am on > is to bring the contents of the RIPE Database into line with the > minimum information required to fulfil the defined purposes of the > database and any legal requirements. We can have a healthy discussion > on interpretations of that minimum information, but we should not be > arguing over the principle. Forcing people (with mandatory attributes) > to enter 'interesting' but not relevant information leads to a corrupt > and diluted database that is less useful to anyone. Even optional > attributes that are not relevant, dilute the important information. > > You can wish for any information you like to be in the RIPE Database > Ronald, but if it is not essential for the defined purposes, it is not > going to be there. Feel free to propose your own policies to change > the purposes of the database and store certified photos of all > contacts and their families if you believe that is necessary for your > use of the database...or set up your own database. > > cheers > denis > proposal author > > On Thu, 21 Jul 2022 at 06:01, Ronald F. Guilmette via db-wg > <db-wg(a)ripe.net> wrote: > > > > In message < > CAKw1M3MEHHC63+BfS7P365F0Cw6hcGuOKKq0ZaTS+evtdiZDoQ(a)mail.gmail.com> > > =?UTF-8?Q?Cynthia_Revstr=C3=B6m?= <me(a)cynthia.re> wrote: > > > > >> *) Why is the hiding of information even a priority? > > > > > >Hiding information is good from a privacy standpoint so you have to > > >weigh the benefit of having the data public against the privacy > > >implications of publishing it. (and consider any potential legal > > >issues/requirements) > > > > Transparency is good from an accountability standpoint. And in my > opinion, > > we have far far too little accountability on the Internet. Practically > > every day now one can find stories about "hackers" and "cybercriminals" > > and everyone just shrugs and goes back to work as if this is the way that > > thing have to be, or that they are supposed to be. > > > > My position is simple: If youy want to be anonymous, then get yourself a > > pseudonym account on Twitter, or Facebook, or YouTube, or whatever, and > > then blast away. Or alternatively, get yourself a domain name with all > > of the WHOIS data redacted and then arrange wweb site hosting for that, > > either on one IP of one hosting company, or several. But somewhere up > > the chain there needs to be accountability, always. It is *not* a God- > > given right to have an IP address block or an ASN. It is a privilege. > > And that special privilege should be reserved for those who are willing > > to be held accountable for what goes on upon their networks. > > > > You and Denis are trying to _remove_ accountability from the equation, > and > > I remain steadfast in asserting that this will only benefit criminals. > > > > >> *) Are these deliberate obfsucation steps still being justified on > the > > >> basis of GDPR, or do you now accept as fact that GDPR is irrelevant in > > >> the context of the RIPE data base, and that it does not currently > compel > > >> RIPE to make any changes to the public WHOIS data base whatsoever? > > > > > >Denis has already mentioned in an email regarding 2022-01 that he will > > >not address any more GDPR issues until there has been a legal review > > >as many of us are not lawyers. > > > > I'm sure that I saw someone post here quite recently that he had checked > with > > RIPE legal already, and had already been assured that RIPE is _not_ > facing > > any current or imminent legal jeopardy with the status quo as it now > exists, > > either in relation to GDPR or in relation to any other applicable law or > > regulation. If you need me to do so, I will find that posting in the > archives > > and I'll copy it here. > > > > >While I can't speak for Denis, you have not convinced me that GDPR is > > >somehow irrelevant > > > > I don't see how or why it should be incumbant upon either me or anyone > else > > to persuade either you or Denis that no change needs to be made. You > and he > > are putting forward and supporting this proposal for a _change_ in the > > current status quo. It is thus necessary for you folks to make a > persuasive > > case that a change _is_ needed, rather than for me or anyone else to > make a > > case that it isn't. > > > > >> *) If the goal is to hide information, then why not just take the > entire > > >> RIPE WHOIS data base offline and hide the whole thing behind some > sort of > > >> permission-wall that can only be pierced with a legal warrant? > > >> > > >> (That last question is, of course, the essential point, since that > endpoint > > >> seems rather clearly to be the direction in which this is all headed.) > > > > > >This question is not really an "essential point" in my opinion as > > >there is a big difference between hiding postal addresses and hiding > > >abuse email addresses and route(6) objects. > > > > You are doing just what Denis has done so far in relation to this whole > > thing... You are evading the question. If transparency is "bad" and > > secrecy is "good" then why not take that general principal to its final > > and logical conclusion? Why not just take the whole WHOIS data base > > offline entirely? > > > > It's a simple question. I'd like to see either you or Denis answer it, > > rather than evade it. > > > > > > 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/db-wg > > > > ------------------------------ > > Subject: Digest Footer > > -- > > 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 > > > ------------------------------ > > End of db-wg Digest, Vol 131, Issue 14 > ************************************** >

2 1

New Version of the RIPE Database Documentation is Available
by Edward Shryane 20 Jul '22

20 Jul '22

Dear Colleagues, The DB team are pleased to announce that a new version of the RIPE Database documentation is now available: https://apps.db.ripe.net/docs/ We are using a common framework that we have across many RIPE NCC technical services, such as RIPEstat, RIPE Atlas, RIS and RIPE IPmap. This framework has some advantages: * Allows us to use a more modern layout that is common across these services. * A built-in search field is now available at the top of each page. * The documentation is stored in Markdown format, making it easier for the team to make changes, and accept outside contributions. * We are now able to deploy changes together with a Whois or DB web application release. Under the hood, the new documentation uses the VuePress framework: https://vuepress.vuejs.org If you prefer not to use JavaScript, or to print or save the entire documentation, it is also available on a single page: https://apps.db.ripe.net/docs/entire-documentation-(HTML) The documentation contents are published on GitHub, please create a pull request or an issue to contribute improvements: https://github.com/RIPE-NCC/ripe-database-documentation Finally, we plan to migrate (redirect) the existing RIPE Database Documentation pages to the new site. https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… Regards Ed Shryane RIPE NCC

2 6

Impact Analysis for Removing Whois Object Tags
by Edward Shryane 14 Jul '22

14 Jul '22

Dear Colleagues, Following is an impact analysis for removing Whois object tags from the RIPE database. Please reply with any questions or comments. Whois object tags was added as a beta feature in 2013: https://labs.ripe.net/author/kranjbar/presenting-object-metadata-in-the-rip… All resources were tagged at that time (inetnum, inet6num and aut-num), but the data was never updated since then. We plan to remove this feature in the next Whois release, both the query flags and tag data. This will impact the RIPE database in the following ways. (1) Tag Data The following tags exist: RIPE Database: RIPE-REGISTRY-RESOURCE and RIPE-USER-RESOURCE AFRINIC Mirror Database: AFRINIC-USER-RESOURCE and AFRINIC-REGISTRY-RESOURCE APNIC Mirror Database: APNIC-USER-RESOURCE and APNIC-REGISTRY-RESOURCE ARIN Mirror Database: ARIN-REGISTRY-RESOURCE and ARIN-USER-RESOURCE Once support for tags are removed, all tag data will be removed from all databases. (2) Whois Query Flags Four query flags were added to support tags: % --no-tag-info % Switches off tagging information. % % --show-tag-info % Switches on tagging information. % % --filter-tag-include % Show only objects with given tag(s) % % --filter-tag-exclude % Do not show objects with given tag(s) Tags are not returned in port 43 queries by default. I have not found these flags in recent query logs for port 43, i.e. they are not used. Once support for tags are removed, an error will be returned if they are used in a query, e.g. % Invalid option: --no-tag-info % %ERROR:111: invalid option supplied % % Use help query to see the valid options. (3) REST API The query flags for tags are not supported by the Whois REST API. If any are included in the "flags" query parameter in a search, a 400 Bad Request is returned. However tags are returned by the Whois search and lookup endpoints by default, if present, within the /whois-resources/objects/object/tags/tag element. Once support for tags are removed, they will not be returned by the Whois REST API. (4) Web Application Query and Lookup The DB web application query and lookup pages uses the Whois REST API. However tags are not displayed if returned by the REST API. (5) Database Dump and Split Files The nightly database dump and split files contain tags as a comment following some resources, e.g. % Tags relating to 'AS3333' % RIPE-REGISTRY-RESOURCE Once support for tags are removed, these comments will not appear between RPSL objects. Regards Ed Shryane RIPE NCC

1 0

Non-RIPE INRs in an Example returned by RIPE Whois DB Query Service
by Sylvain Baya 12 Jul '22

12 Jul '22

Dear DB-WG, Hopefully this email finds you in good health! While exploring some RIPE Whois DB classes [1], i discovered some examples, i thought to be inappropriate [3]. ...i would like to draw to your attention, on the presence of some INRs [2] managed [3] by an other RIR, which appear in content returned when the RIPE Database is queried [2]. __ [1]: <paste1> cacty@shalom:~$ whois -h whois.ripe.net -t route | grep --regexp="^holes" --after-context=0 holes: [optional] [multiple] [ ] </paste1> [2]: <paste2> cacty@shalom:~$ whois -h whois.ripe.net -v route | grep --regexp="^holes$" --after-context=11 holes Lists the component address prefixes that are not reachable through the aggregate route(perhaps that part of the address space is unallocated). An address prefix is represented as an IPv4 address followed by the character slash "/" followed by an integer in the range from 0 to 32. The following are valid address prefixes: 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and the following address prefixes are invalid: 0/0, 128.9/16 since 0 or 128.9 are not strings containing four integers. </paste2> [3]: <https://www.iana.org/assignments/ipv4-address-space/> Maybe it's the only description which contains such non-RIPE INRs; other than of RFC 5737 [4]... __ [4]: <https://www.iana.org/assignments/iana-ipv4-special-registry/> ...but perhaps someone, from the Staff, should check? Thanks. Shalom, --sb. -- Best Regards ! baya.sylvain [AT cmNOG DOT cm] |cmNOG's Structure <https://www.cmnog.cm/dokuwiki/Structure>|cmNOG's Surveys <https://survey2.cmnog.cm/> Subscribe to the cmNOG's Mailing List <https://lists.cmnog.cm/mailman/listinfo/cmnog/> __ *#‎LASAINTEBIBLE‬|‪#‎Romains15‬:33«*Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!*»‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬«*Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!*» (#Psaumes42:2)*

3 6

2022-01 personal data in the "descr:" attribute
by denis walker 06 Jul '22

06 Jul '22

Colleagues Up to now we have focused mostly on member's personal data. But this isn't only about members. The database contains lots of personal data for end users as well. The INET(6)NUM objects have a "descr:" attribute. This has been used extensively for (personal) data about end users, mostly name and address, but maybe also phone numbers. There may well be more of these who are natural persons than members. There are 4.2m INETNUM objects in the database. So the scale of the problem may be far higher here. This is also a more complicated problem. The data is entered by resource holders and possibly multiple levels of sub-allocation holders. The issue of informed consent is hard to judge. Consent may be in the small print of a contract and it may not be clear to the data subject just what they are consenting to. The RIPE Database may contain the home address of many end users without them knowing what this database is or what the consequences are of publishing their personal data in it. This data is also unstructured, unverified, undefined free text. As with member's data there are pros and cons regarding the usefulness of this data. Also the defined purposes of the database cover adding the name and phone number of an end user as part of the public registry, but again not their home address. With the data being undefined, it is not clear what any address relates to. We don't know what address the resource holder asked for or what address the end user supplied. The address, therefore, has no meaning to anyone reading this data. So the question we need to discuss is what do we do with this data in the "descr:" attributes? Perhaps I can start the discussion with a suggestion. First of all we should never overload free text attributes with structured data. So if we want to add a name and address to resource objects we should include user name and address attributes. If we are going to add a new address field we should break it down into a structured set of address attributes, as all addresses should have been from the start. Maybe a phone and/or email attribute is also needed, keeping in mind most end users don't usually have an ORGANISATION object. Any new attributes can all be optional, as it is by choice that resource holders currently add any such data into the "descr:" attributes. The same rules would apply to this data as we have discussed with the members' data. Phone and email must be business data and not personal and they will be verified. (I will explain more about verification in response to Leo's email.) Name may be personal if the end user is a natural person. In that case any optional address added must not be more specific than country and region. Another possible solution could be to optionally create an ORGANISATION object for end users. Either way, this data should not be in the "descr:" attribute. Most of this can be discussed later with the implementation details. What is really important as far as this policy proposal is concerned is the recognition that the same principles of processing personal data will be applied to end users as it is to members, regardless of what objects the data is stored in. cheers denis Proposal author

2 3

Thoughts on 2022-01
by Leo Vegoda 01 Jul '22

01 Jul '22

Hi, Thank you for producing this proposal. It's important to regularly review policy and implementation to ensure we are meeting our legal responsibilities. Parts of the text in this proposal are clear and easy to interpret. For example section 3.0 on Notifications is well written. Other parts are highly ambiguous. The text as written would just lead to disputes. For example, "Email addresses added as contact details and all phone and fax numbers entered into the RIPE Database must be verified." Who must verify them, what must they verify, and when should this happen? Is this just a check that the contact information is syntactically correct? Or is this a check that a fax machine is active and used by the organization listed alongside it? It would be helpful to clearly separate the sections defining a principle from those defining an implementation. The text on verification and compliance is so ambiguous that it's not possible to understand what an implementation would look like. Kind regards, Leo Vegoda

2 2

2022-01 v2 Personal Data in the RIPE Database
by Cynthia Revström 29 Jun '22

29 Jun '22

Hi db-wg, I just want to say that I mostly support the current proposal of 2022-01 (v2). I would prefer it if the following section was reworded in some way to make it more clear how the full home address is never justified and how the default should be no address at all for individuals. Also I think it should be changed to assume that any address an individual is operating from is a home address unless the individual themselves clearly say that it is not a home address. I would still support it in its current form without these changes but I would strongly prefer if these were made to prevent any confusion or ambiguity. (this section is part of 1.0 Organisations) <quote> The name of the organisation (which may be the personal data of a natural person) holding an Internet resource or managing part of an Internet resource, for example a sub-allocation, or using a block of addresses, is an essential part of the public registry. This identification is one of the principal purposes of the database. Any valid address could be helpful. Different types of addresses can be considered including postal addresses. The name and address of a natural person holding or using a resource and operating from a home address are the only personal data that can be justified to be published in the RIPE Database, provided there is documentary evidence held by the RIPE NCC, or a sponsoring LIR, or any resource holder that registered the subject’s details in the RIPE Database, that the natural person has consented to their name and address being published in this public registry. This consensual identification is a requirement of the public registry for holding an Internet resource or managing or using part of an Internet resource. A postal address may optionally be added by the resource holder or manager. Where the resource holder, manager or user is a natural person, the parts of any type of address more specific than country and region must not be entered in any object attribute. </quote> -Cynthia

1 0

Re: [db-wg] Request for the correct review of document link
by Christian Nzhie 29 Jun '22

29 Jun '22

> > Good morning folk, I was reading this archive on the folowing link > https://www.ripe.net/ripe/mail/archives/db-wg/2022-June/007459.html > and I saw this > > The PDP document can be found at:https://www.ripe.net/publications/docs/ripe-710 > > However, when I click on the above link to review the proposal, I am > seeing the following red notice: This document is obsoleted by ripe-781 > <https://www.ripe.net/publications/docs/ripe-781> > So, please, kindly provide the correct link of version 2 under review... > Thanks in advance... > Christian Nzhie. >

2 1

RIPE Database Quarterly Planning Q3 2022
by Edward Shryane 29 Jun '22

29 Jun '22

Dear colleagues, We have published our quarterly plans for Q3 2022 for the RIPE Database: https://www.ripe.net/manage-ips-and-asns/db/quarterly-planning We recently made usability improvements to the website and in this quarter we’re planning on migrating the RIPE Database documentation to a new interface. We will announce on the list when this is ready. The goal of our quarterly planning is to communicate the work we’re doing for the coming months, get your input and start a discussion on other developments we should work on. If you have comments or questions around this, we hope you'll let us know on the list or you can always contact the DB team directly at ripe-dbm(a)ripe.net . Regards, Ed Shryane RIPE NCC

1 0

Updating Descr part of object with # results in No Operation
by Sascha E. Pollok 28 Jun '22

28 Jun '22

Hi everyone, I just tripped over something today which I have never noticed after >20 years of using the RIPE DB :-) It might be explained somewhere but I haven't found anything so here it is. I am updating an inetnum object from: descr: Testobject Ticket #12345 to descr: Testobject Ticket #123456 using Syncupdate. This results in a "No Operation" (Warning: Submitted object identical to database object). Is this intentional? It works if I remove the # and add it again in a second step. I assume it's something about it being interpreted as a comment but even if that's the case, I should still be able to update it. Can someone enlighten me? Thank you and best regards Sascha

4 7

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

28 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 14 Jun '22

14 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 01 Jun '22

01 Jun '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

Decision on NWI-2 Historical queries
by denis walker 18 May '22

18 May '22

Colleagues When I wrote the spec for historical queries, almost 10 years ago, I included an arbitrary constraint to only show history back to the most recent deletion point. This was to get something in production quickly and see how useful it was. Over the years several people have asked for this arbitrary constraint to be removed. No one has objected to removing it. The co-chairs therefore recommend that this arbitrary constraint be removed. The co-chairs now ask the RIPE NCC to produce an impact analysis and implementation plan to remove it. We will then seek a final approval from the community on the plan. cheers denis co-chair DB-WG

5 10

Impact Analysis for UTF-8 in the RIPE Database
by Edward Shryane 12 May '22

12 May '22

Dear Colleagues, The RIPE NCC was requested by the Database Working Group to perform an impact analysis for UTF-8 in the RIPE Database, including the technical and functional effects on the RIPE NCC itself. How would the RIPE Registry function with UTF-8? And what would be the impact on running the Registry? The RIPE NCC has now published a RIPE Labs article detailing the impact analysis: https://labs.ripe.net/author/ed_shryane/impact-analysis-for-utf-8-in-the-ri… Regards Ed Shryane RIPE NCC

1 0