Dear Judith,_______________________________________________
thanks for pointing us to this excellent and very helpful paper from OCTO. This "taking stock" was very interesting as I was not aware at all about the extensive collaboration on so many IETF working groups and I am thrilled to see such collaboration happening at all levels.
Part 1 of this paper also has a link to https://pti.icann.org/agreements , a web page on the special PTI Web site which shows the extent to which the relationship between ICANN, PTI, the IANA functions and the IETF are codified as well as monitored, followed and analysed thanks to a set of Agreements that are regularly reviewed, amended and updated. You can see all of the original documents which the IANA Stewardship Group, some drafted with the help of law firm Sidley Austin and will notice that there are a number of MoUs that make sure that the matter of PTI and PTI operations is not just dropped, since it is a very important function indeed.
Part 2 of this paper explains the various "protocol development in IETF working groups in 2025 that may be important to those interested in the ICANN ecosystem."
Both parts, in my opinion, fall somehow short of achieving their goals as both are missing out on some important information, which I would like to raise here:
In Part 1 - the OCTO paper confirms the point that I have been making for nearly two years: whilst the relationship between ICANN, PTI and "its clients" is adequately monitored, tracked, reviewed and enforced through a multitude of Agreements shown in the above page, there is absolutely no mention of the IANA IPR and the IANA IPR Agreements dated 30 September 2016.
- There is no tracking of it.
- There is no formal governance process or oversight in ICANN for monitoring, identifying and addressing issues relating to these IPRs
- There is no community consultation
- There no service level expectations
- There is no enforcement
It is a complete barren landscape - and this is one of the main reasons why the transfer of IANA IPR from the IETF Trust to the IETF IPMC and other important related issues have taken so much time: a complete lack of process in ICANN leading to confusion, in addition to potential breaches of the IANA IPR Agremeents dated 30 September 2016.
In addition to this, there appears to have been continued opposition from ICANN Legal to seeking independent legal advice in relation to the IANA IPR Agreements dated 30 September 2016, including but not restricted to in respect of the Issues raised in relation to and arising from the IANA IPR transfer, the IANA IPR processes, the IANA IPR Agreements and any new IANA IPR Agreements, as well as the suitability or unsuitability of the use of Novation Agreements given all of the other issues cited.
My submission recommends independent investigation, engagement of specialist Counsel (Sidley or Californian Counsel) to prepare an independent legal opinion, full community transparency, and the adoption of interim protective measures pending the negotiation of replacement instruments that genuinely address the governance failures identified.
Is ICANN ready to remedy this failure?
In Part 2 - the OCTO paper focusses solely on protocol development in IETF working groups. This somehow provides an incomplete picture of the extent by which ICANN has links with the IETF, although I do not know whether there is a specific reason for focussing solely on protocol development.
First, there is the excellent work of the IETF Liaison who does more than just follow these working groups. The IETF is regularly informed of ICANN Activity through the IETF Liaison and their report to the IETF Administration LLC Board and at IETF meetings which goes way further than just focussing on matters directly concerning the IETF.
Second, there are other IETF groups that have done work on topics of interest both to ICANN and the IETF - for example the IDNA and IDNAbis working groups that laid the groundwork for IDNs.
RFCs:
https://datatracker.ietf.org/doc/rfc4690/ in Sept 2006
https://datatracker.ietf.org/doc/rfc5891/ in Aug 2010
ICANN has since done a significant amount of work in relation to IDNs, especially when it comes to the operation of IDNs, including Label Generation Rules for various scripts. Is there a link back to the IETF for these? Should there be? Should the ICANN work be codified/recorded as IETF RFCs?
Or perhaps those in charge at ICANN see the IETF as only focussing on Protocols and implementation is not something that should be addressed at the IETF? I wonder if we could ask these questions to OCTO?
Kindest regards,
Olivier
On 21/04/2026 20:26, Judith Hellerstein via ALAC wrote:
HI All,
Thanks to Olivier and Greg for all their hard work on the IETF MOU that they put in. I want to call everyone's attention to the new publication that David Huberman put out on ICANN's relationship with the IETF. I think it was a good paper. https://www.icann.org/en/system/files/files/octo-043-16apr26-en.pdf
He provides a good overview of why ICANN works hard to keep up their close partnership with the IETF. In the paper he describes a relationship that is not only formal and practical, but also reciprocal. As we all know, the Internet’s unique identifier system is defined by IETF standards, and IETF participants bring technical expertise into ICANN's multistakeholder governance processes.
Since 2025, IETF working groups advanced efforts that have direct implications for how the Domain Name System (DNS) operates, from how DNS delegations work, to how domain names are provisioned, to how the cryptographic algorithms that secure the DNS are managed. This report also focuses on and offers a practical overview of what changed, what's coming, and why it matters to registry operator, registrar, DNS operator, or anyone who depends on the protocols that make the domain name ecosystem function, All in all I thought it was a good paper. The technical foundations on which the security, stability, and resilience of the Internet’s unique identifier system depend on are constantly evolving, and it is important to keep abreast of all these issues and why all constituencies within ICANN should stay abreast and work closely with the IETF as At Large has done in the past
Best,
Judith
-- _________________________________________________________________________ Judith Hellerstein, Founder & CEO Hellerstein & Associates 3001 Veazey Terrace NW, Washington DC 20008 Phone: (202) 362-5139 Skype ID: judithhellerstein Mobile/Whats app: +1202-333-6517 E-mail: Judith@jhellerstein.com Website: www.jhellerstein.com Linked In: www.linkedin.com/in/jhellerstein/ Opening Telecom & Technology Opportunities Worldwide
_______________________________________________ ALAC mailing list -- alac@icann.org To unsubscribe send an email to alac-leave@icann.org At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC) _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
ALAC mailing list -- alac@icann.org
To unsubscribe send an email to alac-leave@icann.org
At-Large Online: http://www.atlarge.icann.org
ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.