- db-wg - mailman.ripe.net

Re: [db-wg] Proposal to allow non-ASCII characters in "org-name:", "person:" and "role:" attributes
by Ángel González Berdasco 18 Dec '23

18 Dec '23

It's nice to see you here, Marco. I don't think it will be possible to change the default without potentially causing problems for clients not expecting that. Adding that -C option to the server seems appropriate, and unless you expect that at one point there will be no clients not providing that, you will face the issue that if the default changes from iso-8859-1 to utf-8, old clients will be wrong, as you can't get every client to be updated at the same time. The most similar situation would be if you had a predefined epoch at which both server and clients would change the encoding. But it still requires all clients to have been updated, and the date having been agreed far in advance (and not posponed later!). A situation that could help would be if the server marked the encoding so that the client could recognise the output is no longer iso-8859-1, but utf-8, such as including a BOM (although it may be preferable to include that inside a comment rather than at the beginning, I see benefits both ways), and thus old-but-not-ancient clients could autodetect the switch. Most likely, the server default will not change, though. Best regards -------- Original message -------- From: Marco d'Itri via db-wg <db-wg(a)ripe.net> Date: 12/18/23 00:44 (GMT+01:00) To: Piotr Strzyzewski <piotr(a)internetsailor.net> Cc: db-wg <db-wg(a)ripe.net> Subject: Re: [db-wg] Proposal to allow non-ASCII characters in "org-name:", "person:" and "role:" attributes On Dec 03, Piotr Strzyzewski via db-wg <db-wg(a)ripe.net> wrote: > As the UTF-8 topic was briefly discussed during DB-WG session at RIPE87 > in Rome, I would like to propose moving forward with it. If that means a > topic for first (?) interim meeting, let it be. Let me know please if > this works for you. Thanks in advance. In Rome I talked a bit with Edward about this. Background: I am the author of the whois client used by all Linux distributions. I fully agree that switching to UTF-8 is desirable, but we cannot just change the encoding of port 43 without major side effects. Since version 5.5.4 (december 2019), the client assumes that the output of whois.ripe.net is Latin 1 and then transcodes it to the system encoding. Receiving unexpected UTF-8 would cause mojibake. My suggestion is to add a new query "command line" option to specify the desired encoding (limiting it to either ISO-8859-1 or UTF-8), as supported by other whois servers. -C is the most common choice, but maybe it would be better to use --charset to not waste a single letter option. See https://github.com/rfc1036/whois/blob/next/servers_charset_list . In a few years then it will be much easier to switch the default from Latin 1 to UTF-8. -- ciao, Marco

1 0

Whois Release 1.109
by Edward Shryane 04 Dec '23

04 Dec '23

