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

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

Extending API Keys
by Fallon Albrecht 01 Apr '26

01 Apr '26

Dear colleagues, We are extending the API key model introduced for the RIPE Database to the remaining API Keys in the LIR Portal, providing a more secure and flexible way to manage access across services. API keys for My resources and IP Analyser can now be created directly within the services where they are used, while centrally visible and manageable via RIPE NCC Access. You can read more about these changes and what they mean for you here: https://labs.ripe.net/author/fallon-albrecht/extending-api-keys-beyond-the-… Kind regards, Fallon Albrecht Manager Business Applications

1 0

RIPE NCC Quarterly Planning Q2 2026
by Boris Duval 27 Mar '26

27 Mar '26

Dear colleagues, We have now published the upcoming quarterly plans for our development teams: https://www.ripe.net/quarterly-planning <https://www.ripe.net/support/documentation/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

Charging scheme discussions
by Rob Evans 11 Mar '26

11 Mar '26

Hi all, Whilst it is good to see discussion happening on the working group list, this is just a gentle reminder that this working group is for discussion on the services offered by the RIPE NCC. Comments about the proposed aspects of a future charging scheme should take place on <members-discuss(a)ripe.net>. Thanks! Rob (On behalf of the NCC Services WG co-chairs.)

3 5

Concerns Regarding Proposed Increased Fees for PI Resources
by Viktoriia Opanasiuk 10 Mar '26

10 Mar '26

Dear Members of the Working group, I am writing to express my concern regarding the proposals under consideration for the future RIPE NCC charging scheme, specifically the potential increase in fees for PI Assignment. Any changes to the charging scheme should take regional characteristics into account. Different countries within the RIPE service region have diverse network structures, operator sizes, and resource usage patterns. In Ukraine, PI resources are widely used to ensure network resilience and independence, and the number of organizations using PI blocks significantly exceeds the number of LIRs. This widespread use of PI addressing contributes to a decentralized, robust, and distributed Internet infrastructure. A disproportionate increase in fees for PI blocks, as currently proposed in the consultations, would place a significant financial burden on small ISPs, regional networks, and other infrastructure organizations, many of which are already operating under serious economic pressure during long-term war. This could have several unintended consequences: - Higher fees may discourage the use of PI addressing for multihoming, potentially affecting network resilience and independence. - Additional costs may strain budgets, limiting the ability to maintain robust network architectures. - PI resources are essential for redundancy and rapid traffic rerouting in the event of failures; increasing their cost could unintentionally reduce the adoption of these practices. I therefore urge the Task Force to maintain annual fees for PI resources at the current level, avoiding disproportionate financial burden on operators that rely on these resources for critical connectivity. I appreciate the efforts of the Task Force and the transparency of the ongoing consultation process, and hope that the regional specifics of Ukraine will be duly considered. -- Kind regards, Regional Director Viner Telecom ISP

1 0

Two-Factor Authentication for RIPE NCC Access Using Passkeys
by Felipe Silveira 06 Nov '25

06 Nov '25

Dear colleagues, Two-factor authentication (2FA) was made mandatory for all RIPE NCC Access accounts in March earlier this year, and we received many requests to use security keys as an authentication method. You can now use passkeys as a two-factor authentication method for RIPE NCC Access accounts, in addition to authenticator apps. Passkeys can be stored on an hardware security key (FIDO2 compatible) or in a password manager, potentially synced across devices. They are supported on mobile devices (iOS, Android) and by most browsers on computers. If you have any feedback, please contact us at ncc(a)ripe.net Kind regards, Felipe Victolla Silveira Chief Technology Officer RIPE NCC

4 5

AI and the RIPE NCC
by Janos Zsako 31 Oct '25

31 Oct '25

Dear WG Members, As most of you are probably aware, there was recently a panel discussion in the RIPE NCC Services WG session in Bucharest about AI at the RIPE NCC: https://ripe91.ripe.net/programme/meeting-plan/sessions/33/P8BNJX/ Many of you have probably attended the session either in person or remotely, but for those who did not and are interested, the panel discussion was recorded and you can watch it at any time. The panel was an interactive session with key people from different areas of the RIPE NCC: - Eleonora Pedridou, Chief Information Security Officer - Antony Gollan, Communications Manager - Gabor de Wit, Chief Registry Officer - Robert Kisteleki, Principal Engineer The first two panelists were present on the stage, while the latter two joined remotely. I do not want to go now into too much detail, but I want to summarize that the panelists, after presenting their initial thoughts, reacted to three different questions we asked from the audience via Kahoot. The three questions were about - the opportunities, - the threats - and any other so far uncovered issues related to the use of AI at the RIPE NCC. We got plenty of feedback, in the form of a Word Cloud. The panelists reacted to the items they felt to be most relevant, but obviously, due to time constraints, we were not able to cover all issues raised. I now take the opportunity to list most of the answers given to each question. I tried to list them in the order of the size they appeared on the screen, but this is by no means the order of importance as most answers had a similar size. I also tried to group similar answers. I would like to ask all of you to react to any of these items, if you feel the NCC and the community should take that aspect into consideration. Of course you are welcome to raise any issue that did not show up during the panel discussion. I think the panel discussion was great, as many opinions were expressed by the community both in the Kahoot answers and in the comments at the microphone. It would be very useful to continue this discussion on this mail list. Have fun! Best regards, Janos Opportunities: Automation, Automation of checks, Automation/assistant Efficiency, Speed Data mining Research Measurements Advisory Supporting staff Only for first draft Assistance Fast correlation Help staff Anomaly detection Sanity checking Pattern finding Smart policy search Risk analysis Planning Help support Survival Risks: Hallucination Data leaks Dehumanization Limit of diversity Security Bias False certainty Loss of control Incorrect data Climate impact Unaccountability World domination It's good to learn Data protection Future price rises No more progress Dependence Brain rot Ethical issues Copyright problems MCPs sharing Spiralling costs Untrustworthy answer Abuse Staff decrease Bubble Automation Bias Haven't considered: Environmental impact, Climate impact, The Planet, Environmental cost Costs, The long term costs, Financial costs, Future price rises, Long term cost of AI Keep right balance Dependence Green Local No AI at all? A usage POLICY! Loss of competence AI WG Precision IPR violations World domination Bots talking to bots

1 0