- db-wg - mailman.ripe.net

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 10 May '22

10 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