Dear colleagues, RIPE Database release 1.109 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Monday 4th December. The data in the RC environment is a dummified copy of production from 16th November. This release has the following main changes: * RDAP redaction (#1317) * Removed organisation "e-mail" from RDAP to match Whois and added to redaction list (#1333) * Removed geofeed prefix validation (#1326) * Added HTTPS Support to Whois Backend (#1329) * Support HTTP Basic authentication (#1342) * Support HTTPS Client Certificate Authentication (#1343) * Initialize NRTMv4 from command-line (JMX) (#1310) * Use parallel stream to generate NRTMv4 snapshots more quickly (#1309) * Include AS-SET in RIPE-NONAUTH dump (#1352) The release notes are on the website: https://apps.db.ripe.net/docs/Release-Notes/#ripe-database-release-1-109 More information on the Release Candidate environment can be found on our website: https://apps.db.ripe.net/docs/Release-Notes/ Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Impact Analysis for NWI-4: using the inetnum and status tuple as a primary key
by Edward Shryane 28 Nov '23

28 Nov '23

Dear colleagues, Following is the impact analysis for NWI-4 "Role of status: field in multivalued status context" based on the use of the "inetnum:" and "status:" tuple as a primary key. Please let me know any questions, corrections or suggestions, in particular if there is impact to any functionality that I haven't considered. I will update the impact analysis as needed. Regards Ed Shryane RIPE NCC Summary ------- Firstly, refer to the Problem Statement for NWI-4: https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005242.html "Some believe that the main underlying issue here is that it is currently not possible to create an assignment that is the same size as an allocation in the RIPE Database. And resource holders are of course supposed to create an assignment for the address space in an allocation that is in use, by address policy." We investigated the impact of allowing a Provider Aggregatable ("PA") assignment to be the same size as its parent allocation to satisfy NWI-4, using a tuple of the prefix and status as the primary key to differentiate between them. This change will have a major impact on querying and updating inetnum objects in the RIPE database. A previous impact analysis of a new status value "ALLOCATED-ASSIGNED PA" was proposed in December 2022: https://www.ripe.net/ripe/mail/archives/db-wg/2022-December/007722.html but has a number of drawbacks, in particular: * The LIR and end-user organisations cannot both be added to the inetnum * The LIR and End User cannot both co-maintain the inetnum So we do not consider this as a feasible solution for NWI-4. General ------- The inetnum primary key tuple will consist of an "inetnum:" attribute value in prefix *or* range notation, immediately followed by the "status:" attribute value. Using the status as part of the inetnum primary key is *optional* and only necessary if there are multiple inetnums with the same prefix. There are space characters in the inetnum "status:" values "ALLOCATED PA" and "ASSIGNED PA", meaning the tuple (primary key) will have a space in it. Sorting inetnums in a hiearchy will take *both* the prefix and the status into account, e.g. an inetnum with "ALLOCATED PA" status will be ordered before an "ASSIGNED PA" status. Only "ALLOCATED PA" and "ASSIGNED PA" status values can be used in the primary key tuple. Only a single "ASSIGNED PA" inetnum can have the same prefix as the "ALLOCATED PA" inetnum. Whois (Port 43) Queries ----------------------- Support will be added for an inetnum tuple in Whois queries. Adding the status to an inetnum prefix or range will be optional. If an exact match (i.e. returning a single inetnum) is needed in the query response, a client may have to specify the tuple (i.e. both the inetnum prefix and status) in the query. If both an allocation and assignment are returned with the same prefix or range, then the client needs to match which inetnum it was querying for based on the status. Querying for only an inetnum prefix or range without any hierarchical flags may return multiple inetnum objects in the response, where previously only one was returned. The allocation is returned first, followed by the assignment. If using the exact match (-x) flag and only specifying the inetnum prefix or range, multiple inetnum objects may be returned in the response, where previously only one was returned. The allocation is returned first, followed by the assignment. If using the less specific (-L, -l) flag, if both an assignment and allocation with the same prefix or range are matched, then first the less-specific assignment is returned, followed by the allocation. If using the more specific (-M, -m) flag, if both an assignment and allocation with the same prefix or range are matched, then first the more-specific allocation is returned, followed by the assignment. RDAP API -------- Querying RDAP for an "ip" resource in the RDAP protocol can only be done by prefix, not by prefix and status. Hence using a tuple as the primary key is incompatible with the RDAP protocol. If there are multiple matches in RDAP for the same inetnum prefix or range key, then an error is returned. To support querying RDAP for a single "ip" resource, we will need to extend the protocol to include the inetnum prefix and (optional) status tuple. REST API -------- The REST API will be updated to allow a tuple to be optionally used in the URL for an inetnum primary key. The status must immediately follow the inetnum prefix or range in the URL path and all spaces are URL-encoded. REST API requests may have to use a tuple as the inetnum primary key, if there are multiple matches on the prefix alone. REST API responses containing an inetnum may contain a tuple as the primary key. REST API Create --------------- There is no change when creating an allocation via the REST API, as it is assumed that no assignment will exist yet. Creating an allocation is only allowed by the RIPE NCC. Creating an assignment the same size as an existing allocation will be allowed. The primary key is not included in the request URL when creating an object. For example: (POST) https://rest.db.ripe.net/ripe/inetnum REST API Lookup --------------- Performing a REST API lookup for an inetnum object requires the tuple to be specified only if both an allocation and assignment exist with the same prefix. For example: (GET) https://rest.db.ripe.net/ripe/inetnum/192.0.2.0/24ASSIGNED%20PA (GET) https://rest.db.ripe.net/ripe/inetnum/192.0.2.0%20-%20192.0.2.255ASSIGNED%2… (GET) https://rest.db.ripe.net/ripe/inetnum/192.0.2.0/24ALLOCATED%20PA Performing a lookup for a single inetnum prefix or range will fail if the status is not specified and there are multiple matches (i.e. a REST API GET request must not match multiple objects). REST API Query (Search) ----------------------- Refer to the Whois Query (port 43) section above, as the query behaviour is the same for REST API search. Searching for an inetnum prefix or range alone may return multiple inetnum matches (i.e. both an allocation and an assignment) where previously only a single inetnum was returned. For example: (GET) https://rest.db.ripe.net/search?query-string=192.0.2.0 The client will need to match which inetnum it was querying for using the status. Searching for an inetnum prefix or range and status tuple will be supported and will return a single inetnum match. For example: (GET) https://rest.db.ripe.net/search?query-string=192.0.2.0/24ASSIGNED%20PA (GET) https://rest.db.ripe.net/search?query-string=192.0.2.0%20-%20192.0.2.255ASS… REST API Update and Delete -------------------------- Specifying the tuple as a primary key in the URL when updating or deleting an inetnum is optional (using PUT or DELETE methods). Updating or deleting an inetnum will only require the tuple to be specified if there are multiple objects matching the prefix. Syncupdates ----------- There is no impact on Syncupdates. Objects are submitted in RPSL format and a tuple is not used. Mailupdates ----------- There is no impact on Mailupdates. Objects are submitted in RPSL format and a tuple is not used. Nightly Dump and Split Files ---------------------------- In the nightly dump and split files (made available on the FTP site), multiple inetnum objects may have the same "inetnum:" prefix but with different "status:" values. Clients parsing these files may need to be updated to match an inetnum based on the tuple of prefix and status. Delegated Stats File -------------------- In the RIPE delegated stats file (made available on the FTP site), multiple inetnum objects may share the same prefix but with different "status:" values. Clients parsing the delegated stats file may need to be updated to match an inetnum based on the tuple of prefix and status. Refer to the delegated stats format specification: https://ftp.ripe.net/ripe/stats/RIR-Statistics-Exchange-Format.txt An IPv4 resource is specified including the start (address), value (size) and status. Authorisation rules for creating route objects ---------------------------------------------- To create a route object in the RIPE database, you must authenticate against the address space you are referring to. First an existing exactly matching route object is checked. If there is none, then any less specific route is checked. If there is none, then an exactly matching or less specific inetnum is checked. If the exactly matching or less specific inetnum is an allocation and assignment with the same prefix, then (both) the assignment is checked first followed by the allocation. Ref. https://apps.db.ripe.net/docs/Authorisation/Protection-of-Route-Object-Spac… Authorisation rules for creating domain objects ----------------------------------------------- The creation of domain objects for "in-addr.arpa" domains must satisfy a hierarchical authorisation against inetnum address space. First an existing exactly matching inetnum object is checked. If there is none, then a less specific inetnum is checked. If the exactly matching or less specific inetnum is an allocation and assignment with the same prefix, then (both) the assignment is checked first followed by the allocation. Ref. https://apps.db.ripe.net/docs/Authorisation/Protection-of-Reverse-Delegatio… Force deleting inetnum objects ------------------------------ Force delete allows you to delete inet(6)num, route(6) and domain objects by using the maintainer of a covering address space object, instead of the maintainer of the object itself. This means the "mnt-lower:" of an allocation or the "mnt-by:" of a provider independent (PI) or anycast assignment or legacy under contract, each have the authority to force delete any more specific or related object. There is no impact on force delete. If an assignment exists with the same prefix as an allocation, only the allocation is checked for authentication during force delete. An assignment with the same prefix as an allocation can be deleted using force delete. Ref. https://apps.db.ripe.net/docs/Authorisation/Force-Delete-Functionality/ Force deleting route objects ---------------------------- If this route object has a maintainer that you do not have the credentials for, it can block you from creating a new route(6) object. In this case you, as the resource holder, can simply delete the blocking route(6) object. When creating a route object, if an existing exactly matching or less specific route object has a maintainer that you do not have credentials for, then it can block you from creating the route object. In this case you, as the resource holder, can simply delete the blocking route(6) object. The force delete functionality will look for an exact matching, encompassing or less specific inetnum object that is co-maintained by the RIPE NCC in the hierarchy of the object that is to be deleted. If the exactly matching or less specific inetnum is an allocation and assignment with the same prefix, then (both) the assignment is checked first followed by the allocation. Ref. https://apps.db.ripe.net/docs/Authorisation/Protection-of-Route-Object-Spac…

4 5

Revised Agenda RIPE87 - Database Working Group
by William Sylvester 28 Nov '23

28 Nov '23

All, Here is the proposed agenda for the Database Working Group for RIPE87. If you would like to present, have questions, comments, or requested changes please let the chairs know. Best regards, William, David, & Denis DB-WG Chairs A. Introduction - 10 min * Welcome * Scribe * Agenda B. NWI Update – 10 mins David Tatlisu, Co-Chair C. Operational Update – 15 mins Edward Shryane, RIPE NCC C. Geolocation within RDAP – 15 mins Mark Kosters, ARIN D. NWI-4 Tuple Impact Analysis – 10 mins Edward Shryane, RIPE NCC Z. AOB (open discussion)

1 0

The RIPE Database Web Application is now Open Source
by Edward Shryane 23 Nov '23

23 Nov '23

Dear colleagues, The RIPE Database Web Application is now open source and available on GitHub: https://github.com/RIPE-NCC/db-web-ui This is the software running the RIPE database website: https://apps.db.ripe.net/ The software is provided under the BSD license (the same as for Whois): https://github.com/RIPE-NCC/db-web-ui/blob/master/LICENSE.md We intend to publish all improvements made to the website in this repository. If you find a bug, or want to request a technical improvement please open an issue via https://github.com/RIPE-NCC/db-web-ui/issues If you have a functional issue with the website, please continue to contact support (via the left-hand menu) or email ripe-dbm(a)ripe.net. Regards Ed Shryane RIPE NCC

1 0

Agenda RIPE87 - Database Working Group
by William Sylvester 20 Nov '23

20 Nov '23

All, Here is the proposed agenda for the Database Working Group for RIPE87. If you would like to present, have questions, comments, or requested changes please let the chairs know. Best regards, William, David, & Denis DB-WG Chairs A. Introduction - 10 min * Welcome * Scribe * Agenda B. Operational Update– 15 mins Edward Shryane, RIPE NCC C. Geolocation within RDAP– 15 mins Mark Kosters, ARIN D. NWI-4 Tuple Impact Analysis– 10 mins Edward Shryane, RIPE NCC Z. AOB (open discussion)

1 0

geolocation purpose
by denis walker 02 Nov '23

02 Nov '23

Colleagues The discussion and agreement of the text for a new purpose for the RIPE Database covering geolocation was done by the RIPE NCC and it's executive board. They refused to publish the text in advance, didn't announce that the board had agreed to it or that the T&C document has been updated. I still don't understand why this had to be done so secretly. Anyway this is the text of the new purpose from the T&C, https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms "Facilitating network operations by publishing geolocation information about the usage of Internet number resources (including country, region, city of the party to which the resources have been distributed by the Registrants)" Does this cover what you all wanted from the new "geofeed:" attribute? "Facilitating network operations" suggests this information is only for use by network operators in the management of their networks. Any use of this geolocation information by the wider public or other geolocation information providers is therefore not covered by this purpose. AFAIK this change to the T&C has not yet been announced by the RIPE NCC as required by Article 8.2. So the new purpose is not yet in effect. cheers denis co-chair DB-WG

3 2

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

Question about the status of the implementation of NWI-4
by Erik Bais 29 Sep '23

29 Sep '23

Hi, I was wondering how long it is going to take, to finish the implementation of NWI-4. And what the current status is on the topic. Regards, Erik Bais

2 2

RIPE Database Quarterly Planning Q4 2023
by Edward Shryane 29 Sep '23

29 Sep '23

Dear colleagues, The next quarterly plans for the RIPE Database are now available 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

Whois release 1.108
by Miguel Herran 27 Sep '23

27 Sep '23

Dear colleagues, RIPE Database release 1.108 has been deployed to the Release Candidate environment. We plan to deploy to production on Wednesday 27th September. This release includes the following main changes: * NRTM: Use base64 instead of Hex * NRTM: JSON Text Sequences * RDAP: Add remarks * Update: Warn when http * Remove Lucene support * Elasticsearch do not rebuild from scratch * Elasticsearch use phrase without prefix due to bug * Elasticsearch scape colons * Jakarta / EE9 The release notes are on the website: https://apps.db.ripe.net/docs/Release-Notes/#ripe-database-release-1-108 More information on the Release Candidate environment can be found on our website: https://apps.db.ripe.net/docs/Release-Notes/ Please let us know if you find any issues with this release in the RC environment. Regards Miguel Herrán RIPE NCC

2 1

Fwd: Geofeed purpose
by Theodoros Fyllaridis 14 Sep '23

14 Sep '23

Dear Colleagues, We would like to provide you with an update on the amendments to the RIPE Database Terms and Conditions. The RIPE Database Terms and Conditions may be amended by either the RIPE NCC (Article 8.2) or the Policy Development Process (Article 8.3). After a long discussion, the Database Working Group reached consensus that providing geolocation information is an agreed additional purpose of the RIPE Database. This consensus was not the outcome of the Policy Development Process. Based on this mandate, the RIPE NCC will work on amending the Terms and Conditions to include this new purpose, as per Article. 8.2 and according to the process set out in the Adoption Process for RIPE NCC Corporate Documents: https://www.ripe.net/about-us/legal/corporate-governance/adoption-process-f…. The proposed text will be based on the community's consensus that geolocation information about the usage of Internet number resources is necessary to facilitate Internet operations. The text will then be reviewed by the RIPE NCC Executive Board in accordance with the aforementioned Adoption Process for RIPE NCC Corporate Documents. Kind regards, Theodoros Fyllaridis Legal Counsel RIPE NCC

1 0

denying access to RIPE DB for proven spammers
by Sergey Myasoedov 13 Sep '23

13 Sep '23

Hi, I would like to discuss the possible changes to the RIPE Database for the LIRs or brokers sending targeted spam with proposed address resources transactions. As far as I know, RIPE DB T&C does not contain a statement about restricting the use of RIPE DB for those abusive traders. Should the community request the NCC to develop how to limit RIPE DB usage? Please feel free to comment. -- Kind regards, Sergey Myasoedov

3 3

About IP resources
by Cunchang Huang 01 Sep '23

01 Sep '23

Cunchang Huang Is there any way to get all the resources under this Id through orgId?

1 0

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

Entry Deduplication
by Peter Potvin 04 Aug '23

04 Aug '23

Hey there DB-WG, Apologies in advance if this is the wrong mailing list for this. I noticed that the RIPE DB Query UI automatically deduplicates entries (i.e. multiple instances of an ASN in an AS-SET only appears once) through the webUI, however when queried through whois on any modem operating system the entry shows the raw data including the duplicates within it. I'm a bit curious as to how this is done, and whether it's possible/planned to have the same functionality implemented in the WHOIS back-end that RIPE uses. 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 Center: +1 (877) 321-1662

2 1

July 2023 Database Working Group update
by David Tatlisu 04 Aug '23

04 Aug '23

Hello everyone, The mailing list has been buzzing this month! This mail is intended to serve as a summary of what happened on the mailing list and behind the scenes. ####################################################################################################################### By far, one of the most active threads concerned the correct *use of the "route" and "route6" objects in a DDOS mitigation scenario. *[1] *Context:* Kaupo Ehtnurm runs a multihomed AS, and one of his upstream providers offers DDOS mitigation service. To ensure all traffic passes through the DDOS mitigation service, they announce a more specific prefix. Kaupo explains that to achieve this, they need to create ROAs and Route objects. ROAs have a max-length field, which allows Kaupo to use just one ROA for a /32 IPv6 with the max-length set to /48. As route objects do not have a max-length field, they explain that they would have to create 65536 /48 route6 objects for their /32, which is difficult to manage. They ask why route objects don't have a comparable "max-length" field.* **Related discussion:* Most of the discussion does not concern the possible reasons why a "max-length" field for route-objects does not exist, but rather discusses operational practice and the actual behavior of DDOS mitigation announcements. Job Snijders explains some of the possible reasons this field does not exist [2]. Job [2] and Nick Hilliard [3] have recommended reading BCP 185 / RFC 9319 for additional information regarding best practices. *Majority consensus:* From what I was able to determine, the following statements are the majority consensus: * Most networks will accept the more specific prefixes, even without a more-specific route object. [4] [5] [6] [7] o Networks have their own reasons for why or why not they might filter more-specifics. [7] [8] [9] o Some traffic might still take the aggregate route instead of the more-specific, this shouldn't be a problem in practice. [10] o Testing the behavior of routes using tools like RIPE Atlas might yield different results, but is said to be unlikely. [7] * Creating a route object for every /48 in a /32 is not recommended. [11] [12] o Announcing and creating route objects for slightly longer prefixes like a few /33 or /34 instead of many /48 might be an acceptable compromise. [13] ####################################################################################################################### Another very active thread was started by Denis Walker, Co-chair of this working group, and concerned*the participation of working group chairs in discussions. *[14] *Context:* Starting the discussion, Denis Walker has explained that he – following feedback from community members – has decided to reduce his community engagement temporarily to evaluate the effect on the working group. He explains that he has not seen current NWIs progress during this time, and that, in his opinion, the lack of engagement by co chairs does not work in some working groups. He states that he will return to his original level of engagement. *Majority consensus: *From what I was able to determine, the following statements are the majority consensus: * Overall, people support active working group chairs that drive discussion, but do not support working group chairs taking a side as a working group chair. [15] [16] [17] * Working group chairs can express their personal opinion when they remove themself from the working group position. [18] [19] *Related discussion:* Most of the discussion has been about co-chair neutrality in discussions. Denis referenced RIPE documents outlaying the responsibilities of a co-chair, where one co chair expressing their opinion to drive discussion is not prohibited. [20] This was followed up by Nick Hilliard, referencing information regarding non-RIPE chair responsibilities. [21] In the end, a policy proposal to clarify the rules was mentioned. [22] [23] ####################################################################################################################### *News from the NCC* * The "rev-srv:" attribute, which was deprecated in 2009, was removed on July 27th. The maintainers of about 34,711 affected objects were informed. [24] * The "NONE" authentication scheme, which was deprecated in 2004, was removed on July 27th. The maintainers of about 613 affected objects were informed. [25] * Client certificate authentication is planned for the database. The NCC has a working implementation internally and is working on getting it ready for production. * The NCC is working on impact analysis concerning a "tuple" solution for NWI-4, where the prefix and status are considered part of the primary key. This will be published soon. * Preparing for the open-source release, the web application for the RIPE Database service is being audited by an external company. This audit is planned to finish by the end of August. #######################################################################################################################* Personal note * Please do not hesitate to tell me if you think I should have included something, or I misrepresented something. I didn't want to go into too much detail, and contemplated a lot about the things to include. You are welcome to contact me if you'd like changes to the format, or you would just like to mention that you thought it was good. I appreciate all feedback. * * ####################################################################################################################### *All the links* Route objects for DDOS mitigation: [1] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007843.html [2] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007859.html [3] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007855.html [4] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007855.html [5] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007867.html [6] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007856.html [7] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007862.html [8] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007866.html [9] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007868.html [10] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007861.html [11] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007865.html [12] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007865.html [13] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007861.html The participation of working group chairs in discussions: [14] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007869.html [15]https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007873.html [16] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007880.html [17] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007891.html [18] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007872.html [19] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007875.html [20] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007883.html [21] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007886.html [22] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007889.html [23] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007890.html NCC news: [24] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007877.html [25] https://www.ripe.net/ripe/mail/archives/db-wg/2023-July/007878.html

2 1

Authoritative check for domain objects seems to cache nameserver response
by Kjartan Hrafnkelsson - HI 02 Aug '23

02 Aug '23

Dear colleagues, When creating domain objects for reverse DNS delegation of a RIPE assigned inetnum or inet6num, I have observed behaviour where entering a nameserver not authoritative for the in-addr.arpa or ip6.arpa zone results in that nameserver being temporarily unable to be used for delegation. The interface keeps rejecting that particular nameserver for the reason of 'not being authoritative for <zone>', even if the nameserver's configuration has been updated accordingly. What I personally suspect is happening here is that the service on the backend of RIPE NCC's database has sent a DNS request to the specified nameserver, received a response, and cached it. I'm writing this email to ask a couple of questions: Is this intended behaviour? if it is, should it perhaps be changed? and if so, how should changes be implemented? I'm excited to hear back from you, especially as many colleagues within the networking space have expressed frustration from forgetting to configure their nameservers first or misconfiguring them and then having to wait a day or two to re-do the delegation. I had tried my best to search the db-wg list archives for a similar discussion before writing this entry but could find nothing of substance, please forgive me if this has been discussed before and perhaps decided on :) Best, -- Kjartan, AS51019 +354 784-0020 kjh14(a)hi.is

