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

Changes to the RIPEstat UI
by Ties de Kock 01 Oct '24

01 Oct '24

Dear colleagues, Over the next few months, we will be making changes to RIPEstat, our information service and open data platform. Most noteworthy, we will introduce a new user interface (UI) that combines elements of the two previous versions introduced in 2013 and 2020. Initially, we will focus on reverting to the 2013 UI and adding the unique features that were available only in the 2020 UI. Afterwards, we will continue building on what we have, and on what we learned, and build something better that aligns with what our users need. Finally, we will sunset the 2020 UI as we continue developing the newer user interface. Our decision was made after extensive user research whilst we maintained two interfaces for a few years, and tried to bridge the gap between the ‘old’ and ‘new’. Our aim now is not simply to bring back an older platform, but to focus on the elements that matter to RIPEstat users the most, and build on them to modernise the product altogether. You can read more details about our decision in our RIPE Labs article: https://labs.ripe.net/author/adonis_stergiopoulos/streamlining-ripestat-bui… We welcome your comments on this mailing list, on the RIPE NCC Forum or by emailing us at stat(a)ripe.net. Kind regards, Ties de Kock Specialist software engineer RIPE NCC

1 0

Resource Requests API to be decommissioned on 6 January 2025
by Marco Schmidt 01 Oct '24

01 Oct '24

Dear colleagues, We are planning to decommission the Resource Requests API on 6 January 2025. We have examined our members’ use of the Resource Requests API and saw that the number of requests through the API has decreased significantly. The API is currently used by only 17 members and requires considerable resources to maintain. Being mindful of the call from our members to cut costs where possible, we have decided to decommission this service. All members using the API will be notified individually so that they have time to adjust their tools and procedures. If you have significant issues or concerns about this, please respond to this email by the end of the week. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC

1 0

RIPE NCC Quarterly Planning Q4 2024
by Adonis Stergiopoulos 30 Sep '24

30 Sep '24

Dear colleagues, The Q4 2024 quarterly plans for our development teams are now published on our website: https://www.ripe.net/quarterly-planning Each quarter, we publish these plans to showcase the work items we will carry out over the next months. We welcome your feedback and encourage you to suggest items 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 If you have any questions or input on these plans, 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

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