Resumo

  • A Resolução 2026-14 reafirmou, sem revisões e com efeito imediato, a orientação da Internet Society para sua ligação com o NomCom da IETF. A aprovação ocorreu por consentimento escrito unânime em 10 de julho de 2026.
  • A orientação ainda invoca a RFC 3777 para o processo, a confidencialidade e as regras da função. A RFC 7437 tornou a RFC 3777 obsoleta e depois foi, ela própria, substituída pela RFC 8713, o BCP 10 vigente.
  • A pessoa deve transmitir fatos e posições que considere representativos do consenso do Conselho, sem deixar sua preferência pessoal perceptível, e também agir no melhor interesse da IETF. Em caso de conflito, a primeira obrigação prevalece.
  • A RFC 8713 conserva as duas responsabilidades, mas determina que tarefas adicionais atribuídas por uma organização não podem contrariar suas disposições. A ligação não vota na escolha de candidatos.
  • Não foi encontrada evidência pública de conflito concreto, intervenção indevida, exposição de opinião pessoal ou efeito sobre qualquer candidatura. A lacuna é a ausência de uma interpretação atual e verificável.
  • A Internet Society deveria publicar um quadro de correspondência com a RFC 8713 e um registro mínimo de decisões sobre regras, sem revelar deliberações nem dados de candidatos.

O Conselho escolheu manter, não apenas esquecer

A Resolução 2026-14 reuniu quatro políticas de governança. O Comitê de Governança sugeriu alterações em três. Para a orientação do trustee que serve como ligação com o NomCom, apresentou o texto vigente e não propôs revisão. O Conselho o reafirmou com efeito imediato. O consentimento escrito foi unânime e ficou aprovado em 10 de julho.

Essa sequência impede que o documento seja tratado como uma página antiga sem dono. Ele nasceu em 2012, mas voltou formalmente à mesa do órgão competente em 2026. A decisão foi mantê-lo. A própria página pública agora exibe a data da reafirmação.

Uma citação antiga não invalida sozinha a política. Também não é razoável presumir que reafirmar atualize silenciosamente cada referência. A pergunta correta é qual regra externa o Conselho incorporou ao renovar a orientação.

A RFC 3777 cumpre três funções no texto. Ela define o processo que a ligação deve acompanhar, fornece as regras de confidencialidade para os relatórios periódicos ao Conselho e é apontada novamente como fonte das regras de ligação.

O histórico oficial não deixa dúvida sobre sucessão. O RFC Editor marca a RFC 3777, de 2004, como obsoleta e indica a RFC 7437 como sucessora. A página da RFC 7437 registra que ela substituiu a 3777 e que foi substituída pela RFC 8713. Publicada em fevereiro de 2020, a RFC 8713 é hoje o BCP 10 aplicável ao NomCom e aos comitês de recall, com atualização posterior.

Os documentos antigos continuam acessíveis; portanto, não se trata de link quebrado. Trata-se de saber se a referência congela o texto de 2004, acompanha automaticamente o BCP sucessor ou preserva apenas certas obrigações. A prática pode adotar a resposta mais sensata. Uma política recém-reafirmada deve torná-la explícita.

O papel não inclui voto sobre nomes

Como o NomCom seleciona candidatos para funções centrais da IETF, a presença de uma ligação pode ser confundida com poder de escolha. A RFC 8713 desfaz essa confusão. O Conselho da Internet Society pode indicar uma ligação a seu critério, mas presidente, ligações e assessores não votam na seleção de candidatos. Só participam de outras votações quando o RFC permitir.

A orientação da Internet Society também separa canais. Quem exerce a função pode enviar opinião pessoal pelos meios abertos a qualquer participante da IETF. No canal institucional, porém, sua posição pessoal sobre uma candidatura ou sobre o processo não deve ser reconhecível. A fala deve se limitar a fatos e posições que a pessoa julga refletir o consenso do Conselho.

Há, portanto, um mandante identificável e um mandato estreito. A ligação representa o Conselho, não todos os associados da Internet Society, os usuários da Internet ou uma comunidade sem contorno. A distinção de Lu Heng entre parte interessada e principal ajuda a manter o limite: participar não cria autorização; um Conselho pode autorizar alguém a transmitir a sua própria posição.

Essa autorização não produz voto. O ponto de vista do Conselho não se transforma em consenso do NomCom só porque foi comunicado dentro do comitê.

A norma estabelece qual dever vem primeiro

Ao mesmo tempo, a orientação manda agir no melhor interesse da IETF. Em seguida, reconhece que suas três diretrizes podem entrar em conflito. Nessa hipótese, a pessoa usa seu melhor julgamento, mas a obrigação de representar o consenso do Conselho deve superar a obrigação relativa ao interesse da IETF.

A prioridade está no documento; não é uma acusação construída por terceiros. Sua existência também não prova que alguém a tenha usado. As fontes públicas não mostram choque concreto, preferência individual disfarçada, interferência em candidatura ou mudança de resultado.

A questão editorial é outra: uma norma vigente prevê a divergência entre a lealdade representativa a uma instituição e a responsabilidade perante o processo da IETF, mas não publica como essa divergência é compatibilizada com o BCP atual.

