- ncc-services-wg - mailman.ripe.net

RIPEstat database migration postponed
by Felipe Silveira 26 Sep '24

26 Sep '24

Dear colleagues, Following Monday’s announcement, we have decided to postpone the move of our largest datasets (HBase) to a new environment by one month. As I mentioned in my last email, this has been an unexpectedly complex process that has required a massive effort from our engineering teams. To ensure that RIPEstat will continue operating, we did not feel confident going ahead when this could result in the service being severely disrupted. I am sure many of you have questions. We plan to publish a RIPE Labs article with more details soon, including which historical data will be delayed when the migration is fully completed. Kind regards, Felipe Victolla Silveira Chief Technology Officer RIPE NCC

1 0

Some historical RIPEstat data will not be available from 24 September
by Felipe Silveira 23 Sep '24

23 Sep '24

Dear colleagues, As we shared back in May, we have been working to reduce our data centre footprint by managing the data for RIS and RIPEstat more efficiently[1]. We have experienced some problems which mean that parts of the historical RIPEstat data will not be available for an extended period. To reduce our data centre usage, we have been exporting RIS-related datasets from the database that contains our largest datasets (HBase) to a new environment, which allows us to decommission our old Hadoop cluster. During the migration, we encountered timeouts and memory limitations with old servers and software that held historical data. Here we faced a difficult choice: we could either extend our data centre contracts at considerable additional cost, or we could accept that certain historical data would not be available to users for an extended period. We decided on the second approach. It is important to be clear that we haven’t lost anything here. However, this does mean that we will not be able to provide aggregated historical data for a number of API calls and their corresponding widgets for some time after we complete our migration. These include: as-path-length, as-routing-consistency, asn-neighbours, asn-neighbours-history, bgp-update-activity, bgp-state, bgp-updates, bgplay, ris-peerings, routing-status, visbility. As mentioned, this has been a difficult process. We may still encounter other issues when we make the switch to the new environment tomorrow (24 September). My team is doing their utmost to keep any disruption to a minimum, but there are no guarantees everything will go to plan. We will be looking at the most efficient way to rebuild access to the historical data in the coming months, and we will share more details in an article on RIPE Labs soon. Kind regards, Felipe Victolla Silveira Chief Technology Officer RIPE NCC [1] For more on this, refer to the following: - Reducing our Data Centre Footprint (RIPE Labs): https://labs.ripe.net/author/felipe_victolla_silveira/reducing-the-ripe-ncc… - RIPE 88 Technology Update (slides 10-20): https://ripe88.ripe.net/wp-content/uploads/presentations/89-RIPE-88-RIPE-NC…

1 0

RIPE NCC Open House: Draft Activity Plan and Budget 2025
by Hans Petter Holen 20 Sep '24

20 Sep '24

Dear all, In October, we will publish the Draft Activity Plan and Budget for 2025 ahead of the Autumn General Meeting. The document outlines our proposed activities for the coming year and how we plan to fund them. It’s a key opportunity for you to read our plans and help shape the direction of our organisation. Once the draft is published, we encourage you to share your feedback on the members-discuss mailing list. We will also host an Open House session where you can ask questions and discuss the draft with me, my team and the Executive Board. Open House: Draft Activity Plan and Budget 2025 Date: 9 October Time: 11:00 - 12:30 (UTC+2) Register: https://www.ripe.net/draft-activity-plan-open-house-2025 At the Open House, you will have the chance to provide direct feedback to the Executive Board and RIPE NCC Management. Afterwards, we will discuss the draft document during the General Meeting (GM), held alongside RIPE 89 on Wednesday, 30 October 2024. All feedback will be considered, and the final version will be published in December 2024. If you are a member and wish to attend or vote in the GM, you will need to register via the General Meeting section in my.ripe.net. You can find more information about the GM and how to register at: https://www.ripe.net/gm/oct2024 Kind regards, Hans Petter Holen Managing Director and CEO RIPE NCC

1 0

RIPE NCC Services WG at RIPE 89
by Rob Evans 03 Sep '24

03 Sep '24

Dear all, We are about eight weeks away from RIPE 89 in Prague. If you have any topics you'd like to present at the NCC Services Working Group on Wednesday afternoon, please let the WG chairs know via <ncc-services-wg-chairs(a)ripe.net <mailto:ncc-services-wg-chairs@ripe.net>>. A reminder that Bijal’s term is up at RIPE 89 and we are looking for a new co-chair. If you are interested, please feel free to speak to any of us, and have a look at the following resources ahead of opening the call for volunteers: RIPE NCC Academy: RIPE Working Group Chair Training https://academy.ripe.net/enrol/index.php?id=16#section-1 A Guide for New RIPE Working Group Chairs https://www.ripe.net/publications/docs/ripe-765/ RIPE Working Group Chair Job Description and Procedures https://www.ripe.net/publications/docs/ripe-692/ Mailing List Guidelines for RIPE Working Group Chairs https://www.ripe.net/publications/docs/ripe-764/ Cheers, Rob On behalf of your friendly WG co-chairs — Bijal, Janos, Rob

