Un viaje de años: el camino del RFC 9660

12/12/2024

Por Hugo Salgado (edición LACNIC)

El proceso de estandarización en el mundo de la tecnología, que se realiza a través de los Grupos de Trabajo de Ingeniería de Internet (IETF) es complejo, fascinante y, a menudo, un viaje de años. Este fue el caso del RFC 9660, una propuesta que introduce una nueva opción dentro del DNS para rastrear el origen de los datos. 

Mi experiencia en este proceso dejó muchos desafíos y aprendizajes, que considero podrían ser útiles para quienes piensen en involucrarse en iniciativas similares en la IETF.

La germinación 

Hace cinco años presenté por primera vez la idea que luego se convertiría en el RFC 9660. En ese momento, tenía un propósito claro: resolver una necesidad operativa en el ecosistema DNS. Lo compartí bajo mi nombre, buscando retroalimentación en los grupos de IETF. Un año después, la propuesta tomó forma gracias a comentarios valiosos de la comunidad, lo que permitió que fuera presentada formalmente y adoptada más tarde.

En el camino, aprendí que este tipo de proyectos no se tratan solo de habilidades técnicas (elaboración del proyecto), sino también de relaciones humanas. El apoyo y el entusiasmo de otros resultaron esenciales. Fue gracias a las redes de confianza y amistad construidas en la comunidad de la IETF que mi propuesta empezó a ganar tracción.

Los operadores y la IETF

Desde mis años de participación en la IETF, entendí que los operadores tienen un papel clave en la adopción de ideas. En el caso del RFC 9660, su utilidad práctica fue evidente para quienes operan infraestructura DNS. Esto, junto con el respaldo de personas claves dentro de la organización, allanó el camino para que la propuesta fuera considerada seriamente.

Mauricio Vergara, un ex-colega y colaborador, resultó crucial en el proceso. Aunque al lanzar la idea no asistí a las reuniones de la IETF, él apoyó la propuesta en las listas de correo y reuniones presenciales, actuando como una especie de “lobista técnico”. La interacción personal en los pasillos y las reuniones informales que realizó Mauricio en las reuniones presenciales de la IETF resultaron decisivas para convencer a la gente del valor de la propuesta. En la IETF, una buena idea no siempre se defiende por sí sola; necesita una estrategia y comunicación efectiva.

Finalmente, casi al terminar el proceso, se incorporó al equipo de autores Duane Wessels, ingeniero senior de investigación de Verisign, quien dió un tremendo aporte de edición principalmente del idioma inglés, y de cohesión final. Además su experiencia como autor de multitud de RFCs fue crucial para avanzar en las últimas etapas de revisión y edición con IANA, la organización encargada de realizar la publicación final del documento.

La evolución del documento

En la IETF, los working groups son el núcleo donde las ideas evolucionan. Los chairs, o líderes de grupo, tienen un rol esencial para guiar la dirección del debate y asegurar que las propuestas avancen de manera constructiva. En mi caso, fue un proceso largo y de muchas revisiones, ajustes y negociaciones. Es importante entender que la IETF no es un entorno exclusivamente académico y técnico. Aunque algunas críticas apuntan a que los estándares no siempre son técnicamente “puros”, este es un espacio donde convergen fuerzas académicas, industriales, comerciales y legales. Lograr un balance entre estos intereses es clave. A veces, ceder en la pureza técnica para alcanzar consenso es un precio necesario para avanzar.

Los desafíos

Lo primero que se me viene a la mente es entusiasmar a la comunidad. Tratar de convencer a otros de que una idea merece atención no resulta sencillo. Al principio, puede ser desalentador enfrentarse a cientos de opiniones diferentes.

Luego, hay que buscar cohesión. El proceso implica armonizar ideas diversas y a menudo opuestas. Esto requiere habilidades tanto técnicas como de negociación.

En ocasiones, sentía que el documento ya estaba listo, pero siempre surgían nuevas revisiones y mejoras. Este proceso llevó más de tres años, pero cada interacción aportó algo valioso.

Un aprendizaje clave fue reconocer la importancia de los equipos de trabajo, como el de la IANA (Internet Assigned Numbers Authority). Su profesionalismo y precisión elevaron la calidad del documento más allá de lo que podría haber logrado por mi cuenta.

A sumarse

Para quienes deseen embarcarse en un proceso de estandarización, les dejo lecciones aprendidas en el caso del RFC 9660.

• Humildad: Es crucial soltar el control y aceptar las opiniones de otros. Este proceso requiere colaboración constante.
• Paciencia y perseverancia: Las discusiones pueden durar años. Hay que estar dispuesto a escuchar, negociar y, es esencial, adaptarse a las propuestas de cambios.
• Buscar aliados: Rodearse de personas con conexiones en la comunidad global puede marcar la diferencia. No es necesario ser conocido previamente, pero sí ser proactivo.
• Consenso: La perfección técnica no siempre es alcanzable, pero lograr consenso es lo que finalmente permite que una idea prospere.

Hoy, miro el RFC 9660 como un logro compartido, resultado de la colaboración entre distintas personas y perspectivas. El documento final es mucho más sólido gracias al feedback y al trabajo colectivo. Además de ser un estándar técnico, este proceso es una oportunidad para aprender, crecer y posicionarse dentro de una comunidad global. El camino es largo,se puede recorrer, vale la pena.

Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.