Uma viagem de anos: o caminho do RFC 9660

12/12/2024

Por Hugo Salgado (edição LACNIC)

O processo de padronização no mundo da tecnologia, realizado por meio dos Grupos de Trabalho de Engenharia da Internet (IETF), é complexo, fascinante e muitas vezes leva anos. Esse foi o caso do RFC 9660, uma proposta que introduz uma nova opção no DNS para rastrear a origem dos dados.

A minha experiência nesse processo deixou muitos desafios e aprendizados, que acredito que poderiam ser úteis para quem pensa em se envolver em iniciativas semelhantes no IETF.

Os inícios

Há cinco anos apresentei pela primeira vez a ideia do que mais tarde se tornaria o RFC 9660. Na época, tinha um propósito claro: solucionar uma necessidade operacional no ecossistema DNS. Eu o compartilhei em meu nome, buscando feedback nos grupos do IETF. Um ano depois, a proposta tomou forma graças aos valiosos comentários da comunidade, permitindo que fosse formalmente apresentada e posteriormente adotada.

Ao longo do caminho, aprendi que esse tipo de projetos não envolve apenas habilidades técnicas (elaboração de projetos), mas também de relacionamentos humanos. O apoio e o entusiasmo de outros revelaram-se essenciais. Foi graças às redes de confiança e amizade construídas na comunidade do IETF que a minha proposta começou a ganhar força.

Os operadores e o IETF

Desde meus anos de participação no IETF, entendi que os operadores desempenham um papel fundamental na adoção de ideias. No caso do RFC 9660, sua utilidade prática ficou evidente para aqueles que operam a infraestrutura DNS. Isto, juntamente com o apoio de pessoas chave dentro da organização, abriu o caminho para que a proposta fosse seriamente considerada.

Mauricio Vergara, ex-colega e colaborador, foi fundamental no processo. Embora eu não tenha participado das reuniões do IETF quando lancei a ideia, ele apoiou a proposta nas listas de discussão e reuniões presenciais, agindo como uma espécie de “lobista técnico”. A interação pessoal nos corredores e as reuniões informais que Mauricio realizou nos encontros presenciais do IETF foram decisivas para convencer as pessoas do valor da proposta. No IETF, uma boa ideia nem sempre funciona por si só; precisa de uma estratégia e comunicação eficaz.

Finalmente, quase no final do processo, Duane Wessels, engenheiro sênior de pesquisa da Verisign, juntou-se à equipe de autores, quem contribuiu de forma muito valiosa para a edição, principalmente na língua inglesa, e para a coesão final. Além disso, sua experiência como autor de diversos RFC foi crucial para avançar nas etapas finais de revisão e edição junto à IANA, organização responsável por realizar a publicação final do documento.

A evolução do documento

No IETF, os grupos de trabalho são o núcleo onde as ideias evoluem. Os chairs, ou líderes de grupo, têm um papel fundamental na orientação do debate e na garantia de que as propostas avancem de forma construtiva. No meu caso foi um processo longo, com muitas revisões, ajustes e negociações.

É importante compreender que o IETF não é um ambiente exclusivamente acadêmico e técnico. Embora algumas críticas apontem que as normas nem sempre são tecnicamente “puras”, este é um espaço em que convergem as forças acadêmicas, industriais, comerciais e jurídicas. Alcançar um equilíbrio entre esses interesses é fundamental. Às vezes, comprometer a pureza técnica para chegar a um consenso é um preço necessário para o progresso.

Os desafios

A primeira coisa que vem à mente é entusiasmar a comunidade. Tentar convencer os outros de que uma ideia merece atenção não é fácil. No início, pode ser assustador enfrentar centenas de opiniões diferentes.

Então, tem que buscar coesão. O processo envolve a harmonização de ideias diversas e muitas vezes opostas. Isso requer habilidades técnicas e de negociação.

Às vezes parecia que o documento estava pronto, mas sempre surgiam novas revisões e melhorias. Esse processo demorou mais de três anos, mas cada interação trouxe algo valioso.

Um aprendizado fundamental foi reconhecer a importância das equipes de trabalho, como a da IANA (Internet Assigned Numbers Authority). Seu profissionalismo e precisão elevaram a qualidade do documento além do que eu poderia ter alcançado sozinho.

Para participar

Para quem queira se embarcar em um processo de padronização, deixo lições aprendidas no caso do RFC 9660.

• Humildade: É crucial abrir mão do controle e aceitar as opiniões dos outros. Este processo requer colaboração constante.
• Paciência e perseverança: As discussões podem durar anos. É preciso estar disposto a ouvir, negociar e, fundamentalmente, adaptar-se às propostas de mudança.
• Procurar aliados: Cercar-se de pessoas com conexões na comunidade global pode fazer toda a diferença. Não é preciso ser conhecido de antemão, mas é preciso ser proativo.
• Consenso: A perfeição técnica nem sempre é alcançável, mas chegar a um consenso é o que finalmente permite que uma ideia prospere.

Hoje, eu vejo a RFC 9660 como uma conquista compartilhada, resultado da colaboração entre diferentes pessoas e perspectivas. O documento final fica muito mais sólido graças ao feedback e ao trabalho coletivo. Além de ser um padrão técnico, esse processo é uma oportunidade de aprender, crescer e se posicionar dentro de uma comunidade global. O caminho é longo, pode ser percorrido, vale a pena.