The recently-ended Plenipotentiary Conference of the International Telecommunications Union (ITU) in Dubai was anything but a technical meeting, yet with the ITU’s mandate focused around telecommunications and ICTs, of course technological issues and challenges underpin many of the discussions. As the meeting resolves and instructs the different ITU Bureaux, especially the Telecommunications Standardisation Bureau (TSB), some of these instructions might impact technical decisions down the line. In this article, I’ll look at some of the conference’s output and try and assess the technology behind it. This is PP-18 from the perspective of a retired network engineer.
The Final Acts of the ITU Plenipotentiary 2018 are available in multiple languages. The texts mentioned in this article are contained in that document.
As we posted earlier here on RIPE Labs, there are a number of Resolutions that focus on Internet technology and the governance of resources such as names and addresses. Many regional groups and member states came to Dubai proposing changes to these resolutions, and while many constitute relatively small changes, some turned out to be highly controversial.
Of course, as with any ICT or telecommunications conference, security is on everybody’s mind and that topic echoes through many of the proposals. In light of the broader debate around the role of the Union on these and other matters, both the proposed changes and discussions remain very high-level, but sometimes there is an underlying issue that does have the potential to negatively impact security.
Take, for instance, the proposal by a group of African and Arab States on the topic of internationalised and multilingual domain names (IDNs), stating that: “… continuing progress in the usage of internationalized domain names added security challenges”. From an initial point of view this might not be totally wrong, but it also seems very counterproductive, especially since earlier editions of this conference, as well as others such as the World Telecommunications and Development Conference (WTDC), have recognised the importance of increasing the use of IDNs and promoting multilingualism in Internet applications.
Talking over a break with some of the proponents engaged in the discussion, we quickly agreed that the actual problem was not the increased use of IDNs, but rather the risk and challenges with string similarity. Although such similarities can introduce security risks, the most important part is that there is a level of awareness with regard to these issues. And not only to raise awareness on the part of end users, but to make sure that these issues are considered when developing policy and making decisions. Not just in the international domain of course, but also importantly in the national domain - for instance, in ccTLD policies that are decided by local stakeholders or governments.
Recognising the issue and considering the objectives of the Resolution to promote and raise awareness, the text was modified and now reads: “while recognizing that there are difficulties in some scripts to implement appropriate and language-specific requirements, including variants” and “the need to address challenges associated with the use of visually similar characters from different languages or character sets”.
Opinions vary on this matter, but I am not convinced there is much to do for ITU, other than transmitting these concerns to the appropriate organisations that are involved in the decision making and which might be able to mitigate some of these issues. While perhaps not a strictly technical matter, as one of the stakeholders, the technical community should take it into account and try to help mitigate some of these risks.
Another big-ticket item for the RIPE NCC and the technical community was the existing Resolution 180 on IPv6 “Facilitating the transition from IPv4 to IPv6”, where many changes were proposed, including changing the title. Again, the text of this resolution is very high-level and while it tries to define the role of the ITU in IP addressing, its primary goal is to encourage the use of IPv6 by Member States and other stakeholders.
From a technical perspective, the focus on a transition was deemed slightly inappropriate and outdated. Responding to this and recognising that IPv6 and IPv4 will need to co-exist for years, possibly decades, it was proposed to replace the instances of “transition” with “adoption” or “deployment”.
At the same time, it became clear that many states still struggle with the fact that their network operators and industries face shortages of IPv4 addresses. Certainly, a full deployment of IPv6 would remove these challenges, but we all know that this is easier said than done. This resulted in the title being changed to a rather lengthy “Promoting the deployment and adoption of IPv6 to facilitate the transition from IPv4 to IPv6”.
Similar language changes were made throughout the text, making it explicit that you can deploy IPv6 while continuing to use IPv4. It also makes note of the fact that “not enough network operators and end users are actually using IPv6”. By itself certainly not a new observation, but as network operators we must keep in mind that, when telling somebody to deploy IPv6, we are the ones responsible for making it work.
The Resolution is a compromise, for sure, but also a stark reminder of the promises once made: that IPv6 would serve as a replacement for IPv4. A goal that might not be in reached as easily as we once all hoped for, but still something we should try for.
Finally, I think that we in the technical community should also note the issues raised by Member States, often developing nations, regarding the availability of bandwidth. This often concerns delivery of broadband (last mile) in rural and underdeveloped areas; but also, from a national perspective, the access to and availability of international fiber connections. This is an issue that is still especially prominent in landlocked countries.
Resolutions cover the role of IXPs in this as well, recognising the work that the Internet Society and the IXP Federation have been doing in this space. And while often not strictly a technical issue, we can probably all contribute our fair share to these efforts to build those IXPs and community networks.
Showing that it works is probably the best way to build understanding and acceptance of these tried and tested methods to increase speed, lower latency, and (most importantly) drive down the costs. Convincing states to lower regulatory barriers, making the Internet more accessible and affordable - not something that is easily done, or done by the technical community alone, but something that requires a fair amount of the knowledge and experience that we can bring to the table.
When going through the Final Acts, hundreds of pages, there aren’t many paragraphs that directly address technical issues. I hope the examples above show how some of the technical issues influence the debates as this level. Or the other way around - how some of these high-level debates are important for the technical work that we do on the ground.
We all have a role to play, whether it be at an ITU meeting like this, an Internet Governance Forum or further down in ITU Study Groups, or a working group of one of the Internet institutions, including RIPE. The key is to listen and understand each other. Certainly not every problem can be solved at the technical level, but sometimes we can.