Dear Hisham, colleagues, As you know, but to provide the Working Group with full disclosure: in my previous role I spend a lot of time on this topic and in particular on updating the current set of instructions and operational rules that are published on the RIPE website. Apologies for the length, if I would provide an exec summary: this goes way too fast. We need to get a better grip of the risks associated with shutting down e164.arpa as a public service and the enquiries now under way via ITU TSB might open additional risks or issues down the line, including that you may have handed the decision to a multilateral process. Would recommend further studies, also to support the underlying rationale for changes to the service. This needs broad and active discussion within the internet and telecommunication communities. Must admit that, as we unfortunately did not have the resources to attend the last meeting of ITU Study Group 2, we were caught a bit of guard with the resulting TSB circular. I see the underlying contribution (SG2-C196) has not yet been posted on the RIPE NCC website and only available to ITU TIES users. It probably would help if that document and any follow-ups or responses can be made available to the RIPE Community and all other stakeholders free of charge. To the topic at hand, while the original question posted was one regarding implementing RDAP support for RIPE database object. We have now leaped and entered the "do we need ENUM at all" domain, which to me is an entirely different question. To which at this stage I also do not have an answer. I appreciate, as you expressed, the careful approach and subscribe to the need of having broad consultations with stakeholders and especially users of the ENUM protocol. I deliberately point to the protocol here, because ENUM is one of those cases where there appears to be a disconnect between use of the e164.arpa zone and its subsidiaries within the global domain name system (DNS) and the implementation and use of the protocol itself in providing a way to lookup signaling parameters for applications such as Voice-over-IP and similar technologies. I think the question as it is contained in C196 is the right one: "Whether ENUM (e164.arpa) should continue to be considered an active protocol requiring ongoing operational support." However, I think you are asking the wrong audience. In fact, the resulting question that ITU is now asking its member states has become a very straight forward binary one: "agree/not agree to the closure of the ENUM system under e164.arpa." (The TSB circular unlike the SG2 proceedings is a public document and available at https://www.itu.int/md/T25-TSB-CIR-0123/en) From the question it appears there is some misunderstanding to what ENUM is en the nature of the problem. "System" is the wrong label here I think. That or I may have misread or misunderstood the question, which to me sounded like "should we continue to have an e164.arpa tree in the global DNS?". As others pointed out, .arpa is the domain of the IAB and it should ultimately be the IAB who decides on whether to remove the deleation of e164.arpa and or whether or not to include it as part of the .arpa domain (In theory two different decisions). By itself we have now entered a risk, because the ITU member states might take a different view to the question they have been asked, than a more in depth and more technical discussion with yield. And we have to consider that this question is put to the member states under signficant time pressure with a deadline of 15 august 2026. Given all the unknowns and uncertainties, I would higly recommend further study of this problem. Or where such studies already have been done or exist, to disclose them in full to the wider audience. Especially since I can't escape the feeling that this may have originated from a focus towards e164.arpa being a cost center for the RIPE NCC and that the underlying technical rationale has not yet been fully developed. In that context, more insights on the actual annual costs (opex and capex) might also help inform the decision. The question on whether to conitnue the operations of e164.arpa is not dissimlar to the question on whether to include or remove a string from the DNS root zone. Just that e164.arpa sits one level below doesn't make it much different given its potential global use. In that context, e164.arpa is "a root" by itself and the operational rules set by the IAB also treat it as such. In this context there is probably some things to learn or even copy from ICANN and its policies. Removing a string from the root zone sounds really big and in fact it is, but in the realm of iso-3166 country codes it has happened and there is a process that describes the triggers as well as formulating a soft-landing procedure to avoid any sudden shocks. That to me is my biggest worry, sudden removal or withdrawl of e164.arpa will likely trigger some sort of shock to the bigger system. This mail is getting quite long, apologies, but to provide some rationale and hopefully set up some questions, let me explain. We have to take into account the path dependency that exists from the standardisation of ENUM as the startpoint and the RIPE NCC being the operator of the e164.arpa DNS ('root") zone. IETF RFC 6116 defines a protocol to "...the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers...", that RFC is on Standards Track. From the protocol it follows that, given its use of the DNS, it needs a place in the DNS tree, enter the creation of the e164.arpa zone. The existence of the zone is the result of the standard. That I think warrants the question of what happens if you walk the other way, i.e. if you remove the zone, what is the impact on the standard as such? Would be good to learn from IAB/IETF what the intend is on the status of RFC6116 and those standards depending on it. As it other people already flagged, probably also need to consider standards developed by other organisations that might depend on RFC6116 or it being actively maintained. The second path dependency is the administrative registry layer, because once you decided to add the zone, you need a mechanism to make further delegations. There is plenty of history written and even more in the memory of people involved (see archives of the RIPE ENUM WG). But the short form is that RIPE NCC has been "hired" by the IAB to perform that task of deciding on and maintaining those delegations. From a high-level yiou can say that what RIPE NCC does for e164.arpa is what PTI/IANA does for ICANN with regard to the root-zone. Where the IAB takes the role of ICANN as setting policy and RIPE NCC "operates" the zone under those instructions. That also leaves a pathway for IAB to select another "operator", although there is no written procedure. If the burden on RIPE NCC to operate the zone becomes too big, maybe this might be something to explore as an intermediate solution. Finally enter the role of ITU (and its member states), which is the third path depency. Which exists part in parallel to the previous step and part as a follow-up. E.164, the global telehpone numbering system, is not native to IETF. RFC 6116 refers to it, but IETF has no control over the standard, which is in the domain of ITU-T (SG2). Very similar as path-dependency one, ITU was also faced with the need to have an administrative function to delegate the numbers at the root of the E164 tree. Which everybody now recognises as the international calling codes (Netherlands = +31). This is where the dependency kicks in, because to make a delegation in e164.arpa, you need it aligned with the number registry that ITU operates for E.164. Or at miminum, to ensure that the authority that has been delegated the E.164 number, agrees or is aware of the e164.arpa delegation. The instructions from the IAB refered to earlier cater for this by explictly involving ITU TSB and ensuring the "rights holder" to particular number is consulted prior to delegation. This is now where it becomes interesting, because what if the ITU membership decides to reneg on the bargain and following the SG2 consultation, tell TSB to no longer be that conduit or vet any further delegation requests or changes. That leaves the RIPE NCC all of a sudden confronted without the checks they need and any further decision to delegate, redelegate or remove an entry on the e164.arpa will the sole responsibilty of RIPE NCC. Is that a risk worth taking? Or can the lack of TSB support be filled in another way, for instance by directly engaging with the national autorities who have a mandate on the E.164 number? To draw a further analogy, ITU in this role is what ISO is on country-code TLDs. Unlikely, but imagine the impact on the delegating ccTLDs if ISO-3166 is not longer available or maintained as a source and authoritative reference. And yes, here starts to exist another path dependency, because of course following the TSB decision, the RIPE NCC can also decide to cease operations for the maintaince of the e164.arpa zone and/or together with the IAB decided to remove it from .arpa. (NXDOMAIN). As mentioned before, not totally unheared of that delegations get removed, but in order to do so it needs a plan and it certainly can't be done instantly. ICANN community has spend countless hours looking at how to prevent any shocks and to ensure sufficient back-ups and resilience exists to provide a soft-landing in case a delegation needs to be removed. To the technical argument for the above, we need to delve into "what lurks beneath". The ENUM protocol stack is used widely in a variety of voice technologies (VoIP, mobile), the lack of use of the public DNS might be a bad indicator to actual use and depency on the ENUM protocol in a number of key technologies and critical infrastructures. It might give false guidance in the "is this safe to remove" if you only consider the number of public queries (which I think you indicated is not zero). This a) completes the circle back to the protocol itsel defining the need for delegation and b) be a clear case to further consider the impact any changes to the public DNS e164.arpa zone including its delegation on the operations of those systems that rely on the ENUM protocol, but do not rely on the public DNS resolving of the e164.arpa domain. In that study you might also want to consider the current "safety catch" of havign the domain delegated in any private queries escaping. Maybe some analogue to the RFC1918 space existing in ipv4.arpa can be found here. Circling back to the original question on provding some guidance to the need for e164.arpa as part of the internet's public core. I think we need to make a more careful cost/benefit analysis and especially consider the underlying and not yet fully qualified and quantified risks of discontnuing a service. In particular, I would appreciate feedback from the operational community, including the MNOs and MVNOs with regard to the risks and dependencies on the ENUM protocol and ENUM DNS zones. Met vriendelijke groet, Marco Hogewoning Senior policy advisor Ministry of Economic Affairs and Climate, the Netherlands Representative to ICANN GAC for the Netherlands ITU Focal Point for the Kingdom of the Netherlands Van: Hisham Ibrahim <HMI@ripe.net> Verzonden: 31 March, 2026 9:08 PM Aan: cooperation-wg@ripe.net Onderwerp: [cooperation-wg] Re: ENUM (e164.arpa): background, scope, and coordination steps Sommige mensen die dit bericht hebben ontvangen, ontvangen niet vaak e-mail van hmi@ripe.net<mailto:hmi@ripe.net>. Ontdek waarom dit belangrijk is<https://aka.ms/LearnAboutSenderIdentification> Dear colleagues, I would like to follow up on my previous message regarding ENUM (e164.arpa) and share a brief update on where things currently stand. As noted earlier, the RIPE NCC has been reviewing the operational status of the e164.arpa registry in light of its very limited usage, recent discussion in the RIPE Database Working Group, and the broader considerations surrounding the service operated by the RIPE NCC. Since my last email, the Internet Architecture Board (IAB) has discussed the matter at its last meeting. At this stage, the IAB has indicated that it would like to hear further feedback from the community before taking any further position. ITU-T has also initiated a consultation with Member States on the possible closure of the ENUM system under e164.arpa. As mentioned previously, this is an important part of understanding whether the service is still needed by the relevant delegating authorities and whether there is a continued operational justification for maintaining it. While the immediate trigger was a limited operational question, the topic also touches on broader considerations around community input, governance responsibilities, and coordination with relevant external bodies such as the IAB, IANA and ITU-T. For the RIPE NCC, the goal remains to approach this carefully and transparently: to understand whether there is still a real need for the service, to avoid unnecessary operational or compliance risk, and to ensure that any future steps are informed by both community feedback and the views of the appropriate stakeholders. I will present on this topic at RIPE 92, where I will provide more background, summarise the discussions to date, and invite further feedback from the RIPE community. In the meantime, I encourage anyone with views on this matter to share them on the RIPE NCC Services Working Group mailing list so that the discussion can continue openly and with the benefit of community input. Best regards, Hisham Ibrahim Chief Community Officer RIPE NCC On Tue, 17 Feb 2026 at 16:13, Hisham Ibrahim <HMI@ripe.net<mailto:HMI@ripe.net>> wrote: 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 Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is gezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

Dear colleagues, Thank you all for the thoughtful and detailed input shared so far. The points raised have been very helpful. I fully agree with the point that visible use of the public e164.arpa tree may not, on its own, give a complete picture of reliance on ENUM-related mechanisms more broadly. That is precisely why we have reached out to different communities and forums for input, in the hope of hearing more from those with direct operational experience. For that reason, I agree that it is premature to frame this discussion primarily in terms of closure of the service. I also understand why the language used in the ITU-T circular has caused concern, and this is something we have raised with them. Several of you have also rightly pointed out that this discussion brings together a number of related but distinct issues: the original operational question, the continued relevance of the ENUM protocol, the role of the public e164.arpa tree, and the question of any future closure. These are all issues we would like to clarify and document better with the community as part of this process. For the RIPE NCC, our aim is to approach this carefully and transparently, and not to rush towards a conclusion. We also need a firmer factual basis for understanding current use, possible dependencies, and the implications of any future change. With that fuller picture, more informed decisions can be made. I will continue to take these inputs into account as part of the broader community discussion, including in the session at RIPE 92. Further input, particularly from those with direct operational experience or knowledge of deployments and dependencies, would be very welcome. Many thanks again for taking the time to share your views. Best regards, Hisham Ibrahim Chief Community Officer RIPE NCC