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

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

Minutes from our session at RIPE 91
by Rob Evans 19 May '26

19 May '26

All, Whilst preparing for our meeting tomorrow, I noticed that we do not appear to have sent the link to the minutes of our previous meeting. Apologies. With thanks to Anastasiya of the RIPE NCC for preparing them promptly, they are here: https://www.ripe.net/community/wg/active-wg/services/minutes/ripe-ncc-servi… If there are no comments within the next two weeks, I’ll ask the NCC to declare them final. Thanks, Rob

1 0

Public ENUM article and RIPE 92 Services WG discussion
by Hisham Ibrahim 12 May '26

12 May '26

Dear colleagues, I wanted to share an article on the current operational status of Public ENUM under e164.arpa. The article is based on a 2026 operational review carried out by the RIPE NCC and looks at the status of current delegations and the questions this raises for the future support of Public ENUM. I plan to present this topic during the Services Working Group session at RIPE 92, where I hope we can discuss the findings and possible next steps with the community. Article: https://labs.ripe.net/author/hisham_ibrahim/operational-review-of-public-en… Best regards, Hisham

1 0

Agenda for the RIPE NCC Services Working Group at RIPE 92
by Rob Evans 11 May '26

11 May '26

Dear all, It is little over a week until we meet in Edinburgh, for those that can make it in person (virtual participation is also welcome of course). Here is the draft agenda for our meeting at 14:00 on Wednesday 20th May: 14:00 Welcome (5 min) 14:05 RIPE NCC Strategy 2027-2031 Hans Petter Holen (20 minutes) 14:25 Assessing Our Technical Infrastructure Hans Petter Holen (20 minutes) 14:45 Operational Review of Public ENUM in e164.arpa Hisham Ibrahim (20 minutes) 15:05 Multiple LIRs, PI and Legacy Hans Petter Holen (20 minutes) 15:25 AOB, Open Mic (5 minutes) Safe travels! Cheers, Rob, Janos, Stefan

2 1

Notification of Updates to the RIPE NCC Closure Procedure
by Theodoros Fyllaridis 07 May '26

07 May '26

Dear colleagues, The RIPE NCC procedural document “Closure of Members, Deregistration of Internet Resources and Legacy Resources” has been reviewed and updated. You can find the updated document at: https://www.ripe.net/publications/docs/ripe-858/. ----------------------------------- The following amendments were made: Section 1.2.1.1 “Violation of RIPE Policies and RIPE NCC Procedures” (sub-section “Procedure”) was amended through the deletion of the text “and a reminder by postal mail” and “email and”. Section 1.2.2 “Termination with Immediate Effect” (1.2.2.c. “The Member fails to submit to the RIPE NCC a valid extract from the Commercial Trade Register or equivalent register”) was amended through the deletion of the text “and a notification by postal mail” and “and postal”. ----------------------------------- The SSA terminations based on the aforementioned grounds follow an extended period of email notifications, during which time the RIPE NCC makes every effort to contact all registered contacts. Postal mail has turned out to be rather inefficient, as it often fails to reach its destination. In addition, the address may be outdated or the recipient uncontactable. Printing and postage also create significant costs, especially for reminders rather than the actual SSA termination letter. At the same time, there is a high administrative workload for the RIPE NCC departments involved. Therefore, since email is legally binding, and members remain responsible for keeping their contact details up to date in accordance with the SSA, we see no issue in no longer sending postal mail in these instances. Kind regards, Theodoros Fyllaridis Legal Counsel RIPE NCC

1 0

Re: [cooperation-wg] Re: ENUM (e164.arpa): background, scope, and coordination steps
by Hisham Ibrahim 04 May '26

04 May '26