2 1

Removing RIPE-NCC-NONE-MNT remarks from objects in the RIPE database
by Edward Shryane 27 Jul '23

27 Jul '23

Dear colleagues, The "NONE" authentication scheme was deprecated in the RIPE database in 2004: https://www.ripe.net/publications/news/announcements/deprecation-of-the-non… At that time, "remarks:" attributes were added to objects in the RIPE database to explain this change: remarks: Maintainer RIPE-NCC-NONE-MNT removed and object remarks: LOCKED by the RIPE NCC due to remarks: deprecation of the NONE authentication scheme. remarks: Please visit the following URL to unlock this object remarks: http://www.ripe.net/db/none-deprecation-042004.html As mentioned in my Operational Update at RIPE86, I propose to remove these obsolete remarks from all objects, on *Thursday 27th July*. This change will affect approximately 613 objects. We plan to notify the maintainers of all affected objects afterwards. If you have any questions or comments, please let me know. Regards Ed Shryane RIPE NCC

1 1

Removing "rev-srv:" remarks from inetnum objects in the RIPE database
by Edward Shryane 27 Jul '23

27 Jul '23

Dear colleagues, The "rev-srv:" attribute was deprecated in inetnum objects in the RIPE database in April 2009: https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2009-April/001130.h… However the "rev-srv:" attribute was not removed but was converted into a "remarks:" attribute. As mentioned in my Operational Update at RIPE86, I propose to remove these obsolete remarks from all objects, on *Thursday 27th July*. This change will affect approximately 34,711 objects. We plan to notify the maintainers of all affected objects afterwards. If you have any questions or comments, please let me know. Regards Ed Shryane RIPE NCC

