- db-wg - mailman.ripe.net

Extending the consultation period for service criticality
by Razvan Oprea 18 Jan '23

18 Jan '23

Dear colleagues, Your input about the criticality rating of the RIPE Database is important. Keeping in mind the busy end of year, and the holidays, we have extended our consultation period until 22 January 2023. Wishing you all a happy new year. Regards, Razvan C. Oprea RIPE NCC

1 1

Performance Evaluation 2022
by Fallon Albrecht 05 Jan '23

05 Jan '23

Hi Ed, Do you have any feedback positive/improvements over my performance in 2022? Cheers, Fallon

1 1

Impact Analysis for NWI-4
by Edward Shryane 16 Dec '22

16 Dec '22

Dear colleagues, Following is the impact analysis for NWI-4 "Role of status: field in multivalued status context", based on the addition of a new status value "ALLOCATED-ASSIGNED PA". The main drawback identified in this proposal is that an inetnum with status "ALLOCATED-ASSIGNED PA" must remain co-maintained between the RIPE NCC and the LIR, and not by the end user. If an end user is required then the earlier alternative proposal to use a tuple (using both prefix and status) is preferable (although technically more complex). Whois Application * Add a new inetnum status "ALLOCATED-ASSIGNED PA". Treat this status as both ALLOCATED PA and ASSIGNED PA. * New allocations will continue to be created with the "ALLOCATED PA" status. * Allow a user to switch the status to and from (only) "ALLOCATED PA" to "ALLOCATED-ASSIGNED PA" themselves. This allows the user to document a single assignment under the allocation. * Follow the same validation rules for both ALLOCATED PA and ASSIGNED PA. This new status has no impact on the validation rules (i.e. no conflict was found between the two status values). * Support the same status hierarchy for ALLOCATED-ASSIGNED PA as for ALLOCATED PA or ASSIGNED PA (e.g. SUB-ALLOCATED PA, LIR-PARTITIONED PA etc.). * An inetnum with status "ALLOCATED-ASSIGNED PA" remains co-maintained by the RIPE NCC. * The inetnum primary key remains the IPv4 address range. Using the same address range with different status values is not allowed. Registry Services * The "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" policy (currently RIPE-733) requires that "All assignments and allocations must be registered in the RIPE Database". This proposal addresses this requirement. * If an LIR wants to create an assignment because they want to document an assignment to an end user, this proposal will not help in this case. The ALLOCATED-ASSIGNED PA inetnum remains co-maintained between the LIR and the RIPE NCC, and not by an end user maintainer. Also any contacts (admin-c, tech-c, abuse-c etc.) are for the LIR and not the end user. * What is missing is that an LIR can not specify an end user customer’s mnt-by and, most importantly, cannot specify the customer’s organisation object. Internal Registry * No impact is expected to the internal registry software. No direct parsing of the status attribute for either inetnum objects was found in interactions with Whois (e.g. organisation changes and transfers). Whois Clients * Clients reading the inetnum status: value must be updated to take account of the "ALLOCATED-ASSIGNED PA" status and treat it as equivalent to both an "ALLOCATED PA" and "ASSIGNED PA" status. Regards Ed Shryane RIPE NCC

1 0

RIPE Database Quarterly Planning Q1 2023
by Edward Shryane 15 Dec '22

15 Dec '22

Dear colleagues, We have published our quarterly plans for Q1 2023 for the RIPE Database: https://www.ripe.net/manage-ips-and-asns/db/quarterly-planning In this quarter, we will continue working on the server-side implementation of NWI-12: NRTMv4 and the migration of the RIPE Database documentation to a new interface. We hope that by providing these plans, we can better inform the community of the ongoing developments on the RIPE Database and get feedback on our work. 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

Whois Release 1.105
by Edward Shryane 13 Dec '22

13 Dec '22

Dear Colleagues, RIPE Database release 1.105 has been deployed to the Release Candidate environment. We plan to deploy to production on Tuesday 13th December. This release includes a single change from 1.104: * NWI-19: Change to AS-SET object naming rules (not allowed to create with short format) 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

NWI-10 "Definition of Country" is Complete
by Edward Shryane 02 Dec '22

02 Dec '22

Dear Colleagues, The RIPE NCC has now completed the implementation of phase 3 of NWI-10: "Definition of Country". This work included: * Recording the legal address for all End User organisations with Provider Independent resource(s); * Populating the legal address country code into end user organisation objects in the RIPE database; * Updating the country code in the Extended Delegated Stats for all the Provider Independent resources an end user holds to the legal address country code. * Internal software changes to synchronise changes of legal address country code to the RIPE database and Extended Delegated Stats. More information about NWI-10 is available here: https://labs.ripe.net/author/stefania_fokaeos/our-plan-to-update-country-co… Regards Ed Shryane RIPE NCC

1 0

