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

NCC Services WG at RIPE 93
by Rob Evans 02 Sep '26

02 Sep '26

Dear all, It is eight weeks until the RIPE NCC Services Working Group meeting as part of RIPE 93 in Sofia. If you have something that you would like to discuss in the session, please drop a line to the co-chair team at <ncc-services-wg-chairs(a)ripe.net>. The WG co-chairs are also discussing with the RIPE NCC how to make the best use of the time during the meeting. The autumn meeting is also where one of the co-chairs stands down at the end of their term. We will send an announcement for that about four weeks before the meeting, but if you are interested in helping co-chair the working group, please have a think about that and approach the co-chair team if you have any questions. Please do not post any intentions to stand to the working group list. All the best, Rob, Janos, Stefan

1 0

Re: New subject: Draft liaison statement on Public ENUM under e164.arpa for the September 2026 ITU-T Study Group 2 meeting
by Lars-Johan Liman 25 Aug '26

25 Aug '26

Jim, All, FWIW, I support Jim's proposed text. Best regards, /Liman -- #---------------------------------------------------------------------- # Lars-Johan Liman, M.Sc. ! E-mail: liman(a)netnod.se # Senior Systems Specialist ! Mobile: +46 708 - 54 06 66 # Netnod AB, Stockholm ! https://www.netnod.se/ #----------------------------------------------------------------------

1 0

Fwd: Draft liaison statement on Public ENUM under e164.arpa for the September 2026 ITU-T Study Group 2 meeting
by Hisham Ibrahim 25 Aug '26

25 Aug '26

Dear colleagues, I am sharing this message the DNS, Database, RIPE NCC Services Working Group mailing lists to ensure all relevant working groups are informed. If you wish to share thoughts in response, please reply to the thread on the RIPE NCC coop-WG mailing list. Regards Hisham ---------- Forwarded message --------- From: Hisham Ibrahim <HMI(a)ripe.net> Date: Mon, 17 Aug 2026 at 17:40 Subject: Draft liaison statement on Public ENUM under e164.arpa for the September 2026 ITU-T Study Group 2 meeting To: <cooperation-wg(a)ripe.net> Dear colleagues, Following the earlier discussions on Public ENUM under e164.arpa, I have prepared the following draft liaison statement for the September 2026 ITU-T Study Group 2 meeting. In my draft I tried to: - clarify the RIPE NCC’s position following SG2-C-0196*, - support the confirmation of the revised interim procedures**, - outline how the responses to TSB Circular 123*** could inform the treatment of individual delegations, - and provide an updated overview of the operational status of the current delegations. I would appreciate feedback on my draft and I would appreciate it if you could share any comments or concerns, particularly on the technical, procedural or governance aspects, by 25 August, so that the RIPE NCC can incorporate the feedback before finalizing the submission. Many thanks in advance for your review. Regards, Hisham * https://www.ripe.net/media/documents/ENUM_liaison_statement_ITU_T_SG2.pdf ** https://www.itu.int/en/ITU-T/inr/enum/Pages/procedures.aspx *** https://www.itu.int/md/T25-TSB-CIR-0123/en To: ITU-T Study Group 2, September 2026 Meeting Title: RIPE NCC liaison statement on ENUM (e164.arpa) Dear colleagues, The RIPE NCC thanks ITU-T Study Group 2, the Telecommunication Standardization Bureau, the Internet Architecture Board, Member States and ENUM delegation operators for their continued engagement concerning Public ENUM under e164.arpa. The RIPE NCC operates the e164.arpa zone as the IAB’s designated operator under the established coordination arrangements involving the IAB, ITU-T and the RIPE NCC. 1. RIPE NCC position At the February 2026 meeting of Study Group 2, the RIPE NCC submitted contribution SG2-C-0196. The contribution arose from an operational question concerning support for ENUM domain objects through the Registration Data Access Protocol, but also raised broader questions concerning the future status of ENUM and e164.arpa. Following subsequent engagement with the IAB, ENUM delegation operators and members of the RIPE community, the RIPE NCC recognizes that those broader questions did not accurately reflect the established distribution of responsibilities. This statement therefore clarifies and supersedes the relevant parts of SG2-C-0196. For the avoidance of doubt, the RIPE NCC supports the continued operation of Public ENUM under e164.arpa and is not proposing its closure. SG2-C-0196 no longer represents a request for Study Group 2 to determine the technical or architectural future of ENUM or e164.arpa. Any future consideration of a system-wide change would require coordination involving the IAB, the relevant IETF and ITU-T processes, the RIPE NCC and affected stakeholders. 2. Operational status and revised procedures The RIPE NCC has reviewed the 46 current delegations recorded in the RIPE Database. Of these, 23 showed no DNS issue at the top delegation level, 17 appeared non-operational and six showed partial DNS issues. These findings identify a registry-maintenance and data-accuracy issue. They do not provide a sufficient basis for a system-wide conclusion concerning Public ENUM or e164.arpa. The RIPE NCC therefore welcomes the revised Interim procedures for Geographic Country Codes (ENUM administration ad interim) contained in TD423 Rev.1/PLEN. The revised procedures provide an appropriate mechanism for addressing individual non-operational or expired temporary delegations while preserving functioning delegations and the ability of Member States to confirm, update, withdraw or subsequently restore their delegations. Responses to TSB Circular 123 may provide useful information concerning the status and intentions of individual national delegations. The RIPE NCC considers that such information should inform individual cases under the revised procedures, rather than a system-wide conclusion concerning Public ENUM or e164.arpa. 3. Request to Study Group 2 The RIPE NCC respectfully invites Study Group 2 to: - confirm that the revised procedures contained in TD423 Rev.1/PLEN will come into force at the September 2026 meeting and will provide the applicable mechanism for addressing individual non-operational or expired temporary delegations; and - continue coordination with the IAB, the RIPE NCC, the relevant IETF processes and affected stakeholders on any broader questions concerning the technical or long-term status of ENUM and e164.arpa. Once the revised procedures come into force, the RIPE NCC intends to apply them systematically and transparently, including by refreshing its technical assessment, engaging with relevant delegation operators where possible and submitting substantiated cases to TSB. The question of Registration Data Access Protocol support is separate from the continued operation of Public ENUM and will be considered through the appropriate technical and community processes. The RIPE NCC remains committed to working constructively with Study Group 2, TSB, the IAB, Member States, delegation operators and the RIPE community to maintain e164.arpa in a stable, accurate and technically sound manner.