2 2

Where are we with NWIs?
by denis walker 24 Jul '23

24 Jul '23

Colleagues One or two vocal members of this community frequently express their opinion that all WG chairs should sit silently in the background, post an occasional review and wait to declare consensus or not. I am always willing to try out ideas from the community. So for the last couple of months, since RIPE 86, I have stayed silent on DB matters. How has the conversation been on NWIs? Oh there hasn't been any. How have they progressed beyond some steps already in progress? Oh there hasn't been any. Are we any closer to completing action on most NWIs? Er no we aren't. So I think it is fair to say this is not an appropriate way of working with some WGs these days. I will now go back to my previous way of working where, as a co-chair, I do have an agenda - to get things done, for the good of the internet. Whether you consider that a 'personal' or 'professional' or 'DB' agenda is up to you. Just to be clear, this is not the same as for the good of 'operators'. There are many stakeholder groups in this community now. We are no longer just 'the operator community' or even 'the technical community'. So I will continue to engage with the community, push out ideas (even crazy ideas sometimes), start and drive conversations until we get resolutions. Incidentally, this quiet period since RIPE 86 does remind us how busy you all are and how difficult it is for you to find the time to get so involved with the fine detail of small technical and operational changes to the RIPE Database. Which does fit with the presentation I did at RIPE 86 on how to manage the RIPE Database. I will come back to that shortly. cheers denis co-chair DB-WG

