- db-wg - mailman.ripe.net

The RIPE Database needs your attention...
by denis walker 08 Feb '23

08 Feb '23

Colleagues We still have many outstanding issues, some of which have been on and off the table for years. We cannot make any progress on them as we do not have the attention of enough people in the community. It will be good if we can clear up some of these issues before the next RIPE meeting. For that to happen we need more of you to volunteer to focus a little bit of your attention on database issues over the coming months. The database may not be your highest priority, but it is still an essential tool for many LIR's business and a fundamental part of the whole registry system. If you can PLEASE offer a few moments of your attention over the coming months we can wrap up many of these outstanding issues. Often people who agree with a suggestion, or have no preference, say nothing. We need you to say something so we know you agree or don't disagree. It is not good to declare consensus based on only 3 people commenting. Maybe we can start with the recent conversation about country codes. If you look back over the DB-WG mailing list for January we more or less have a couple of people supporting and one objecting to my suggestions. My suggestions for the community to consider are these: 1/ The country: attribute in ORGANISATION objects is only used to specify the legal address country of organisations (including individuals) holding internet resources and is tied to the country values in the extended delegated stats file. These values are maintained by the RIPE NCC. This is what the community agreed to when they accepted the implementation plan for NWI-10. 2/ The country: attribute in ORGANISATION objects cannot be set by users to meaningless, undefined values for other reasons, as this was not in the agreed implementation plan. 3/ The country: attribute in INET(6)NUM objects is made optional. 4/ We define the optional country: attribute in INET(6)NUM objects to be used for geolocation purposes only 5/ If included, this country code will signal that all the addresses covered by this range/prefix are used within the geographical boundary of the country value. 6/ The geofeed: attribute can be used where a block of addresses are used in multiple countries or if more fine grained details are needed. 7/ An optional country: attribute could be added to the AUT-NUM object if anyone feels it necessary to specify a geolocation for an ASN. As always your thoughts are welcome... cheers denis co-chair DB-WG

1 0

ASNs present in a few AS-SETs in RIPE
by Peter Potvin 30 Jan '23

30 Jan '23

Hello, It has come to our attention that a couple of our newly-allocated ASNs are present in a few AS-SETs within the RIPE database which we should not be present in, and we are unsure how to successfully get them removed from these AS-SETs. If someone could please let us know how we can get them removed, that would be appreciated. Regards, Peter Potvin | Executive Director ------------------------------------------------------------------------------ *Accuris Technologies Ltd.* 56A Mill St E, Unit #470, Acton, ON L7J 1H3 Canada Email: peter.potvin(a)accuristechnologies.ca Office: +1 (877) 352-6105 Network Operations Centre: +1 (877) 321-1662

3 2

Re: [db-wg] ORGANISATION country code
by Ángel González Berdasco 24 Jan '23

24 Jan '23

Hello Denis Sorry to ask but, how is this country code used / what their meaning when it is entered by RIPE NCC itself? It appears to me that the challenge on "what to place" would be the same. Regards -- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/ PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ==================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ==================================================================== In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to dpd(a)incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad. ====================================================================

2 1

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