proposal: disallow creation of new non-hierarchically named AS-SET objects
by Job Snijders 01 Dec '22

01 Dec '22

Dear DB-WG, Speaking in individual capacity. In RFC 2622 section 5 specifies the naming convention for AS-SET objects. https://www.rfc-editor.org/rfc/rfc2622#section-5.1 There basically are two styles: * "short" (example: AS-SNIJDERS) * "hierarchical" (example: AS15562:AS-SNIJDERS) Problem statement ================= In recent weeks a number of hypergiant cloud providers have faced the thorny effects of adversarial AS-SET object naming collisions between IRR databases. An example of this phenomenon is the existence of AS-AMAZON in both RADB and RIPE. According to https://www.peeringdb.com/net/1418 the RADB copy of the object is the the correct one and populated with a number of members entries. The RIPE one is empty, and not under control of Amazon. The existence of the AS-AMAZON object in the RIPE database might cause some operators to inadvertently apply empty prefix-filters to EBGP sessions which in turn causes various problems. It seems Amazon has no recourse to get the AS-AMAZON object removed from the RIPE database; because the existence of that object in the RIPE database does not violate any policies (as far as I know). But perhaps, going forward, this community can do a little bit more to help prevent similar situations from happening to others. Solution proposal ================= I think the solution is to - GOING FORWARD - disallow creation of new AS-SET objects which follow the 'short' naming style. The advantage of hierarchical naming is that the existing authorization rules as applied by the RIPE Whois Server database engine do a decent job of protecting/separating namespaces. 'Grandfathering' existing short-named objects ensures that implementation of this solution proposal causes minimal (if any) disruption to existing workflows. The RIPE database engine blocking creation of short-named AS-SETs might help nudge the industry towards making hierarchical naming the norm. Related work ============ Related work throughout the registry industry: IRRd version 4 forces new AS-SET objects to be structured hierarchically: https://github.com/irrdnet/irrd/issues/408 Kind regards, Job

21 50

NWI-10 Populating End User Organisation Country Attribute
by Edward Shryane 01 Dec '22

01 Dec '22

Dear colleagues, As I mentioned in the Operational Update during the DB-WG session at RIPE85 last week (slide 16): https://ripe85.ripe.net/wp-content/uploads/presentations/111-DB-WG-Operatio… *today* the DB team will populate the "country:" attribute in approximately 20K organisation objects in the RIPE database. This will be done for end user organisations with resources allocated or assigned by the RIPE NCC, with the country code value where the resource holder is legally based. We are continuing work internally on the remaining end user organisations without a country code, and software changes for synchronisation during resource requests. Regards Ed Shryane RIPE NCC

5 9

Issue with authorization in hierarchical as-sets
by Cynthia Revström 21 Nov '22

21 Nov '22

Hi DB-WG, While looking into the discussion about requiring hierarchical as-sets I wanted to see if all current hierarchical as-sets were authorized by the ASN holders and I found two separate issues (in my opinion). I could find at least two cases of hierarchical as-sets that were likely created before RIPE and RIPE-NONAUTH split. They are using APNIC ASNs and there are aut-num objects for both of them in RIPE-NONAUTH, but the as-sets are still in RIPE. I am not sure of the scope of this issue or if others consider it an issue, but it seems like that should possibly get cleaned up, or at least get checked out. I only tried to check if there were any occurrences of this, not trying to find a complete list, so I just checked for any 32-bit APNIC ASNs in the db dump using grep. For those who want to look at it, the grep command I used was: grep '^as\-set:\s*[Aa][Ss][1][3-6][0-9][0-9][0-9][0-9]' ripe.db.as-set There is also another issue related to authorization when it comes to hierarchical as-sets. While authorization by a maintainer listed as mnt-by on the aut-num object is required to create an as-set, that maintainer can then later be removed and there is no force-delete option like there is for inet(6)num delegations. I think that a force-delete option should be implemented so any maintainer with mnt-by on the relevant aut-num can delete an as-set. I think that it would also be helpful to introduce a "associated as-set objects" list to the DB web UI, just like there is for associated route objects currently. Something that could be an issue is the cleanup, what happens with an hierarchical as-set when the relevant ASN is de-registered? Maybe someone on the DB team could clarify? -Cynthia

2 1

2022-01 Policy Proposal Withdrawn (Personal Data in the RIPE Database)
by Angela Dall'Ara 17 Nov '22

17 Nov '22

Dear colleagues, The policy proposal 2022-01, "Personal Data in the RIPE Database” has been withdrawn. The goal of this proposal was to allow the publication of verified Personal Data in the RIPE Database only when justified by its purpose. The proposal is archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive… Reason for withdrawal: The proposer felt that the scope of this proposal was too wide and decided to withdraw the proposal. Raised concerns like the potential consequences of the consent based publication of personal data and the efficacy of their verification might be addressed in future discrete proposals. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

1 0