7 12

WG Co-Chairs Tasks (was: Where are we with NWIs?)
by Sylvain Baya 21 Jul '23

21 Jul '23

{change the topic. focus: basic tasks} Dear RIPE DB-WG, Hope this email finds you in good health. Please see my comments below inline... Thanks. Le mercredi 19 juillet 2023, denis walker via db-wg <db-wg(a)ripe.net> a écrit : > Colleagues > > One or two vocal members of this community frequently express their > opinion that all WG chairs should sit silently in the background, post an > occasional review and wait to declare consensus or not. > Hi Denis, Thanks for your email, brother. ...you seem to disagree with the WG consensus :-) or it's just with those few "vocal" WG participants? Do seek, first, if there is any rough consensus, or not, please. Is there actually any consensus on the matter? > > I am always willing to try out ideas from the community. > That's not part of the tasks of Co-Chairs, imho :-/ ...i may be wrong, though. Again! you *must* ask to the WG participants if they are ok with that idea, first...prior to engage on disruptive behavior. > So for the last couple of months, since RIPE 86, I have stayed silent on > DB matters. > > Please, it's not about you, brother. If you push back to the WG, you would be less concerned about your WG participant's opinions. In what, as a Co-chair, shall you be concerned about your WG's participant opinions? Please think of it twice, brother...if you care much; then how could you act fairly? or in other words: Do you expect your WG participants to hope to get a fair process, at end? > How has the conversation been on NWIs? > > Which one? Is it into the Co-chair's tasks list to follow-up on the active NWIs progress? > > Oh there hasn't been any. > > This WG have three Co-chairs, may i suggest to our Co-chairs to: 1] organise their team; 2] identify their *willing* regular tasks list; 3] discuss it with the DB-WG; 4] distribute the resulting regular tasks list amongst them (Co-chairs) 5] bind on that. > > How have they progressed beyond some steps already in progress? > Oh there hasn't been any. > Are we any closer to completing action on most NWIs? > Er no we aren't. > > Please, do not justify a disruptive behavior by stats poured like that. It *should* not work that way, brother: 1| remove your hat first 2| voice your personal opinion 3| wait the other Co-chairs to seek any consensus 4| put back your Co-chair's hat 5| and go ahead. That's, imho, what Randy is trying to recommend, if i got it well. > > So I think it is fair to say this is not an appropriate way of working > with some WGs these days. > The DB-WG may be an exception, but how to deal with that difference? Revisit the Co-chair's tasks list? What else? > > I will now go back to my previous way of working where, as a co-chair, I > do have an agenda - to get things done, > Please read my previous comments :-) Yes to "Get Things Done"! No to handle "Things" without rough consensus! Yes to do any-"Thing " with "no hat"! > > for the good of the internet. > We have already experienced that before and we know that the "good of the Internet" is a matter of collaborative engagement of any stakeholders available. ...but! don't get me wrong, please: i have no doubt on your sincerity or capacity to act as fairly as it would be possible. Note that those who would come after you would also benefit to whatever disruption we would have agreed on now. Imagine, then, some really bad actor with own hidden *agenda* taking the position after you...what would be the safeguards? ...i stop here, while thinking to have said enough on this topic. By the way! i personally appreciate the fondamental values and expertise of Denis and i hope we would be able to get more benefit on his presence on this WG. Shalom, --sb. > Whether you consider that a 'personal' or 'professional' or 'DB' agenda is > up to you. Just to be clear, this is not the same as for the good of > 'operators'. There are many stakeholder groups in this community now. We > are no longer just > 'the operator community' or even 'the technical community'. > > So I will continue to engage with the community, push out ideas (even > crazy ideas sometimes), start and drive conversations until we get > resolutions. Incidentally, this quiet period since RIPE 86 does remind > us how busy you all are and how difficult it is for you to find the > time to get so involved with the fine detail of small technical and > operational changes to the RIPE Database. Which does fit with the > presentation I did at RIPE 86 on how to manage the RIPE Database. I > will come back to that shortly. > > cheers > denis > co-chair DB-WG > > -- > [...] -- Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/> __ #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!» ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬ «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)