1 0

Re: [db-wg] Changes to the RIPE Database Acceptable Use Policy and Daily Limit Accounting
by Daniel Suchy 07 Aug '24

07 Aug '24

Hello, this discussion is annoying and in the circle. You're still trying to give the term "IP address" a different meaning than it has. IP address is IP addres. Period. It's not a subnet of any size, as you're trying to say. AUP clearly talks about IP address, not about end-user site etc. You put that in there arbitrarily. You are trying to give a strange interpretation of a standard technical term, which, however, has a clearly defined meaning. To defend yourself, you're thinking of hypothetical scenarios. But these can similarly occur with both IPv4 and IPv6. But as as a result, using IPv6 is a disadvantage now, you artificially penalize IPv6 more than IPv4. I can have IPv4 LAN with /24 and I'll no face any issue, but I'll have on LAN even with /64 IPv6. It's just stupid what you're doing. In fact, what the NCC tells us here is to turn off IPv6 and we'll be fine. And as it was already mentioned by Denis at db-wg, there're much more ways to scrap personal data if someone really wants to do that. But your pseudo-protection code is only throwing the baby out with the bath water. And create unnecessary problems for users on IPv6, thanks to developers incompetence (or laziness?). I understand, some employees and RIPE NCC doesn't understand IPv6 basics and make no difference between IP address and IP subnet (site). But there's a difference. Again. IPv6 address has 128 bits, not 64 bits, which NCC staff uses for AUP accounting. I raise question to services WG: How it's possible that an employees of RIPE NCC interprets standard terminology in such strange way and bends the written rules in the direction they are not written? Who approved the blocking of the entire subnet, when even AUP exactly says that IP addresses should be blocked in case of violation? Who is responsible for this creativity? I would like to hear the answers, because it seems that there is anarchy in NCC and the developers implements what they want, not what they should (with respect to published rules/documents). - Daniel On 8/6/24 3:45 PM, Edward Shryane wrote: > Hello Daniel, > >> On 6 Aug 2024, at 10:01, Daniel Suchy <danny(a)danysek.cz> wrote: >> >> Hello, >> >> On 8/5/24 3:32 PM, Edward Shryane wrote: >>> The current system is a compromise between allowing queries containing personal data, and complying with the Acceptable Use Policy: >>> https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… >> >> The current system is a design bug, not a compromise. >> > > It was a deliberate choice to account by /64 prefix size for IPv6 (the smallest subnet size) and /32 for IPv4 (the smallest prefix size). While it’s true that an IPv6 end user site could contain multiple users, this is the same for IPv4 where you could have a single public NAT address with many users behind it. However, within an IPv6 /64 end user site, the user is free to configure their global address. If we account for greater than a /64 then it becomes trivial for a user to change their host address and avoid the limit accounting. Changing the accounting to limit both by /128 and /64 prefixes complicates the implementation and operation of the system and the user must still comply with the AUP daily limit of 1,000 objects (it’s just harder to identify them). > > To avoid getting blocked, a user (one or many) must reduce the queries for objects containing personal information, no matter how the accounting is done. > >> Acceptable Use Policy clearly defines limits per IP address (without distinguishing whether IPv4 or IPv6). >> > > Using a /64 as the smallest subnet size is a reasonable compromise for the implementation, given the huge address space and how trivial it is to change host address, to avoid the accounting. Furthermore, if we account for every single /128 address, this would allow malicious actors to DDoS the accounting by simply sending each query from a new, different IPv6 address. > > >> Your implementation at this time blocks whole /64 subnet in case of IPv6, not only single address violating AUP. >> > > See above. A single user can be assigned a whole /64 subnet. > >> >>> The limit is 1,000 objects that could contain personal data, which is not normally reached by most users (< 0.02%), and it is clear what can be done if this is exceeded. >> >> The limit value isn't problem as well as limiting the number of queries per IP address. But the developers probably wanted to make their life easier and implemented the AUP incorrectly. >> >> Blocking entire subnets as an initial reaction simply isn't the spirit of AUP. IPv6 address has 128 bits, not only 64 you're using - whatever the "reason" is. >> > > We do not want to make it easier to avoid the AUP limit. > >>> Rather than re-write the accounting code, can the community review why objects containing personal data is returned by default? Can we make "-r" the default? >> >> If code contains bug (and that's now quite clear), it needs to be fixed regardless of the data returned with the default settings. >> > > Again, there was a deliberate decision to account by /64 and it’s not an implementation bug. > >> >> I personally don't consider as a bad idea not to display personal data at all (have "-r" as default), it's important that the abuse contact is always displayed (and it is, even with "-r"). But that's different topic. >> >> - Daniel >> > > Changing the accounting implementation does not fix the root cause in terms of why users are getting blocked. By default, RIPE Database queries are returning referenced personal data that the user did not ask for. Rather than change the accounting, we can change the default query behaviour. Users should be accountable for the personal data that they requested. > > In conclusion, there are good reasons for the current implementation, but if there is consensus for reviewing how AUP accounting is done, then we will prioritise it. > > Regards > Ed Shryane > RIPE NCC >

2 1

Re: [db-wg] Changes to the RIPE Database Acceptable Use Policy and Daily Limit Accounting
by Daniel Suchy 07 Aug '24

07 Aug '24

Hello, this discussion is annoying and in the circle. You're still trying to give the term "IP address" a different meaning than it has. IP address is IP addres. Period. It's not a subnet of any size, as you're trying to say. AUP clearly talks about IP address, not about end-user site etc. You put that in there arbitrarily. You are trying to give a strange interpretation of a standard technical term, which, however, has a clearly defined meaning. To defend yourself, you're thinking of hypothetical scenarios. But these can similarly occur with both IPv4 and IPv6. But as as a result, using IPv6 is a disadvantage now, you artificially penalize IPv6 more than IPv4. I can have IPv4 LAN with /24 and I'll no face any issue, but I'll have on LAN even with /64 IPv6. It's just stupid what you're doing. In fact, what the NCC tells us here is to turn off IPv6 and we'll be fine. And as it was already mentioned by Denis at db-wg, there're much more ways to scrap personal data if someone really wants to do that. But your pseudo-protection code is only throwing the baby out with the bath water. And create unnecessary problems for users on IPv6, thanks to developers incompetence (or laziness?). I understand, some employees and RIPE NCC doesn't understand IPv6 basics and make no difference between IP address and IP subnet (site). But there's a difference. Again. IPv6 address has 128 bits, not 64 bits, which NCC staff uses for AUP accounting. I raise question to services WG: How it's possible that an employees of RIPE NCC interprets standard terminology in such strange way and bends the written rules in the direction they are not written? Who approved the blocking of the entire subnet, when even AUP exactly says that IP addresses should be blocked in case of violation? Who is responsible for this creativity? I would like to hear the answers, because it seems that there is anarchy in NCC and the developers implements what they want, not what they should (with respect to published rules/documents). - Daniel On 8/6/24 3:45 PM, Edward Shryane wrote: > Hello Daniel, > >> On 6 Aug 2024, at 10:01, Daniel Suchy <danny(a)danysek.cz> wrote: >> >> Hello, >> >> On 8/5/24 3:32 PM, Edward Shryane wrote: >>> The current system is a compromise between allowing queries containing personal data, and complying with the Acceptable Use Policy: >>> https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… >> >> The current system is a design bug, not a compromise. >> > > It was a deliberate choice to account by /64 prefix size for IPv6 (the smallest subnet size) and /32 for IPv4 (the smallest prefix size). While it’s true that an IPv6 end user site could contain multiple users, this is the same for IPv4 where you could have a single public NAT address with many users behind it. However, within an IPv6 /64 end user site, the user is free to configure their global address. If we account for greater than a /64 then it becomes trivial for a user to change their host address and avoid the limit accounting. Changing the accounting to limit both by /128 and /64 prefixes complicates the implementation and operation of the system and the user must still comply with the AUP daily limit of 1,000 objects (it’s just harder to identify them). > > To avoid getting blocked, a user (one or many) must reduce the queries for objects containing personal information, no matter how the accounting is done. > >> Acceptable Use Policy clearly defines limits per IP address (without distinguishing whether IPv4 or IPv6). >> > > Using a /64 as the smallest subnet size is a reasonable compromise for the implementation, given the huge address space and how trivial it is to change host address, to avoid the accounting. Furthermore, if we account for every single /128 address, this would allow malicious actors to DDoS the accounting by simply sending each query from a new, different IPv6 address. > > >> Your implementation at this time blocks whole /64 subnet in case of IPv6, not only single address violating AUP. >> > > See above. A single user can be assigned a whole /64 subnet. > >> >>> The limit is 1,000 objects that could contain personal data, which is not normally reached by most users (< 0.02%), and it is clear what can be done if this is exceeded. >> >> The limit value isn't problem as well as limiting the number of queries per IP address. But the developers probably wanted to make their life easier and implemented the AUP incorrectly. >> >> Blocking entire subnets as an initial reaction simply isn't the spirit of AUP. IPv6 address has 128 bits, not only 64 you're using - whatever the "reason" is. >> > > We do not want to make it easier to avoid the AUP limit. > >>> Rather than re-write the accounting code, can the community review why objects containing personal data is returned by default? Can we make "-r" the default? >> >> If code contains bug (and that's now quite clear), it needs to be fixed regardless of the data returned with the default settings. >> > > Again, there was a deliberate decision to account by /64 and it’s not an implementation bug. > >> >> I personally don't consider as a bad idea not to display personal data at all (have "-r" as default), it's important that the abuse contact is always displayed (and it is, even with "-r"). But that's different topic. >> >> - Daniel >> > > Changing the accounting implementation does not fix the root cause in terms of why users are getting blocked. By default, RIPE Database queries are returning referenced personal data that the user did not ask for. Rather than change the accounting, we can change the default query behaviour. Users should be accountable for the personal data that they requested. > > In conclusion, there are good reasons for the current implementation, but if there is consensus for reviewing how AUP accounting is done, then we will prioritise it. > > Regards > Ed Shryane > RIPE NCC >

6 9

Minutes from the NCC Services WG meeting at RIPE 89
by Rob Evans 12 Jul '24

12 Jul '24

Hi, With thanks to Antony Gollan from the RIPE NCC, the draft minutes from our meeting at RIPE 88 are here: https://www.ripe.net/community/wg/active-wg/services/minutes/ripe-ncc-servi… Please let us know of any errors or omissions, and we will get them rectified before we approve the minutes formally at RIPE 89. I’d like to remind the working group that we will have a selection process for a new co-chair at RIPE 89, and encourage potential candidates to speak to one of the current co-chairs if you want to know what the role entails. Cheers, Rob

1 0

Mailing Lists Migration from Mailman 2 to Mailman 3
by Timour Bakeev 02 Jul '24

02 Jul '24

Dear colleagues, In response to the community concerns regarding using the outdated Mailman 2 software for the RIPE mailing lists, RIPE NCC is starting the migration process to the Mailman 3 software suite. This upgrade will enhance the user interface and message archives for these lists. We expect to complete this work by 14 July 2024. Previously, we successfully updated our internal mailing lists to Mailman 3 and the ASO and NRO mailing lists, containerising them in the process. This latest migration extends those improvements to these external mailing lists as well. What will change? Mailman 2 and Mailman 3 are entirely different products, which brings some changes in the observed behaviour. - The location of the email archives. The new address of the archive will be: https://mailman.ripe.net/archives/list/{list-name}@ripe.net/ - The subscription address will be changed to {list-name}-join(a)ripe.net - To maintain historical links to the archives, we’re planning to turn this into a static website at: https://lists.ripe.net/ The mail delivery process for the existing subscribers will not change, so they will continue to receive emails from the lists as usual, with a potential one-time delay of up to four hours during the actual transition. The interaction with the server is also going to remain the same. Thank you for your understanding and cooperation. Kind regards, Timour Bakeev Senior System Engineer RIPE NCC

1 0

Changes to the Navigation on www.ripe.net
by Ulka Athale 01 Jul '24

01 Jul '24

Dear colleagues, Following the redesign of ripe.net, we are also working on improving the ease of access to our content. We have made some changes to the navigation menus of the website. The main changes are: - "Events" has been added as a section to the top-level navigation of the menu - "Participate" has been renamed "Membership" - The Policy Development and Internet Governance pages can now be found under "Community" You can read about these changes and other improvements planned for the website in more detail on RIPE Labs: https://labs.ripe.net/author/ulka_athale_1/a-click-away-improving-navigatio… All existing links and URLs should continue to work. If you do see any broken links, please let us know. We also welcome your input about content that you would like to access more easily or other improvements via the forum: https://forum.ripe.net/t/improving-the-navigation-on-ripe-net/1026 Kind regards, Ulka Athale -- Ulka Athale Senior Communications Officer RIPE NCC www.ripe.net

1 0

RIPE NCC Quarterly Planning Q3 2024
by Adonis Stergiopoulos 27 Jun '24

27 Jun '24

Dear colleagues, We have now published the Q3 2024 quarterly plans for our development teams: https://www.ripe.net/support/documentation/quarterly-planning These plans include the work items that will be carried out over the next quarter and give you the chance to provide your feedback and suggestions that the RIPE NCC should be working on going forward. The plans cover the following areas: - RIPE Database - Business Applications, including the LIR Portal, Registry Services and other applications. - DNS and K-root - RIPE Atlas - RIPEstat - Resource Public Key Infrastructure (RPKI) - Routing Information Service (RIS) - Information Security, Risk, and Compliance - Training and Certification Please share your suggestions on this list or the RIPE NCC Forum: https://forum.ripe.net/ Kind regards, Adonis Stergiopoulos Senior Marketing & Communications Officer RIPE NCC

1 0