Dear Ruben et al, Thank you for this helpful input. This is exactly the kind of information the RIPE NCC is trying to gather as part of the current review of Public ENUM in e164.arpa. It also shows why we cannot rely only on Tier-0 query volumes or on whether delegations formally exist. The more complete operational picture lives at the Tier-1 level and below, where national delegations are actually managed and where any reliance on the infrastructure would be visible. We appreciate the clarification that 1.3.e164.arpa remains maintained, that the contact information is current, that DNSSEC is in place, and that revocation is not being sought. We will follow up with ISOC NL and SURF soon to better understand the use cases and any further information that could help inform the review. Kind regards, Hisham Ibrahim RIPE NCC On Sat, 2 May 2026 at 16:40, Ruben Brave <brave(a)entelligence.nl> wrote: > Dear Hisham, dear colleagues, > > Thank you for the continued transparency around this process, and for your > 6 April update acknowledging that framing this discussion primarily in > terms of closure is premature. We agree, and would like to contribute the > perspective that has so far been missing from this thread: that of an > active national delegating authority. > > Internet Society Netherlands (ISOC NL) holds the delegation for > *1.3.e164.arpa*, covering the Dutch country code (+31), with SURF > providing the technical infrastructure. The delegation is operationally > sound, contact information is current, and DNSSEC is in place. We do not > intend to request revocation. > > More importantly, we are actively exploring forward-looking applications > for the +31 delegation. The principle at the heart of ENUM, linking a > regulated, government-authorised numbering resource to verifiable Internet > identifiers through a standards-based, DNSSEC-signed framework, is gaining > renewed relevance in the context of the IP interconnection transition, > DNS-based identity verification, and European digital identity frameworks. > We are engaged with national stakeholders, including the Dutch Ministry of > Economic Affairs and Climate Policy (EZK), to assess how this > infrastructure can meet these emerging needs. > > We therefore support Marco Hogewoning's call for further study before any > conclusions are reached and specifically echo his point that low query > volume at the Tier-0 level is a poor proxy for actual reliance on the ENUM > protocol and national delegations. The relevant signal is at the Tier-1 > level and below, which is precisely where active national delegations like > ours operate. > > We look forward to the RIPE 92 session and would welcome the opportunity > to contribute the Dutch delegating authority's perspective directly. We are > also happy to coordinate with RIPE NCC and SURF on providing more granular > usage data from 1.3.e164.arpa specifically, if that would support a more > complete factual basis for this discussion. > > Met vriendelijke groet, > Kind regards, > > Ruben Brave <http://www.rubenbrave.com/> > Chairman (voorzitter(a)isoc.nl, +31 (0)6 53 868 270) > > > [image: Internet Society Nederland logo] > Internet Society Nederland <https://isoc.nl/contact/>, Royal Library of > the Netherlands > <https://en.wikipedia.org/wiki/Royal_Library_of_the_Netherlands>, Prins > Willem-Alexanderhof 5, 2595 BE the Hague > <https://goo.gl/maps/EKZGbhFwUkHTrhLe9> > > [image: 2026-Giga-Chapter Badge 1080x1080.png] > <https://isoc.nl/nieuws/voor-het-derde-jaar-op-rij-isoc-nederland-opnieuw-be…> > > ___________________________________________________ > > > > Met vriendelijke groet, > Kind regards, > > <https://rubenbrave.com?promo=email_sig&utm_source=product&utm_medium=email_…> > Ruben Brave > rubenbrave.com > <https://rubenbrave.com?promo=email_sig&utm_source=product&utm_medium=email_…> > Ruben Brave <http://bit.ly/profile-rubenbrave> > Managing Partner > +31 (0)6 53 868 270 > Entelligence bv <https://www.entelligence.nl/>, Keizersgracht 62, 1015 > CS Amsterdam > > > * * * * * * * > Book a meeting with me: > https://calendly.com/rbrave > ----- > To unsubscribe from this mailing list or change your subscription options, > please visit: > https://mailman.ripe.net/mailman3/lists/cooperation-wg.ripe.net/ > As we have migrated to Mailman 3, you will need to create an account with > the email matching your subscription before you can change your settings. > More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

1 0

reg-nr entity types
by Cynthia Revström 04 May '26

04 May '26