A RFC 8713 mantém a dualidade e acrescenta um limite

A seção 4.7 da RFC 8713 atribui às ligações a responsabilidade de ajudar a garantir que o NomCom e sua presidência cumpram as tarefas no melhor interesse da comunidade IETF. Também espera que representem a visão de suas organizações, ofereçam informações úteis, expliquem a operação dos órgãos e levem perguntas e respostas de um lado para o outro.

Na maior parte do tempo, as funções se reforçam. Informações do Conselho sobre governança, confirmação ou estrutura institucional podem melhorar o trabalho do NomCom. Representar a organização que fez a indicação não é, por definição, interferência.

O RFC determina ainda que a ligação acompanhe a operação e a execução do processo, comunique imediatamente preocupações à presidência e use o procedimento de controvérsias se o problema não puder ser resolvido. O caminho é processual; ele não vira uma cédula sobre candidatos.

O limite mais forte aparece nas responsabilidades adicionais. A organização ou o NomCom pode exigir outras tarefas, desde que elas não conflitem com nenhuma disposição da RFC 8713.

Isso não basta para declarar incompatível a prioridade da Internet Society. A própria RFC prevê representação organizacional. “Melhor interesse” exige avaliação. É possível que o Conselho entenda a prioridade como uma regra de fidelidade da fala, enquanto a RFC continua limitando qualquer conduta dentro do comitê.

O problema é que essa conciliação não foi publicada. O texto reafirmado não diz se a prioridade governa apenas o conteúdo da mensagem, se alcança uma intervenção processual, como a cláusula de não conflito restringe a orientação ou para onde a dúvida deve ser levada. Uma norma que antecipa conflito deveria indicar o mecanismo atual de resolução.

Atualizar exige uma correspondência, não busca e substituição

Trocar 3777 por 8713 eliminaria o sinal mais óbvio de desatualização, mas não faria uma migração confiável. A RFC 8713 reorganizou regras, refletiu mudanças como IETF Trust e IETF LLC e recebeu atualização posterior. Os deveres de 2004 precisam ser ligados aos dispositivos atuais, não apenas renumerados.

A confidencialidade mostra a diferença. O Conselho pode receber informação de que o calendário está regular, uma dúvida processual foi encaminhada ou um procedimento de controvérsia foi acionado. Nada disso exige revelar nome, avaliação, comparação, depoimento ou deliberação sobre um candidato.

O quadro deve reunir também as funções atuais: representar a organização, fornecer informação, explicar o órgão, monitorar o processo, alertar a presidência, escalar quando necessário e não votar na seleção. Conselho, ligação e NomCom passariam a usar o mesmo mapa.

A regra de prioridade merece uma linha própria. O Conselho pode mantê-la e justificar sua compatibilidade; limitá-la à transmissão fiel; ou exigir encaminhamento quando os deveres não puderem coexistir. O histórico deve preservar tanto o texto de 2012 quanto a reafirmação de 2026.

A transparência correta é sobre a regra

Abrir a sala de candidatos seria um erro. O NomCom depende de avaliações francas e de proteção contra campanhas públicas. Prestação de contas não significa divulgar o material que a confidencialidade foi criada para proteger.

O objeto público pode ser pequeno. Uma parte estática apresenta cláusula de 2012, seção atual da RFC 8713, dever mantido, diferença relevante, responsável pela interpretação e data. Uma parte eventual registra apenas classe da questão, papéis que a encaminharam, regras aplicadas, data e desfecho — resolvida, retirada ou escalada.

Nenhum registro deve conter identidade de candidato, opinião do Conselho sobre uma pessoa, preferência do titular ou debate interno. O público não refaria a seleção. Poderia verificar que a instrução institucional foi comparada ao BCP vigente e passou pelo canal apropriado.

Governança leve significa publicar o estado comum indispensável e nada além dele. Mandato, aconselhamento, fiscalização do processo e seleção precisam continuar em campos diferentes.

Um principal definido não autoriza representação ilimitada

Este caso é mais disciplinado que a retórica de “comunidade” sem cadeia de autorização. A Internet Society identifica o Conselho que a ligação representa. Estar no comitê não cria o mandato.

O limite, contudo, deve permanecer visível. Consenso do Conselho autoriza a comunicação de uma visão do Conselho. Não vira consenso do NomCom, não cria voto e não faz do Conselho o principal da comunidade IETF. O dever de agir no melhor interesse da IETF protege essa separação.

Em 10 de julho, o Conselho confirmou que deseja manter a interface. Agora falta um ato menor: conectar o texto preservado ao RFC que de fato rege o comitê hoje.

Fontes

  1. Internet Society — Orientação para a ligação do Conselho com o Comitê de Nomeações da IETF
  2. Internet Society — Resolução 2026-14 por consentimento escrito
  3. RFC Editor — Informações sobre a RFC 3777
  4. RFC Editor — Informações sobre a RFC 7437
  5. RFC Editor — RFC 8713, BCP 10 atual
  6. Lu Heng — The Multi-Stakeholder Mirage