The process of standardizing technology through the Internet Engineering Task Forces (IETF) is a complex, fascinating journey that often spans many years. This was the case of RFC 9660, a proposal that introduces a new option within the DNS to trace the origin of data.
My experience through this process brought both challenges and learnings, which I believe might be useful for anyone thinking of getting involved in similar initiatives within the IETF.
An idea germinates
I first presented the idea that would later become RFC 9660 five years ago. At that time, its goal was clear: to address a specific operational need within the DNS ecosystem. I shared it under my name, inviting comments from IETF groups. A year later, the proposal began to take shape thanks to valuable feedback from the community, which allowed it to be formally presented and later adopted.
Throughout the process, I learned that this type of project requires more than merely technical skills (drafting the project) — they are also about human relationships. The support and enthusiasm of others proved essential. It was thanks to the trust and friendships I built within the IETF community that my proposal started to gain traction.
Operators and the IETF
(Free access, no subscription required)
My years of involvement in the IETF have allowed me to understand that operators play a key role in the adoption of ideas. In the case of RFC 9660, its practical value was clear to those operating DNS infrastructure. Along with the support of key individuals within the organization, this paved the way for the proposal to be taken seriously.
Mauricio Vergara, a former colleague and collaborator, proved to be crucial in the process. Although I was not present at the IETF meetings when the idea was launched, Mauricio supported the proposal on mailing lists and in-person meetings, effectively acting as a sort of ‘technical lobbyist.’ The personal interactions that he engaged in during informal discussions and hallway conversations at IETF meetings were decisive in convincing others of the proposal’s value. At the IETF, a good idea does not always advocate for itself; it needs a strategy and effective communication.
Finally, near the end of the process, Duane Wessels, a senior research engineer at Verisign, joined the team of authors and contributed significant editorial input, particularly regarding the English language and the overall cohesion of the document. His experience as the author of multiple RFCs was also pivotal in advancing through the final stages of revision and editing with the IANA, the organization responsible for the final publication of the document.
My years of involvement in the IETF have allowed me to understand that operators play a key role in the adoption of ideas. In the case of RFC 9660, its practical value was clear to those operating DNS infrastructure. Along with the support of key individuals within the organization, this paved the way for the proposal to be taken seriously.
Mauricio Vergara, a former colleague and collaborator, proved to be crucial in the process. Although I was not present at the IETF meetings when the idea was launched, Mauricio supported the proposal on mailing lists and in-person meetings, effectively acting as a sort of ‘technical lobbyist.’ The personal interactions that he engaged in during informal discussions and hallway conversations at IETF meetings were decisive in convincing others of the proposal’s value. At the IETF, a good idea does not always advocate for itself; it needs a strategy and effective communication.
Finally, near the end of the process, Duane Wessels, a senior research engineer at Verisign, joined the team of authors and contributed significant editorial input, particularly regarding the English language and the overall cohesion of the document. His experience as the author of multiple RFCs was also pivotal in advancing through the final stages of revision and editing with the IANA, the organization responsible for the final publication of the document.
Evolution of the document
Working groups are the core of the IETF. They are the place where ideas evolve. Working group chairs play an essential role in steering the debate and ensuring that proposals advance constructively. In my case, it was a lengthy process with many revisions, adjustments, and negotiations.
It is important to understand that the IETF is not an exclusively academic and technical environment. While some critics point out that standards are not always technically ‘pure’, this is a space where academic, industrial, commercial, and legal forces converge. Achieving a balance among these interests is key. Sometimes, compromising on technical purity to achieve consensus is the price that must be paid to move forward.
The first thought that comes to mind is the need to engage the community. Trying to convince others that an idea deserves attention isn’t easy. At first, facing hundreds of different opinions can seem discouraging.
Likewise, you need to search for cohesion. The process involves harmonizing various and often conflicting ideas. This requires both technical and negotiation skills.
At times, I would feel the document was ready, but new revisions and improvements kept coming up. This process took more than three years, but each interaction contributed something valuable.
A key lesson learned was recognizing the importance of the work teams, such as the one at the IANA (Internet Assigned Numbers Authority). Their professionalism and precision elevated the quality of the document beyond what I could have achieved on my own.
You can do it too!
For anyone who wishes to embark on a standardization process, I will conclude with some of the lessons I learned from RFC 9660.
Humility: It is essential to relinquish control and accept the opinions of others. This process requires constant collaboration.
Patience and perseverance: Discussions can last years. It’s important to be willing to listen, negotiate, and, importantly, adapt to proposed changes.
Seeking allies: Surrounding yourself with individuals who have connections in the global community can make a difference. You don’t need to be well-known beforehand; what matters is being proactive.
Consensus: Technical perfection is not always achievable, yet reaching a consensus is what ultimately allows an idea to prosper.
Today, I view RFC 9660 as a shared accomplishment, the result of collaboration among various individuals and perspectives. The final document is much more robust thanks to feedback and collective work. In addition to a technical standard, this process is an opportunity to learn, grow, and position yourself within a global community. The road is long but worth traveling.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.
