June 2023 - db-wg - mailman.ripe.net

Using the RIPE Database for IPAM
by denis walker 04 Oct '23

04 Oct '23

Colleagues Do you use the RIPE Database as your IPAM solution? If so, read on.... The RIPE NCC has done a brief review of the recommendations made by the DB Task Force (DBTF). You can find it here: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/initial-analys… There is one point in the summary that I disagree with: One recommendation can be implemented immediately by the RIPE NCC: - 3. Using the RIPE Database as an IPAM solution The recommendation from the DBTF was: "The task force recommends limiting and discouraging the use of the RIPE Database as an enterprise IPAM solution." This has not yet been discussed by the community and there is no consensus on this recommendation. So the RIPE NCC should not be doing anything to implement this recommendation. There are a number of points relating to this. The first BoF held by the DBTF had 46 participants. They had some polls about IPAM: Where do you hold your canonical IP address assignment details? (13 answers) Internal database or IPAM system (5 - 38%) RIPE Database (5 - 38%) Internal database for detailed assignments and RIPE database for allocations (3 - 23%) What should we do about the IPAM use of the RIPE Database? (12 answers) We should discourage it (3-25%) We should tolerate it but provide restrictions and best practices (5-42%) We should promote it and facilitate it (4-33%) During the BoF some comments were also made on this: Shane's comment "IPAM seems to be an important thing" Nathalie said about 50% of people attending training courses over a number of years said they use the RIPE DB for IPAM. Also trainees said open source IPAM solutions often pull data out of the RIPE DB but have no functionality to push data to the RIPE DB. During the presentation by the DBTF in the DB-WG session at RIPE 83 Shane said (on IPAM): "if you had very light requirements for IPAM then maybe it is OK, but it's not really what it's for" "unable to find out if this [response] was based on misunderstanding of the question" "we think there are probably good ways to go forward with that, for example making hooks so that external IPAM solutions can hook into it...that makes sense, there are certainly many commercial vendors that make IPAM products who would be happy to use hooks, there are many ways that third parties could use this but probably not a requirement" So it looks like there are very mixed views on the use of the RIPE Database for IPAM. Some people also expressed surprise that so many people use the database for IPAM. It is clear that we don't actually understand who, how and why people use the database for IPAM. We need a better understanding of the how and why and the number of users doing this before we can make any decision about discouraging or encouraging this use of the database. Even to consider if IPAM should be defined as a purpose of the database. As we are talking about it, maybe now is the time to start this discussion. If you use the RIPE Database as your IPAM solution maybe you can offer some more details. cheers denis co-chair DB-WG

5 5

Geofeed purpose
by denis walker 07 Aug '23

07 Aug '23

Colleagues The conversation on deploying geofeed died shortly after RIPE 85. The last comment was from myself asking if anyone was willing to propose some wording for a new purpose covering the use of the RIPE Database for geolocation information. No one proposed any wording. So below I have made a proposal for a new purpose. Your comments are appreciated. cheers denis co-chair DB-WG The RIPE Database contains information for the following purposes: Ensuring the uniqueness of Internet number resource usage through registration of information related to the resources and Registrants Publishing routing policies by network operators (IRR) Facilitating coordination between network operators (network problem resolution, outage notification etc.) Provisioning of Reverse Domain Name System (DNS) and ENUM delegations Providing information about the Registrant and Maintainer of Internet number resources when the resources are suspected of being used for unlawful activities, to parties who are authorised under the law to receive such information. Scientific research into network operations and topology Providing information to parties involved in disputes over Internet number resource registrations to parties who are authorised under the law to receive such information. Providing information about the geolocation usage of Internet number resources.

6 15

Progress on NWI-4
by Wessel Sandkuijl 20 Jul '23

20 Jul '23

Hi, I've reviewed Ed's impact analysis for NWI-4 and his proposal to add a new status value "ALLOCATED-ASSIGNED PA". This will not cover all use cases and it's use will most likely be limited as most people are used to the "ALLOCATED PA" versus "ASSIGNED PA" status values. I would highly prefer the earlier alternative proposal to use a tuple (using both prefix and status) so no new status value is introduced to the RIPE database. Can this be moved forward? Regards, Wessel Sandkuijl

4 4

Database Working Group Chair Selection
by William Sylvester 07 Jul '23

07 Jul '23

