Resumo

  • A revisão 00-01 da proposta de carta do IETF para Agent Communication Protocols foi publicada em 14 de setembro. Ela continua na revisão interna do Steering Group/IAB e está na pauta da teleconferência do IESG de 17 de setembro; o Agentproto ainda não é um grupo de trabalho constituído.
  • O novo texto prevê coordenação com trabalhos relevantes de padronização e código aberto fora do IETF para compreender a prática implantada e evitar divergência desnecessária.
  • A frase imediatamente anterior preserva nos grupos pertinentes do IETF as decisões sobre mudanças nos protocolos deles. Evidência externa e autoridade interna seguem caminhos diferentes.
  • Daniel Kade propõe um recibo de coordenação com duas vias. A proposta não é uma exigência da carta nem uma posição do IESG.

O texto abre uma passagem, não entrega a chave

A revisão 00-01 descreve um possível programa de trabalho: protocolo básico de gestão de diálogos entre usuários, agentes e ferramentas, arquitetura de referência e material informativo sobre casos de uso e requisitos.

Perto do fim da lista de entregas, há uma regra para dependências internas. Se o Agentproto precisar mudar ou estender um protocolo especificado por outro grupo do IETF, a questão será levada ao grupo pertinente para que ele decida a melhor maneira de tratá-la. A proximidade técnica não transfere a custódia do protocolo.

Logo depois vem a frase acrescentada em 00-01. O futuro grupo deverá coordenar com esforços externos relevantes de padronização e código aberto, conhecer aquilo que já funciona em sistemas implantados e evitar uma separação técnica sem necessidade.

Essa escuta é indispensável. Um projeto em produção pode revelar uma hipótese inviável, um teste conjunto pode mostrar que duas opções não interoperam e uma especificação externa pode oferecer um componente já amadurecido. Ignorar tais sinais produziria um padrão isolado do ambiente que pretende servir.

Mas receber informação não desloca o local da decisão. Um projeto externo não ganha o poder de declarar consenso do IETF por ter participado. O IETF também não passa a controlar a licença, o repositório ou a agenda do projeto externo por decidir algo em seu próprio documento. A cooperação preserva dois mandatos.

Ainda há uma decisão pela frente

O Datatracker mantém a proposta em “Start Chartering/Rechartering (Internal Steering Group/IAB Review)” e informa que ela está na pauta da teleconferência do IESG de 17 de setembro. Isso comprova a etapa de revisão, não o seu desfecho.

Comparada à 00-00, a versão nova faz quatro alterações visíveis. Retira intelligent da definição de agente; inclui usuários na passagem sobre proteção de dados; corrige uma concordância; e acrescenta a coordenação externa.

O histórico e o registro da cédula mostram o que ocorreu antes. Em 10 de setembro, um comentário pergunta se o grupo também deveria colaborar com entidades não pertencentes ao IETF. Outro pergunta sobre dados trocados com usuários e sobre marcos que acompanhem o avanço posterior das entregas. Em 13 de setembro foi incluído um marco para submeter o protocolo ao IESG como Proposed Standard em março de 2028; 00-01 apareceu no dia seguinte.

As semelhanças textuais e a sequência são fatos. A causa específica não é. O material público examinado não traz uma tabela ligando cada comentário a uma edição, à pessoa que a aceitou e à justificativa. A notícia não deve preencher essa lacuna com certeza inventada.

Também não cabe reaproveitar a revisão para condensar as votações da BoF no IETF 126. Naquela ocasião, escopo, entregas e formação do grupo foram perguntas diferentes. A proposta atual pertence a uma etapa posterior e não converte retrospectivamente as contagens em um único mandato.

A lição limitada dos mecanismos de liaison

O RFC 4052 atribui ao IAB a gestão das relações formais de liaison. Essas relações devem permanecer tão informais quanto for prático e ajudar a reduzir trabalho duplicado sem impedir cada organização de cumprir o próprio mandato.

O RFC 4691 trata o responsável por liaison como elo bidirecional. Ele recolhe informação para que o IETF decida melhor, mas só pode comunicar uma posição institucional depois de entender o consenso pertinente. Opinião pessoal não se torna posição do IETF pelo cargo de quem a expressa.

O RFC 4053 organiza o recebimento, o encaminhamento e a resposta a declarações de liaison. Um pedido que busque influenciar a direção de um grupo merece consideração, não aceitação automática. O prazo pode aumentar a urgência da resposta; não aumenta a autoridade substantiva do pedido.

Nada disso obriga o Agentproto a converter toda conversa com mantenedores em documento formal. Questões públicas, relatórios de implementação, eventos de interoperabilidade e contribuições individuais podem ser os canais adequados. O ponto comum é manter visível quem falou, em nome de quem, sobre qual versão e com qual tipo de evidência.

Um recibo para cada lado da fronteira

Na via de entrada, o registro teria o assunto, o artefato externo, a versão ou commit exato, o responsável, a data, o canal, a alegação e a situação da verificação. Também classificaria a origem: liaison formal, posição de organização, contribuição individual, observação de implementação ou relato ainda não confirmado.

Na via decisória, apareceria a entrega do Agentproto afetada, o responsável no IETF, a discussão pública, o estado e a justificativa. Um vocabulário curto — observado, considerado, adotado, adaptado, rejeitado, adiado, ação pedida ao responsável externo — evita reduzir tudo a aprovação ou silêncio.

Quando outro grupo do IETF controla o protocolo, seu próprio registro de decisão deve ser ligado, não substituído. Quando a alteração depende de um projeto externo, o recibo registra um pedido e uma resposta autônoma, não uma ordem. Uma mensagem enviada em nome do IETF deve indicar qual consenso autoriza essa representação.

Não é preciso publicar conversas privadas ou detalhes de segurança. É preciso impedir que um participante conhecido substitua uma instituição, que consulta substitua consentimento e que popularidade de uma implementação substitua decisão de padrão. O recibo é uma proposta analítica de Daniel Kade, não texto escondido na carta.

Fontes

  1. Proposta de carta do Agentproto 00-01 com marcos
  2. Proposta de carta do Agentproto 00-00 com marcos
  3. Histórico da carta do Agentproto
  4. Cédula da carta do Agentproto
  5. Registro da proposta de carta
  6. RFC 4052 — gestão de relações de liaison pelo IAB
  7. RFC 4053 — tratamento de declarações de liaison
  8. RFC 4691 — orientação para representantes de liaison do IETF
  9. RFC 2418 — diretrizes e procedimentos de grupos de trabalho do IETF
  10. RFC 5434 — considerações para uma BoF bem-sucedida
  11. Lu Heng — The Multi-Stakeholder Mirage
  12. Lu Heng — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption