- db-wg - mailman.ripe.net

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 11 Jul '22

11 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 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