2 2

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

Route(6) objects
by Kaupo Ehtnurm 12 Jul '23

12 Jul '23

Hello For example I have 2001:1234::/32 ipv6 network. And I want to start using DDoS protection service that one of my ip transit provider offers. But my edge routers are multihomed and enabling ddos protection on one transit provider lets half of the attack still come in from our other ip transit providers in case of DDoS attack. But if our ip transit provider that provides also a ddos protection would hijack the routes from us with more specific routes, then instead of traffic flowing from my other ip transit providers to my AS it flows to my DDOS protection providers AS. Route hijacking solves the problem where half of the attack still comes in to my AS from other transit providers. For in order for the DDoS protection service provider to be able to hijack the routes correctly from us we need to have more specific ROA and route(6) objects done. With ROA it is easy, I just create the following ROA: " 2001:1234::/32 max length 48 ASN AS1234" But with route(6) objects this isn't so easy, because these objects don't have max length or any other operators that it accepts. And because of that I need to hope the entire internet to accept all the /48s that fit into 2001:1234::/32 prefix if I have following route6 object: " 2001:1234::/32 AS1234". But to be correct with my db records I would need to make all the /48 route6 objects that fit into that /32 and instead of 1 object I need to create 65536 objects. First of all I would hit the object creation limit per day in ripe DB. With this limit enabled, I would create the records over 2 months. And the manageability of those records would be a nightmare. If ROAs and route(6) objects go hand-in-hand anyway for the most of the time, then why can't route objects have "max length" or somekind of operator like ROAs have? Lugupidamisega / Best regards, Kaupo Ehtnurm Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo(a)wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | [ http://www.wavecom.ee/ | www.wavecom.ee ]

