- db-wg - mailman.ripe.net

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

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

DB Task Force Recommendations
by denis walker 11 May '22

11 May '22

Colleagues The chairs propose creating a series of NWIs to address the recommendations recently made by the Database Task Force that are considered to be relevant to the DB-WG. NWI-15 Baseline requirements for registration information NWI-16 Using RIPE Database as an IPAM solution NWI-17 Historical data NWI-18 Operational Contact Information They can all reference this page as the Problem Definition https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/database-requi… cheers denis co-chair DB-WG

2 1

Agenda RIPE84 - Database Working Group
by William Sylvester 09 May '22

09 May '22

Dear Database Working Group Members, Below is the agenda for the Database Working Group for RIPE84. If you would like to present, have questions, comments, or requested changes please let the chairs know. Best regards, William & Denis DB-WG Chairs A. Introduction - 10 min * Welcome * Scribe * Jabber * Chairs & Succession Planning * Agenda B. NWI Update – 20 mins Denis Walker, Co-Chair DB-WG C. Operational Update– 20 mins Edward Shryane, RIPE NCC D. Personal Data in the RIPE Database – 20 mins Denis Walker, Co-Chair DB-WG Z. AOB (open discussion)

1 0

NWI-1 Staying on top of abuse contact changes
by denis walker 09 May '22

09 May '22

Colleagues There has been no interest in this item for several years so the chairs recommend cancelling NWI-1. We ask the RIPE NCC to mark it as 'Cancelled'. cheers denis co-chair DB-WG

1 0

Whois Release 1.103
by Edward Shryane 09 May '22

09 May '22

