Even while attending remotely, it was obvious that the ccNSO meeting in Sevilla was a great edition. The meeting offered a rich agenda with relevant updates from around the world, it had excellent interactive sessions on the two key areas that are of the highest relevance for any ccTLD manager and it covered our industry’s hot topics such as resilience, verification and DNS abuse.
At the end of this blogpost I’ll add some pointers to some of the best sessions - available in the ICANN archives - but I want to put the spotlight on two topics that every ccTLD manager should keep an eye on.
Last year, the ccNSO delivered a crucial document: the Policy Gap Analysis. That analysis looked into the abundance of documents and policies that govern ccTLDs to ask the essential questions: Where are the gaps? What is needed for a predictable and transparent governance of ccTLDs?
On the list that the Policy Gap Analysis group drafted, there are two topics that were considered urgent and - potentially - relatively easy to fix: improving the accuracy of the IANA records and the potential role of PTI in disaster recovery.
Accuracy of IANA Public Records (Discovery Phase)
The discussion on accuracy of the IANA public records is reminiscent of another ongoing debate: accuracy of registrant details. But this is of course bringing that discussion from the second level to the top level.
There is evidence of low data accuracy in the IANA ccTLD records, including mistakes, unrecorded changes, and outdated information that is maintained with tacit consent from the local stakeholders.
However, there are no practical remediation steps or formal guidance from the ccNSO on how to handle these inaccuracies. IANA has to rely only on informal outreach when inaccuracies are identified, basically asking nicely to fix it.
The study group is evaluating the purpose of this accuracy rule and its use cases. It covers questions on the validity of legal entities, personal and contact details listed in the IANA root database, and their correct linkage to the designated country or territory. (and RFC1591 requirement). This last topic is what makes this a highly sensitive and crucial discussion in the ccNSO.
The working group will draft a short paper outlining potential graduated compliance and enforcement options. CENTR will encourage all members to contribute in the upcoming consultation round.
IANA’s Role in ccTLD Disaster Recovery (Development Phase)
Utilizing the "Double Diamond" methodology (Discover, Define, Develop, Deliver), this study group is currently in the development phase, modeling how IANA can support registries during severe disruptions such as power outages, natural disasters, or armed conflicts. “what could IANA do here - and what preparation would have helped to prepare for this scenario?”
The research asks what concrete actions IANA could take during a crisis and what prior preparations would facilitate those interventions.
To ensure comprehensive scenario building, these disaster scenarios are tested against a matrix of five defining ccTLD characteristics:
- Regulatory Framework: Ranging from absent to strict compliance requirements (e.g., NIS 2).
- Governance Model: Government versus private oversight.
- DNS Service: In-house versus outsourced infrastructure.
- Registration Service: In-house versus outsourced operations.
- Scale: Micro to very large registry operations.
One of the questions debated was if there needed to be additional dimensions taken into account such as the level of maturity of existing disaster recovery plans.
The other, which touched upon the most structural problem, is how any disaster recovery scenario interplays with the ccTLD manager transfer procedure. How to avoid that any action in a recovery scenario is seen as an unauthorised transfer?
The initial findings are clear: firstly, disaster recovery and business continuity planning is the sole responsibility of the ccTLD manager. However, there are scenarios when PTI could potentially play a role. This needs to be prepared and structured.
Secondly, the diversity of the landscape means that there is no single approach that would fit all ccTLDs.
The group is still welcoming additional contributors.
In other news:
- The amount of work that is required of the ccNSO is baffling to the level that a screenshot tells more than a few paragraphs in a blogpost:
2. CNNIC gave a fascinating presentation, sharing their views on and efforts in capacity building in the age of AI. The training curriculum they offer to ccTLDs is impressive. Capacity building is their strategic priority. And they shared a wisdom we all know but too often fail to live by: standards participation is power. (Pages 33-42)
3. In the same session, Ukraine shared their experience from a lasting war. They shared their learnings: resilience by design. In 5 design principles, they touched upon the essential role of a ccTLD: protect the digital identity, the trust, the availability and the continuity of your zone. They advise design with failure in mind; avoid single points of failure; build trust in the infrastructure, include people and partners and embed resilience in governance. (Pages 43-51)
4. Two interesting sessions on resilience covered mainly European aspects of regulation and impact on open source software. Excellent updates from the ICANN EU Policy Team and a fascinating talk by NLNetLabs on the impact of NIS2 on the open source community. (Full deck)
5. This meeting also celebrated the decades-long dedication of Bart Boswinkel to the ccNSO community. On behalf of the CENTR community: Thank You Bart!
This covered the most relevant sessions from the ccNSO in Sevilla. I am looking forward to the next meeting and encourage everyone to contribute to at least the two discussions highlighted in the blogpost. Though I am sure that any additional contributions to one of the 43 workpackages currently managed by the ccNSO would be greatly appreciated too.