9 22

Co-chairs Personal Goals versus only DB Working Group Goals
by Sylvain Baya 08 Jul '23

08 Jul '23

{thread changed to add a maybe late comment} Dear RIPE DB-WG, Hope this email finds you in good health! Please see my comments below, inline... Thanks. Le vendredi 9 juin 2023, denis walker via db-wg <db-wg(a)ripe.net> a écrit : > Hi Randy > > That would be fine if we had a very active and engaging community. Like we > had 20 years ago. > > Hi Denis, Thanks for your email, brother! No excuse! to try to bypass the reminded principle. ...imho! > But the vast vast vast majority of this community is silent on almost all > database matters. The vocal people are a handful of well known members of > the community, > > ...i suspect that it's not only an era problem; my guess is simply that it might be more a matter of natural growth of the population/community. If you check old and current stats of participation ratio, i submit that it would be *almost* influenced only by the population/community growth, with relatively nearly the same numbers of real active participants... That argument of delegitimating those who are voluntarily participating, is not convincing me... How come that those who.are participating are *blamed*? Where are, actually, the others? What's the $threshold of non-representativity? ...i would agree with a *WG's goal* tasking the DB-WG Co-chairs to find a way to have more participation than that $threshold. > whose views on many matters are also quite well known. > > Are we really able to handle more various opinions? ...i mean, you know, suppose half of the accounts subscribed show up here with theirs contributions. ...i agree that it might not be what you asked for; then maybe you should work (or ask RIPE NCC) on finding a way to address the $threshold issue, when identified. > > Sometimes someone raises a point and it gets little or no response. Like > assigning an allocation. Often the chairs know from face to face > discussions, people want this option. But there is no discussion. In > situations like this I've found that a chair needs to drive the discussion. > > Maybe you could (non exclusively): option#1: start with regular reports or blog articles to inform the whole community of those issues raised privately option#2: advise those, who choose to discuss public matters privately, to post it on list; in order to expect the support of part of the WG. option#3: collect allowed private comments to the Staff; for inclusion consideration into their next PIER [*]. > > Even if that means making an outrageous suggestion that no one will agree > to, but it generates a reaction. From the following discussion we can move > forward. > > Also sometimes a chair needs to throw ideas out into the community to move > the service forwards. The chairs talk with the NCC engineers. We often > discuss ideas that no one in the community is thinking about. If the chairs > don't then raise it with the community the idea can never be considered. > > Not sure! imho! the Staff should have a way [1] to share their experience and recommendations regarding their implementation of the Policy Manual. They should share these information on that channel...and if it no longer exists; please ask for a reboot. > So either the chairs or the NCC engineers need to be able to put ideas > into the public domain, and sometimes drive the discussion to get it > started, or technically and socially the database as a product and service > just stagnates. > > __ [*]: PIER (Policy Implementation Experience Report) *Purpose of Policy Experience Report* < https://www.arin.net/participate/meetings/reports/ARIN_34/PDF/thursday/nobi… > <quote_page2> *Purpose of Policy Experience Report* *• Review existing policies – Ambiguous text/Inconsistencies/Gaps/Effectiveness • Identify areas where new or modified policy may be needed – Operational experience – Customer feedback • Provide feedback to community and make recommendations when appropriate * </quote_page2> > I often take on this role, as well as the devil's advocate to question > what others say. I don't see it as pushing a personal agenda. I have no > personal agenda. It doesn't matter to me personally if the database evolves > or dies. It does matter to the industry and society. I have no employer or > financial interest in how the database evolves. I can look at each issue > and consider how it fits in with that old saying...for the good of the > Internet. > > This is one of the reasons why I've put myself forward again as a chair > for another couple of years. > > Thanks for your much appreciated engagement, imho! and congrates for your selection as Co-chair. > I hope in that time David can spearhead a new generation of WG chairs. > > Congratulations and welcome, Co-chair David! Maybe, raising awareness of the need to participate within your generation-peers, should be considered too...dear David :-) > > Then dinosaurs like myself (and others) can ascend into advisory positions > instead of decision making roles. > > Thanks for continuing to support the community and the DB-WG, in particular. Shalom, --sb. > > Cheers > Denis > > > > On Fri, 9 Jun 2023, 15:37 Randy Bush via db-wg, <db-wg(a)ripe.net> wrote: > >> > Some of my goals as a co-chair would be >> > - To support the moderation of the mailing list and facilitate working >> > group tasks >> > - Promote active discussion, sending summary emails to make the >> > content easier to follow >> > - Perform community outreach to raise awareness of this working group >> > and the policy process >> >> /me likes. simple, but what a chair should be doing. leave personal >> agendas at the door. >> >> randy >> >> [...] > > -- Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/> __ #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!» ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬ «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)

1 0