Dear Colleagues, RIPE Database release 1.103 has been deployed to the Release Candidate environment. We plan to deploy to production on Monday 9th May. The database in the Release Candidate environment has been reloaded with dummified production data from 20th April. This release includes the following main changes: • Fixed "goefeed:" validation when reading object containing multiple remarks: attributes (#975) • Removed WHITEPAGES org type. (#1003) • Better Error Message when Changing "mnt-by:" on Allocations (#988) • Allow user "mnt-by:" when creating inet6num allocations (already allowed for inetnums) (#982) • Disallow weak keys and hash algorithms (#642, #974) • Abuse-c is Required for End User Organisations With Resources (#955, #969) • Domain overlap validator (#956) • Increase HTTP idle timeout from 30s to 60s (#998) The release notes are on the website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… More information on the Release Candidate environment can be found on our website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Update: NWI-2, NWI-4, NWI-8
by denis walker 03 May '22

03 May '22

Colleagues The RIPE NCC is working on an impact analysis and new legal review for NWI-2 Historical Queries. The chairs ask the RIPE NCC to also produce an impact analysis on NWI-4 Status Value based on the addition of a new value 'ALLOCATED-ASSIGNED PA' The chairs ask the RIPE NCC to mark NWI-8 as 'Finished (Stage 2 Cancelled)' cheers denis co-chair DB-WG

2 1

Missing org: fields for direct allocations from RIPE
by Ronald F. Guilmette 30 Apr '22

30 Apr '22

Some considerable time ago I previously noted here the fact that there exists in the RIPE WHOIS data base some WHOIS records for what I personally would refer to as "top level" IP address block allocations (i.e. ones which were assinged directly by RIPE NCC to some specific RIPE member organization) and that contain no org: field which would otherwise associate these blocks with a specific organisation having its own organisation: record in the data base. At that time, I was basically told (by denis, as I recall) that this was a historical artifact in the data base, that it would absolutely NOT be rectified, and that I should go pound sand. Having long ago become resigned to this level of respectful helpfulness when raising legitimate issues relevant to the RIPE data base here, I let it go, and I have not raised the issue again since that itme. Now however I feel that I have some clear and concrete basis for doing so. I call everyone's attention to the following post that I just made to the mailing list of the RIPE Anti-Abuse Working Group: https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2022-April/006346.html I should say that it is my (naive?) belief that (a) every operator of an inbound mailbox or an inbound mail server should have the right to decide for themselves when any given network is not worthy of having its inbound emails accepted, and also (b) RIPE and the RIPE WHOIS data base should not make the task of locally filtering inbound packets or emails from a given network any harder than it needs to be. As noted in the mailing list post linked to above, it is my desire to locally block all further inbound emails from the entire set of IPv4 CIDRs currently associated with the Dutch network which is alternatively known as Signet B.V. and/or TransIP B.V. (These people are clearly lack the requsite minimal level of competence to run a network from which outbound emails emmanate.) In any universe guided by either reason or simplicity it should be easily possible to find the ORG handle for any given (offending) network and then to use that handle as a "reverse" lookup key in a query to the relevant RIR data base and thus automatically derive the full set of IP address blocks currently assigned to the given organization. Unfortunately, and for reasons that have yet to be adequately explained, we do not live in that simple or rational universe, at least not when it comes to the RIPE WHOIS�data base. For quite some time now I have had a relatively trivial Perl script that does this exact job. I call it "org2cidrs". It works flawlessly when provided an ORG handle known to any one of the five Regional Internet Registries, except in the case of RIPE where, as I have noted above, some IP block allocations have no org: field and thus no connection to any particular organisation... at least none that could be automatically determined by a reverse WHOIS query based on some ORG handle. The bottom line is that although I have found it quite easy to deduce that the handle ORG-SI6-RIPE represents the offending organization that I would now like to block, a reverse (org) WHOIS query against the RIPE WHOIS server using that handle yields only a subset of the IP block allocations currently assigned to that organisation. More specifically, although the vast majority of IP blocks assigned to this organization do in fact have corresponding WHOIS records in the data base that -do- contain an org: field designating ORG-SI6-RIPE as the registrant organization, the following two blocks, both marked as "status: LEGACY", have no org: field present in their respective RIPE WHOIS records, and thus these allocation records are effectively invisible to any reverse WHOIS query using -any- ORG handle (e.g. ORG-SI6-RIPE) as lookup key: 136.144.128.0/17 157.97.168.0/22 I don't know how to say this delicately, so I will just say it. It is, in my opinion, fundamentally idiotic that every other one of the five Regional Internet Registries make it trivially easy to find ALL of the IP allocations associated with a given ORG handle, but that RIPE, for reasons that are apparently shrouded in mystery and/or which have long ago been lost to the sands of time, continues to insist on making what should be simple difficult. The last time I checked there were only on the order of about 122 "top level" RIPE IP block allocations whose corresponding WHOIS records failed to include an org: field. In each of these cases it would be trivially possible for RIPE NCC to manufacture an appropriate organization: record out of the information already in the data bases and/or information which is readily available on the web or from the actual organizations themselves. Once these new organisation: records were created it would also be trivial for RIPE NCC to insure that every single IP block allocation in the data base is associated with some ORG handle, thus simplifying automated processing of the data base -and- bringing its functionality into line with that of the other four RIR data bases. The fact that this has not already been done, especially in a case like the legacy blocks which clearly belong to ORG-SI6-RIPE, is, I think, indicative of some narrow-minded insistance on the preservation of past practices, even when those practices are, as in this case, provably detrimental to reasonable and serious users of the data base. Regards, rfg P.S. I have always and will always argue in favor of anything that simplifies the parsing and/or automated processing of WHOIS data base records. Having *every* IP block allocation record include an org: field would do just that. Furthermore, quite frankly I am both flummoxed and flabberghasted that a call was made here, some time ago, for suggestions on how to make it simpler to parse the data base, EVEN AS my simple, straightforward, and (I would have thought) obvious suggestion to represent all handles in the data base only and consistantly in upper case garnered -no- response from this working group whatsoever.

2 3

NWI-8 LIR´s SSO Authentication Groups
by denis walker 25 Apr '22

25 Apr '22

Colleagues This work item had two defined stages. Stage 1 was to introduce a default authentication group for LIRs. This has been implemented and is in widespread use now. Stage 2 was to introduce user defined authentication groups. This has had no discussion with little support or objection. If anyone feels this would be a useful extension please let the working group know. Otherwise the co-chairs will recommend that stage 2 is cancelled and NWI-8 is marked as Finished. cheers denis co-chair DB-WG

1 0

NWI-4 status for an assigned allocation
by denis walker 25 Apr '22

25 Apr '22

Colleagues This has been discussed over many years. The co-chairs recently asked the RIPE NCC to produce an impact/implementation report on the suggestion to introduce a new status value 'ALLOCATED-ASSIGNED PA'. This had one supporter and one objection. The objection was basically that 'something' will break. As I have since pointed out, the status values and structure has been changed several times over the years and nothing significant broke. Do we have any final comments before the RIPE NCC produces an impact/implementation report on this suggestion? cheers denis co-chair DB-WG

1 0

NWI-2 historical queries
by denis walker 25 Apr '22

25 Apr '22

Colleagues Over the last few years several community members have asked for the arbitrary restriction on deleted objects in historical queries of operational data to be removed. The DB-WG co-chairs recently recommended that the RIPE NCC goes ahead with producing an impact/implementation report, including a new legal review. Since then we have had one objection based on privacy of data. I believe I have addressed that issue in some detail. The co-chairs recommend that the RIPE NCC goes ahead with publishing a new impact/implementation report o this issue. cheers denis co-chair DB-WG

1 0

New NWI for geofeed?
by denis walker 14 Apr '22

14 Apr '22

Colleagues [Apologies for the length of this email...] The chairs would like to suggest creating a new NWI for the "geofeed:" attribute and suggest the following draft Problem statement and Solution definition. If there is agreement on this the RIPE NCC will do an impact assessment including legal review and summary of what the other RIRs are doing. There has already been quite a discussion in the WG on this issue with a lot of support. So hopefully we can reach a consensus quickly, at least on setting up the NWI and starting the impact assessment. Having read the latest draft IETF docs, there are some outstanding questions. Comments and changes are welcome... cheers denis co-chair DB-WG Problem statement Associating an approximate physical location with an IP address has proven to be a challenge to solve within the current constraints of the RIPE Database. Over the years the community has chosen to consider addresses in the RIPE Database to relate to entities in the assignment process itself, not the subsequent actual use of IP addresses after assignment. The working group is asked to consider whether the RIPE Database can be used as a springboard for parties wishing to correlate geographical information with IP addresses by allowing structured references in the RIPE Database towards information outside the RIPE Database which potentially helps answer Geo IP Location queries The IETF is currently discussing an update to RPSL to add a new attribute "geofeed: url". The url will reference a csv file containing location data. Some users have already started to make use of this feature via the "remarks: geofeed: url". It is never a good idea to try to overload structured data into the free format "remarks:" attribute. This has been done in the past, for example with abuse contact details before we introduced the "abuse-c:" attribute. There is no way to regulate what database users put into "remarks:" attributes. So even if the new "geofeed:" attribute is not agreed, the url data will still be included in the RIPE Database. Currently there are 24,408 INETNUM and 516,354 INET6NUM objects containing a "remarks: geofeed: url" attribute in the database. These have 7,731 distinct values in the INETNUMs and 1,045 distinct values in the INET6NUMs. Solution definition Implement a new "geofeed:" attribute according to the IETF's definition. Although the IETF has not yet concluded discussions on this attribute we can still implement it in the RIPE Database RPSL data definition. The RIPE Database already has many local differences to the RPSL standard. As expressed in the Problem statement, users are already using the geofeed data by overloading the "remarks:" attribute. That is a dirty hack which should be avoided. An invalid formated url will be a syntax error. The RIPE NCC will perform a one time conversion of the existing data to convert "remarks: geofeed: url" to "geofeed: url". If an update then contains a "remarks: geofeed: url" attribute, the update will be successful and the response should include an appropriate Warning message. At some point in the (near) future, this could be changed to an update failure as a syntax error. An update containing a "geofeed:" and a "remarks: geofeed:" attribute or more than one "remarks: geofeed:" will be a syntax error. The resource holder should be able to create, modify, delete the "geofeed:" attribute in allocation objects. Questions: -Should the database software do any checks on the existence/reachability of the url as part of the update with an error if the check fails? -Should the RIPE NCC do any periodic repeat checks on the continued existence/reachability of the url? -Should the RIPE NCC do any periodic checks on the content structure of the csv file referenced by the url? -Should the Solution definition define how this will be adopted into RDAP or should we simply ask the RIPE NCC to define this in their impact assessment? -The RIPE Database contains hierarchical address space objects. Should it be acceptable for "geofeed:" attributes to exist at multiple levels within a specific hierarchy? -Suppose a geofeed csv file referenced by a /16 INETNUM object contains location data for the whole /16. Then a more specific /24 INETNUM object references another geofeed csv file that contains conflicting location data for this /24. Should this be a concern for the RIPE Database? -Should geofeed data be inherited? If you query for a /24 that does not contain a "geofeed:" attribute, but a less specific /16 does contain a "geofeed:" attribute, should this data be returned? In other words could it be used in a similar way to "abuse-c:"? -Thinking ahead to how people will actually deploy this data and what short cuts they could make. It is said that when reading a geofeed csv file, consumers of the data should ignore all data within that file not directly concerning the address space queried in the RIPE Database. Could you therefore create a single csv file with location data for all your address space and reference the same file in all your RIPE Database address objects? The address space owner could rely on the data consumer to pick out the correct piece of data for the relevant address space. The manager of the csv file then only has to work with one file. If this is possible and does happen (which the IETF doc 'Finding geofeeds' seems to suggest is possible for unsigned geofeed data), would it therefore make sense to apply "geofeed:" hierarchically as with "abuse-c:"? Allow a single, default "geofeed:" attribute in the ORGANISATION object to be applied to all that organisations address space, with the option of specific localised "geofeed:" attributes in address space objects. That could be a neater solution, and easier to setup, than applying thousands of references to the same geofeed file at a more specific level in the database. -Relating to the above 3 questions, should geofeed data only be considered applicable if returned by a specific geofeed locater application which takes into account the hierarchical nature of address space in the database? Otherwise do the standard database query mechanisms have to take into account this hierarchy and locate the most specific "geofeed:" attribute from the less specific objects? -Should/could the RIPE Database return the csv file as part of the query? If so should the file be cached (for how long?) to avoid too many downloads? -Should we only allow HTTPS urls? (Which the IETF doc 'Finding geofeeds' seems to suggest) -Should the RIPE NCC go ahead and implement this now, with our own set of RIPE rules? Or should we try to coordinate this and agree a set of common rules between all the RIRs before any deployment in the RIPE Database? -For the legal review, there are 2 statements in the IETF doc 'Finding geofeeds' which may be of concern: *[RFC8805] geofeed data may reveal the approximate location of an IP address, which might in turn reveal the approximate location of an individual user. Unfortunately, [RFC8805] provides no privacy guidance on avoiding or ameliorating possible damage due to this exposure of the user. In publishing pointers to geofeed files as described in this document the operator should be aware of this exposure in geofeed data and be cautious. All the privacy considerations of [RFC8805] Section 4 apply to this document. *It is significant that geofeed data may have finer granularity than the inetnum: which refers to them. It is clear that the RIPE NCC cannot prevent this data being referenced by objects in the RIPE Database. It is already being referenced from "remarks:" attributes. Perhaps the RIPE NCC should require (as part of their service agreement) that it's members obtain written consent from their customers to publish this location data, or at least inform the customers in writing that it will be published. Also, although RFC8805 says postcode is deprecated it is still provided for in the csv files. So anyone can still enter location data to this detail. -The IETF doc 'Finding geofeeds' suggests that geofeed information 'will be' available in bulk accessed whois data. In view of the privacy concerns above, is this likely? -The IETF doc 'Finding geofeeds' says "To minimize the load on RIR whois [RFC3912] services, use of the RIR's FTP [RFC0959] services SHOULD be the preferred access." Is the RIPE NCC expected to download all the geofeed files and make them available through their FTP service? -The IETF doc 'Finding geofeeds' states that consumers of the geofeed data MUST NOT access this data in real time via the RPSL servers 'too frequently' or at 'magic times like midnight'. Some users will do whatever they want to do if they are able to do, regardless of any statements to the contrary. Should the RIPE NCC enforce such access rules by some means? References The IETF doc 'Finding geofeeds': https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/?includ… geofeed file format: https://www.rfc-editor.org/rfc/rfc8805.html

12 53

Future of "geoloc:"
by denis walker 13 Apr '22

13 Apr '22

Colleagues Now we have the "geofeed:" attribute, what should we do with "geoloc:"? Right now far more people are using "geoloc:" than "geofeed:". denis$ zgrep "^geofeed:" ~/Desktop/ripe.db.inetnum.gz | wc -l 289 denis$ zgrep "^remarks:\s*geofeed" ~/Desktop/ripe.db.inetnum.gz | wc -l 13 Although from the 289 there are only 161 unique organisations. denis$ zgrep "^geoloc:" ~/Desktop/ripe.db.inetnum.gz | wc -l 35453 cheers denis co-chair DB-WG

4 3

Decision on NWI-4 INETNUM status values
by denis walker 11 Apr '22

11 Apr '22

Colleagues For many years people have been asking for a way to assign a whole allocation without having to create 2 smaller assignments. The situation is more relevant now with so many /24 allocations. After the RIPE NCC rejected the idea of a dual primary key, for technical reasons, there were two options on the table. Making the "status:" attribute multiple or creating a new status value 'ALLOCATED-ASSIGNED PA'. No one has objected to either of these options. The co-chairs therefore recommend the option put forward by the RIPE NCC to add a new status value 'ALLOCATED-ASSIGNED PA'. Of the two options, this is probably the simplest and likely to cause less problems with user's scripts that parse objects. If there are no objections to this, the co-chairs now ask the RIPE NCC to produce an impact/implementation report to add this new status value and include the business rules to restrict it's use. We will then seek a final approval from the community on the report. cheers denis co-chair DB-WG

6 20

Whois Release 1.102.3
by Edward Shryane 31 Mar '22

31 Mar '22

Dear Colleagues, We have deployed Whois release 1.102.3 to production to fix a vulnerability in the Spring Framework library (Spring4Shell). The only change from the current Whois release 1.102.2 is to update the spring dependency from 5.3.13 to 5.3.18. Whois is not vulnerable to the already known exploit, but we updated in case further exploits appear. Regards Ed Shryane RIPE NCC

1 0

RIPE Database Quarterly Planning Q2 2022
by Edward Shryane 31 Mar '22

31 Mar '22

Dear colleagues, We have published our quarterly plan for Q2 2022 for the RIPE Database: https://www.ripe.net/manage-ips-and-asns/db/quarterly-planning This quarter we are working on usability improvements to the website, and we will announce on the list when this has finished. Our goals here are to make it clear what we are working on in the coming months, and also to get discussion around those plans so we can make developments based on community input. If you have comments or questions around our plans, we hope you'll discuss with us on the list or you can always contact us directly at ripe-dbm(a)ripe.net. Regards, Ed Shryane RIPE NCC

1 0

Protecting References to Objects in the RIPE Database
by Edward Shryane 29 Mar '22

29 Mar '22

Dear Colleagues, Currently the "mnt-ref:" attribute only protects references to organisation objects in the RIPE database, by specifying which maintainer(s) can authorise the reference. This means it is possible to make references to other object types without any authorisation, for example: * Refer to another organisation's maintainer * Refer to another organisation's abuse-c contact * Refer to any technical contact, admin contact, zone contact Since these references do not need authorisation, it is open to misuse, creating the impression that an unrelated party is responsible for that object. I propose that the "mnt-ref:" attribute be added (as an optional attribute) to other object types to allow references to be authorised: * person * role * mntner * irt This proposal does not eliminate misuse (e.g. contact information can still be copied into a separate object), but protects references to existing objects. If the DB-WG agrees to this proposal, I will prepare a more detailed impact analysis for review. Regards Ed Shryane RIPE NCC

2 2

RIPE NCC Open House: Feedback on our Unified User Interface
by Michela Galante 28 Mar '22

28 Mar '22

Dear colleagues, On Wednesday 6 April from 10:00 to 11:30 UTC, we invite users of RIPE Atlas, RIPE Database, RIPE Labs, RIPE NCC Academy, LIR Portal, RPKI and RIPEstat to give us feedback on our unified user interface. This Open House session will focus on the user interface that was launched in 2020. Our goal is to unify the user experience across all platforms to make it easier and faster for users to navigate our services. You can register for the event at: https://meeting-registration.ripe.net/meeting-pub/registration?0&meetingId=… More information is available on our website: https://www.ripe.net/participate/meetings/open-house/ripe-ncc-open-house-fe… Best regards, Michela Galante RIPE NCC

1 0

Last call and final reminder for nominations to the 2022 Rob Blokzijl Award
by Carsten Schiefner 14 Mar '22

14 Mar '22

[Apologies for cross-posting to various RIPE lists] Dear DB WG members - this is the last call and final reminder for nominations to the 2022 Rob Blokzijl Award that will be accepted until this Friday, 18th March, at 23:59 UTC. In seeking nominations for this prestigious award, which was created to celebrate Rob's contributions to the development of the Internet, the Award Committee (https://rob-blokzijl-foundation.org/2021/11/22/2022-award-committee/) is interested to receive nominations of those who have reflected Rob's approach in either a technical or operational capacity. Please give some consideration to nominating individuals - but also teams and groups of people! - in your own community and/or the wider industry in the RIPE region who, in your opinion, deserve to be recognised for their work to make the internet and/or internet community better. To specifically have this emphasised again after some according queries: nominations of teams and groups of people are very well possible and wished for as well in case their collective work would match the criteria of the call as laid out! The Award Committee is particularly interested to receive nominations of contributors who, in addition to their own contributions, have also supported and enabled others anywhere in the world. Also, the Award Committee would like to encourage those making nominations to consider not only the community members in the later stages of their careers or who are widely known but also those who may have contributed greatly in the springtime of their career or discreetly for the greater good or who may be considered to be part of an unrepresented group. And last but not least: those of you who previously have made a nomination other than Wilfried Woeber, the 2018 awardee, may want to consider resubmitting a nomination. The complete details of the call and the nomination process can be found at: https://rob-blokzijl-foundation.org/2021/11/25/call-for-nominations-2022/ Best wishes and kind regards Carsten (on behalf of the Award Committee)

1 0

Removing Apache Proxy Servers from DB Services
by Edward Shryane 02 Mar '22

02 Mar '22

Dear Colleagues, Next Tuesday, 1st March, the DB team plan to remove the Apache httpd proxy servers for the following services: * https://apps.db.ripe.net/ * https://rdap.db.ripe.net/ * https://rest.db.ripe.net/ * https://syncupdates.db.ripe.net/ This will allow us to simplify our production environment, reducing operational work and maintenance. Be aware that URL validation will be stricter after this change. For example, the following will return a 400 Bad Request: * Empty path segments (i.e. '//') * Encoded path separators (i.e. %2F for '/') * Encoded query separator (i.e. %3F for '?') Please test your client using the TEST environment: https://www.ripe.net/manage-ips-and-asns/db/ripe-test-database or the Release Candidate environment: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Regards Ed Shryane RIPE NCC

1 1

Clear up of old issues - Whiepages
by denis walker 01 Mar '22

01 Mar '22

Colleagues The co-chairs recently had a zoom meeting with the RIPE NCC. One of the things we discussed was clearing up a number of old issues. We need to clear the deck and move on with new and perhaps more relevant issues. We will address a number of issues for the last time. In some cases the chairs will make a recommendation. As these are quite old issues, we will take silence as consensus for the chair's recommendation. The first issue is Whitepages. This is a feature from about 10+ years ago. It was intended to preserve the PERSON object in the RIPE Database and protect it from automatic deletion if it is not referenced from any operational data. It was to use the RIPE Database as a phone book for well known people in the industry who may not be resource holders. There are many other ways to provide such contact details today. It was only ever used by a handful of people. The RIPE NCC now has other ways to preserve ROLE objects if needed, for example if used by RIPE Atlas users. The chairs recommend removing this feature from the RIPE Database. If you need a ROLE object to be preserved, contact ripe-dbm(a)ripe.net to discuss. cheers denis co-chair DB-WG

4 8

geofeed issue: can't add geofeed attribute to PI /48
by Job Snijders 28 Feb '22

28 Feb '22

Dear all, Like all good netizens, I tried to align information I publish in the RIPE database to reality, but there is an obstacle: https://sobornost.net/~job/geofeed.png """Adding or modifying the "geofeed:" attribute of an object with a prefix length greater or equal to 48 is not allowed.""" No such restriction exists if you use the 'remarks: Geofeed' approach, as demonstrated here: $ whois -h whois.ripe.net 2001:67c:208c::/48 | grep Geofeed remarks: Geofeed https://sobornost.net/geofeed.csv I appreciate concerns about privacy, but I'm not wholly convinced restricting /48s from having a proper 'geofeed:' attribute is the best path forward. How does the working group feel about this restriction? Is it useful? Should it be lifted? If the latter, what would be the process? Kind regards, Job

14 52