4 3

New on RIPE Labs: Multiple LIR Accounts, Looking Back and Thinking Ahead
by Marco Schmidt 12 Aug '26

12 Aug '26

Dear colleagues, We have published a new article on RIPE Labs reflecting on how multiple LIR accounts evolved from a practical exception for a handful of members into a source of operational complexity, and why, currently, we have an opportunity to address the issue with relatively limited impact on the membership. Read on RIPE Labs: https://labs.ripe.net/author/marco_schmidt/multiple-lir-accounts-looking-ba… We plan to present on this topic at RIPE 93 and welcome your comments and feedback on this mailing list. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC

1 0

Missing DANE records for RIPE MXes
by David 'equinox' Lamparter 31 Jul '26

31 Jul '26

Hi all, on June 5th this year, @ripe.net MXes were impacted for about a day due to incorrectly deployed TLSA records. This got fixed relatively quickly after poking people, with correct TLSA records getting added. The issue back then was caused by RIPE operational choices to rotate the private keys whenever the certificates are refreshed through ACME, rather than just the certificate. In an attempt to not have to update the records each time, the TLSA records referenced multiple Let's Encrypt *intermediate* CA's fingerprints rather than the end certificate/key. Let's Encrypt then issued certificates for ripe.net with a different intermediate CA that was not listed. From certificate validity times, I can see that it can't have been broken for more than roughly a day. The less-than-a-day delay to this getting caught does IMHO indicate that this is used and validated by MTAs. With this being SMTP, in most cases, you won't even get a mail delivery warning by that point yet, the outgoing MTA would still have mails in its queue and be retrying them. Less than a day is basically "this was noticed immediately" for SMTP. Unfortunately roughly on June 17th, all TLSA records were removed, leaving e-mails to ripe.net no longer DANE-protected. They're still absent as of a few minutes ago. This means that most MXes will fail open and deliver mails to ripe.net without TLS if something tampers with the connection to remove the STARTTLS advertisement. ("hyperscaler" MTAs are a separate problem because those use MTA-STS and not DANE; but that requires the MTA to have an HTTP client which most FOSS ones don't by default.) I would really like to have those TLSA records reinstated, or rather, any kind of TLSA record is fine - purely for fail-closed behavior, to prevent stripping of TLS. It's generally not recommended practice to put root certificate fingerprints in there, but if that's what's doable (putting Let's Encrypt root fingerprints in it), that's fine. Actual end certificate fingerprints would of course be better, but that does need DNS updates when the private keys change. It would be a little disheartening to have ripe.net not be leading by example on this. Best practice to ensure TLS gets used is DANE (plus MTA-STS). We're pushing so hard for RPKI and then failing on e-mail security? :( Hope this can be fixed, equi (David)

2 1

Minutes from RIPE 92
by Rob Evans 08 Jul '26

08 Jul '26

Dear all, With many thanks to Antony at the RIPE NCC for a difficult job, the draft minutes of our session in Edinburgh are now available. https://www.ripe.net/community/wg/active-wg/services/minutes/ripe-ncc-servi… Please let the co-chairs know of any errors and omissions. As you know, we were time-limited during the session, in particular for comments to Hisham and Gabor. If you think the discussion of any topic covered by the minutes should continue, please feel free to carry on the conversations here on the WG list. Meanwhile, we will consider how we structure the session at RIPE 93 to allow more time for discussion. Thanks, Rob, Stefan, Janos

1 0

RIPE Labs Article on the Need for Independent Infrastructure
by Hans Petter Holen 16 Jun '26

16 Jun '26

Dear colleagues, Following my presentation in the RIPE NCC Services Working Group at RIPE 92, I have published an article about our plans to reinvest in independent, self-hosted infrastructure: https://labs.ripe.net/author/hans_petter_holen/independent-infrastructure-r… The article explains why we have reassessed parts of our cloud strategy, what this means for our infrastructure planning, and why this will require significant investment over the coming years. We are still in the early stages and do not yet have all the answers. However, we want to be transparent as this work develops, and welcome any comments from the working group. Kind Regards, Hans Petter Holen Managing Director and Chief Executive Officer RIPE NCC

1 0

RIPE NCC Quarterly Planning Q3 2026
by Boris Duval 11 Jun '26

11 Jun '26

Dear colleagues, We have now published the upcoming quarterly plans for our development teams: https://www.ripe.net/quarterly-planning We publish these plans each quarter to showcase the work items we will be carrying 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, Boris Duval Communications Officer RIPE NCC

1 0

Fwd: NOG Feedback to the RIPE NCC Strategy 2027-2031
by Patrick Bussmann 22 May '26

22 May '26

(resending to ncc services wg) Dear RIPE Members, Dear RIPE NCC Executive Board, Dear RIPE NCC Strategy Team, Throughout the week of RIPE92 the Network Operator Groups of the RIPE Service Region have been reviewing the draft RIPE NCC strategy proposal for 2027 - 2031 which was put forward for discussion and request for feedback. From a NOG perspective it is our opinion that not referencing and prioritising Network Operator Groups (NOGs) explicitly in the strategy and the key focus areas for the next 5 years is a miss and clearly puts a core foundation of the RIPE community at a disadvantage, especially in a world where budgets are limited and budget discussion will always be held along priorities and focus areas. The RIPE NCC as well as the RIPE NCC Executive Board have prioritised focus and investment into cooperation and support of Network Operator Groups over the last years and we believe this should at a minimum continue at the same level. Therefore we are submitting, officially and within commenting timelines, attached feedback to the RIPE NCC Strategy 2027-2031, supported by the following NOGs: DENOG (German Network Operators Group), NetUK LUNOG (through LU-CIX) RONOG (through InterLAN-IX) GRNOG (Greek / Hellenic NOG) PTNOG RSNOG (Serbian NOG) NLNOG (Dutch Network Operators Group) NONOG (Norwegian Network Operators Group) ESNOG (Spain / España NOG) nog.fi (Finland) ITNOG (Italian NOG) SwiNOG (Swiss Network Operators Group) FRnOG (France) We are looking forward to your engagement and feedback. For the supporting NOGs, Patrick Bussmann Chairman of the Board - DENOG -- --- DENOG e.V. | Schlesierstr. 14, 85368 Moosburg a.d.Isar Vorstand: Patrick Bußmann, Moritz Frenzel, Tim Kleefass Registergericht AG Frankfurt VR 16234 St.-Nr. 014 255 15777 / VAT ID DE319546939

1 0

Today's session
by Rob Evans 20 May '26

20 May '26

Dear all, I wanted to note that the session today could have gone better, and your co-chairs will be thinking about how we handle future sessions. We will take the blame for that. There is a limit to how far we over-run due to the subsequent General Meeting, and out of respect to the stenographers, note-takers, and participants who may have other commitments. The presenters need to provide enough information for people to react to and comment on, and that must balance with the amount of time for that discussion. In the majority of meetings the discussion is limited. We knew that would be different today, which is why I made a point of asking speakers to keep to time and participants at the microphone to keep their comments concise. I will find out what happened to Marco’s audio, but one lesson learned is that there needs to be an effective two-way communication between the room and remote participants. Meanwhile, can I encourage participants to take the topics up on the list? All the best, Rob

2 1