Hi db-wg and ncc-services-wg, I'm not sure if this necessarily belongs in db-wg or ncc-services-wg but I felt like it might be of interest to both. Now that the reg-nr fields have been populated I have noticed some interesting places where it is present and where it is omitted. As far as I understand it, it is supposed to be omitted from orgs referring to natural persons (I assume including sole proprietors) and government agencies while being included for basically all other kinds of entities. When looking at the data for some Swedish entities I noticed that for both non-profit associations and government agencies, there were those with reg-nr and those without. I would expect non-profits to have reg-nr (except for the cases when they don't have one) while I would expect gov agencies not to have one. One example of a gov agency having reg-nr is SUNET, the Swedish NREN: ORG-SA58-RIPE As SUNET is also the employer of one of the current RIPE NCC EB members I would expect that the NCC would be somewhat familiar with the fact that it is a gov agency. I highlighted that I was worried about this kind of issue when we discussed this proposal in the db-wg in November so I can't say that I'm too surprised. I am however thankful that I at least haven't observed any cases of a natural person having a reg-nr on them as that was my biggest worry by far. -Cynthia

2 1

ENUM (e164.arpa): background, scope, and coordination steps
by Hisham Ibrahim 08 Apr '26

08 Apr '26

Dear colleagues, This message summarises recent discussion regarding ENUM (e164.arpa) and clarifies the scope and next steps. The RIPE NCC has operated the e164.arpa registry for many years under instructions and coordination arrangements established with the ITU-T and IAB. These arrangements, and the operational context for how the registry is run, are described here: https://www.ripe.net/manage-ips-and-asns/dns/enum/iab-instructions/ Recently, a request was raised in the RIPE Database Working Group to support ENUM (e164.arpa) in RDAP for querying the RIPE Database. We noted that RDAP support for ENUM is not currently implemented, but could be added if there is clear interest. We also checked current query patterns and found a few hundred ENUM-related queries per day in DNS and in Database; so low usage, but not zero. Following discussion on the Database WG mailing list, including replies in support, we proposed implementing RDAP support for ENUM. While this is a limited operational change, it was recognised that anything touching E.164 and e164.arpa can raise political questions that go beyond the purely technical. As e164.arpa is directly linked to the ITU E.164 numbering system, the relevant points of contact are typically national administrations and the entities they designate. This led us to consult ITU-T Study Group 2 to clarify the status of ENUM and its usage and needs for ongoing support. ITU-T will ask member states for their feedback and share this with us. ITU-T provides an established and coordinated channel to reach those administrations, and importantly confirm whether any delegating authorities still rely on the service, so our technical decisions are informed by real-world use and help us avoid unnecessary operational risk, confusion, or compliance headaches (including in the context of regulatory frameworks such as NIS2). We are also reaching out to the IAB regarding these operations, which the RIPE NCC performs under its instruction on behalf of the global DNS and Internet community. I am sharing this message with the DNS, Database, Cooperation and 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 Services WG mailing list. Best regards, Hisham Ibrahim Chief Community Officer, RIPE NCC

3 4

Re: ENUM (e164.arpa): background, scope, and coordination steps
by Hisham Ibrahim 07 Apr '26

07 Apr '26

Hi Sergey, Thank you, that is a fair point. To provide some additional context now, the assessment I referred to was based on query data shared internally for 16 February 2026 from three RIPE NCC authoritative DNS servers for the e164.arpa zone, located in Amsterdam, Paris and Mangalore. On that day, the number of queries for e164.arpa seen on those servers was as follows: - Amsterdam: 61,981 queries out of 873,948,265 total queries (0.007%) - Paris: 15,584 queries out of 161,779,569 total queries (0.009%) - Mangalore: 953 queries out of 62,438,947 total queries (0.002%) It is also important to note that these figures include traffic generated by RIPE Atlas anchors for DNSMON monitoring, and in the case of Amsterdam also include a certain amount of clearly non-meaningful or “junk” traffic. In other words, the level of genuine query traffic appears to be lower still. That said, as I noted in my previous message, visible query volume to the public e164.arpa tree does not by itself provide a complete picture of possible reliance on ENUM-related mechanisms more broadly. This is one of the reasons we are trying to gather broader input before drawing conclusions. I will make sure that this context is also reflected in the RIPE 92 presentation. Best regards, Hisham

1 0