Fellow working group members, We currently have two slots open, the first is Denis’s term has come to an end. In keeping with our continuity plan to have chairs on a three year rotation offset yearly. The other open slot has two years remaining as a term. We have two candidates currently for these open slots with preferences as indicated; Denis Walker, two year term David Tatlisu, three year term I encourage each candidate to post any statements they wish to make directly to the working group. This notice serves as the candidate announcement and call for discussion. Thanks, William DB-WG Co-Chair Our current chair process is as revised in 2017, as follows; 1) Number of chairs is a minimum of 2 with a maximum of 3. 2) Chair can be removed at any time by consensus. 3) Chair terms are staggered yearly. 4) One chair per year is replaced. 5) Working group selects chair by consensus. 6) The consensus judgement will be made by the serving WG co-chair(s) and will exclude the co-chair(s) who is the subject of that consensus judgement. 7) Selection process is as follow; 7.1) Interested parties have two weeks to make their interest known via the mailing list, or directly to the Chair/s. 7.2) After two weeks, the Chair/s ensure that all candidates are announced on the mailing list and issue a call for discussion. 7.3) WG members express their approval or otherwise of the presented candidates. 7.4) Two weeks after the call for discussion, the Chair/s declare a decision, based on mailing list discussion, as they would do for a policy proposal. 8) Any appeal over a consensus decision will be heard by the RIPE Chair (or their deputy) whose decision shall be final. 9) In the case more than one chair is up for selection at the same time, the chair with the greatest support will take a multi-year term, the chair with the least support will take the second longest term. Terms will be determined by the number of chairs (3 chairs = 3 year term, 2 chairs = 2 year teams). The intent is to maintain continuity of the working group chairs. So the working group is never left without a chair.

6 8

Updated Full Text Search API
by Edward Shryane 23 Jun '23

23 Jun '23

Dear Colleagues, In the Whois 1.107 release, we have made some improvements to the Full Text Search API and also to the backend Elasticsearch implementation. We have also improved the API documentation: https://apps.db.ripe.net/docs/11.How-to-Query-the-RIPE-Database/02-Web-Quer… If you prefer using the web interface to Full Text Search, it is still available: https://apps.db.ripe.net/db-web-ui/fulltextsearch If you have any suggestions for improvements or find any issues, please let me know. Regards Ed Shryane RIPE NCC

1 0

RIPE Database Quarterly Planning Q3 2023
by Edward Shryane 23 Jun '23

23 Jun '23

Dear colleagues, We have published our next quarterly plans for the RIPE Database on our website: https://www.ripe.net/manage-ips-and-asns/db/quarterly-planning In this quarter, we will continue to work on publishing the source code to our web application and move the RIPE Database documentation to a new interface. By sharing these plans with you, we want to inform you of the ongoing developments on the RIPE Database and get your feedback on other work items you would like us to focus 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

About rpki
by Cunchang Huang 22 Jun '23

22 Jun '23

I now need to get the expiration time of the rpki we set, how can I get it Cunchang Huang

1 0

NWI-14 Authenticating References to Objects
by denis walker 19 Jun '23

19 Jun '23

Colleagues The chairs propose creating NWI-14 for expanding the optional use of the "mnt-ref:" attribute to protect objects from accidental or intentional mis-representation of responsibility. See slide 14 of this presentation for the problem definition: https://ripe78.ripe.net/presentations/129-RIPE78-Operational-Update.pdf We ask the RIPE NCC to add NWI-14 to the list. cheers denis co-chair DB-WG

3 4

Whois Release 1.107
by Edward Shryane 19 Jun '23

19 Jun '23

Dear colleagues, RIPE Database release 1.107 has been deployed to the Release Candidate environment. We plan to deploy to production on Monday 19th June. This release includes the following main changes: * NWI-14: added mnt-ref: attribute to person, role, mntner, irt object types * Sign NRTMv4 notifications * Full text search fixes * Limit resource lookups in RDAP organisation entity requests * Allow any characters in local part of SSO auth: email addresses * Fixed country: attribute validation * Include country: attribute in organisation split file The release notes are on the website: https://apps.db.ripe.net/docs/21.Release-Notes.html#ripe-database-release-1… 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

Sponsored ASNs AccountOwner's in extended delegate file don't move with sponsor
by Ben Cartwright-Cox 15 Jun '23

15 Jun '23

I'm not 100% sure if this is the correct place to report/discuss this quirk I've come across, but db-wg is the closest I have, so here it goes. In (what I call) the RIPE delegate file https://ftp.ripe.net/ripe/stats/delegated-ripencc-extended-latest Sponsored ASNs have slightly funny behaviour. For ASNs that are sponsored, the account owner UUID is always the ASN that sponsored the ASN first. If sponsorship is moved, the account owner UUID does not change. However given (as far as I understand) sponsored ASNs are PI resources, surely they should get the same treatment as the IPv4 and IPv6 entries (in that the PI holder has their own accountowner uuid) What do we think? Is this behaviour of being sticky to the original sponsor account UUID a bug? Should sponsored ASNs have their own account UUID? Have I completely misunderstood what any of this file means? I ask most of this because my own system bgp.tools allows you to quickly lookup resources by account, and for my own production ASN: $ curl -s https://ftp.ripe.net/ripe/stats/delegated-ripencc-extended-latest | grep 206924 ripencc|GB|asn|206924|1|20170411|allocated|b786bde2-1363-44c5-aec3-5ac65ee325e6 It shows all of the remaining ASNs that were originally registered by the now defunct LIR: https://bgp.tools/rir-owner/b786bde2-1363-44c5-aec3-5ac65ee325e6 Cheers Ben Cartwright-Cox

2 3