Resumo

  • O DAWN continuava Proposed em 27 de agosto de 2026. A carta 00-00 estava na análise interna IESG/IAB, e a pergunta da cédula se limitava à prontidão para revisão externa.
  • O NETCONF já era Active, mas 20-02 era uma proposta de recharter. O próprio Datatracker dizia que a carta aprovada vigente continuava sendo a versão 20.
  • Segundo o RFC 2418, uma carta aprovada vincula o IETF e o grupo a um conjunto delimitado de tarefas. Redação, análise interna, revisão ampla, decisão do IESG e anúncio da Secretaria são atos distintos.
  • Aprovar uma carta não adota automaticamente um Internet-Draft, não comprova consenso técnico, não aprova um RFC e não transfere aos operadores uma ordem de implantação.

Duas perguntas escondidas na palavra “atual”

Qual é a versão atual? Para um editor de texto, é a revisão mais recente. Para quem precisa saber o que um grupo pode fazer hoje, é o texto cuja aprovação está em vigor. As respostas podem apontar para documentos diferentes.

Na formação inicial, o projeto pode estar completo e mesmo assim não existir carta vigente. O valor correto é vazio até a decisão constitutiva. No recharter, acontece o contrário: há uma carta anterior válida, e ela continua limitando o trabalho enquanto o substituto é debatido.

Um único ponteiro para latest inventaria a autoridade do DAWN e apagaria antes da hora a autoridade vigente do NETCONF. O desenho seguro mantém proposta mais recente e carta atualmente aprovada como relações independentes. O nulo de um grupo ainda não formado é uma conclusão factual, não uma falha de preenchimento.

A confusão muda a alocação de recursos. O assunto aparentemente autorizado ganha tempo de reunião, editores, protótipos e referências comerciais. Grupos vizinhos podem recuar, e outras organizações podem esperar que o IETF resolva um tema que ainda nem foi incorporado ao mandato. Uma correção posterior do rótulo não recolhe código ou compromissos já feitos.

O DAWN tinha material para análise, não autorização final

A página do DAWN o identificava como “Proposed WG Discovery of Agents With Names”. O estado do grupo era Proposed; a carta, charter-ietf-dawn-00-00; e a etapa, Start Chartering/Rechartering (Internal Steering Group/IAB Review).

O texto descrevia descoberta de agentes e recursos de IA, ambientes locais, dentro de uma organização e entre organizações, mecanismos possíveis, presidência proposta, entregas, prazos e exclusões. Essa especificidade permitia avaliar a proposta. Não a tornava autoexecutável.

A cédula da carta perguntava: “Is this charter ready for external review?”. Éric Vyncke registrou Yes; Mohamed Boucadair, Block; os demais membros listados apareciam como No Record. O resumo dizia haver posições suficientes para passar pela etapa quando o Block fosse resolvido.

Boucadair manifestava apoio ao trabalho, mas pedia maior precisão sobre o gatilho da descoberta, os modelos operacionais, a diferença entre cenários locais e interorganizacionais, as barreiras de confiança e a viabilidade de um único protocolo. Era uma objeção de escopo a ser tratada. Não equivalia a rejeição final do tema nem a um veto pessoal permanente.

O Yes também deve permanecer ligado à pergunta. “Pronto para revisão externa” não quer dizer “grupo criado”. O histórico registrava a versão 00-00, a abertura da cédula e a entrada em revisão interna em 24 de agosto, seguida do Block no dia 25. Não registrava aprovação constitutiva.

O BoF do IETF 126 já havia organizado terminologia, casos de uso, requisitos e uma longa conversa sobre carta. Essa atividade é prova de interesse, conhecimento e controvérsia. Não autoriza os participantes a substituir a decisão que o processo atribui ao IESG.

O estado pode mudar depois da data observada. O DAWN pode avançar, ser revisto, voltar para ajustes ou não ser criado. Uma decisão futura vale do ponto de transição identificável em diante; não transforma retroativamente a preparação em trabalho de um WG já autorizado.

O NETCONF continuava operando sob a versão 20

O ponto de partida do NETCONF era diferente. A página do grupo mostrava estado Active e um campo estabelecido em torno de NETCONF, RESTCONF, YANG, telemetria e gestão de rede.

A página da carta exibia charter-ietf-netconf-20-02, atualizada em 12 de agosto, na revisão interna de um recharter. Ao mesmo tempo, avisava que o conteúdo era uma proposta e que a carta aprovada vigente era a versão 20.

Três registros coexistiam: o grupo ativo, a versão 20 que lhe dava o escopo atual e 20-02, que pedia uma alteração futura. Examinar a terceira não suspendia a segunda.

A cédula do NETCONF também perguntava pela prontidão para revisão externa. Christopher Inacio mantinha um Block porque não havia milestones. Mahesh Jethanandani registrou Yes, e vários membros, No Objection. O resumo dizia que a fase poderia passar quando o Block fosse resolvido. O objeto daquela cédula não era a entrada em vigor.

Se forem pedidos ajustes, uma versão posterior pode virar a candidata final. Se a proposta for retirada, a versão 20 permanece. Se houver aprovação, a decisão precisa identificar o texto aprovado, a carta substituída e o momento de vigência. Nenhum desses caminhos exige imaginar que 20-02 passou a reger o grupo no dia em que foi publicada.

Antecipar a mudança ainda inverte o ônus. Antes da aprovação, quem propõe ampliar o escopo precisa justificar por que o trabalho pertence ao NETCONF. Depois de agendas, chamadas de adoção e implementações baseadas no escopo informal, quem revisa é pressionado a explicar por que estaria “retirando” uma competência que nunca foi concedida.

Quem participa não desaparece; quem decide não se dissolve

O marco publicado seguia sendo o RFC 2418, parte do BCP 25. A futura presidência e o Area Director negociam normalmente a carta. O IAB presta aconselhamento, e o IESG dá a aprovação final. Depois da análise interna, o projeto é exposto à comunidade mais ampla. O IESG pode aprovar, pedir mudanças ou recusar; em seguida, a Secretaria registra e anuncia o grupo aprovado.

O RFC chama a carta de contrato entre o IETF e o WG para um conjunto de tarefas. É um contrato institucional, não comercial, e não representa uma delegação política de todas as pessoas afetadas. Ele delimita onde atenção coletiva e procedimento aberto podem ser usados para produzir resultados técnicos.

O limite tem utilidade prática. A presidência pode adiar intervenções fora de escopo sem fechar o grupo. WGs próximos podem reconhecer sobreposição. Outros organismos podem decidir quando estabelecer liaison. Colaboradores podem avaliar onde investir. Mudanças de premissa podem levar a recharter, troca de presidência ou encerramento.

O RFC 3710 distribui responsabilidades. A iniciativa pode vir da comunidade ou do Area Director. A futura presidência constrói um plano. Participantes demonstram interesse, capacidade e objeções. O IAB avalia impactos arquiteturais. A revisão ampla revela efeitos de privacidade, segurança e operação. O Area Director coordena; o IESG assume a decisão institucional.

Separar participação de autorização não torna a consulta decorativa. Uma boa objeção pode reduzir escopo, acrescentar uma ligação externa, dividir uma entrega ou demonstrar falta de maturidade. A participação é fonte de evidência e contestação; não precisa fingir que cada presença representa todos os afetados.

Quando um trabalho importante está fora da carta, há rotas: reformar a carta, usar outro WG, trabalhar fora de um grupo ou criar um novo. Preservar a fronteira não exige paralisia.

A carta permite investigar; não aprova a conclusão

Depois da aprovação, a carta cria um espaço de perguntas. Um Internet-Draft individual pode ser considerado nesse espaço. A adoção pelo WG escolhe uma base de trabalho; não endossa cada frase. Rough consensus, Working Group Last Call, avaliação do IESG e publicação como RFC ocorrem em etapas seguintes. O stream e a categoria do RFC ainda determinam seu significado formal.

Implantação fica além dessa cadeia. O RFC 3935 descreve um IETF que produz documentos técnicos relevantes, mas não controla a Internet nem pode obrigar seu uso. Um operador precisa escolher versão, responsável, testes, abrangência, critérios de rollback e sinais do ambiente em produção.

O draft-ietf-procon-2418bis-04 era uma proposta útil para observar esse limite. Em 27 de agosto, permanecia WG Document com estado IESG I-D Exists. Seu cabeçalho dizia que substituiria RFC 2418 e RFC 3934 se fosse aprovado. O condicional não pode ser descartado.

O texto do draft trata a carta como compromisso de escopo e afirma que adotar um Internet-Draft não significa consenso sobre o conteúdo. A carta do PROCON autoriza consolidar uma cadeia nomeada de RFCs de processo e exige novo recharter para outras mudanças substantivas. O mandato de redigir o sucessor não aprova antecipadamente o sucessor.

Um recibo para a passagem de autoridade

O registro deve começar pelo tipo de ação: INITIAL_CHARTER ou RECHARTER. Deve preservar nome e sigla do grupo, estado, identificador da proposta, revisão e hash do texto. Outra referência guarda a carta aprovada vigente e seu hash, ou um nulo explícito antes da criação.

O bloco de escopo registra tarefas adicionadas, removidas e mantidas, exclusões, entregas, grupos vizinhos e coordenação externa. O bloco de revisão registra Area Director, presidências, data de abertura, pergunta exata da cédula, posições, Blocks, condições de resolução, aconselhamento do IAB, anúncio externo e destino de comentários materiais.

O bloco decisório precisa do resultado do IESG, razão pública, data, anúncio da Secretaria, vigência e versão substituída. Aprovação, devolução, continuidade da carta antiga, retirada, recusa e dissolução são resultados normais e completos.

Duas negações acompanham a carta aprovada: ela não prova consenso sobre uma contribuição específica e não ordena implantação. Esses limites não esvaziam o mandato; evitam que ele seja reutilizado como autoridade que nunca recebeu.

Fontes

  1. IETF Datatracker: grupos em chartering e rechartering
  2. IETF Datatracker: grupo DAWN proposto
  3. IETF Datatracker: cédula da carta do DAWN
  4. IETF Datatracker: histórico da carta do DAWN
  5. IETF Datatracker: agenda do BoF DAWN no IETF 126
  6. IETF Datatracker: proposta de recharter do NETCONF
  7. IETF Datatracker: carta aprovada do NETCONF, versão 20
  8. IETF Datatracker: WG NETCONF ativo
  9. IETF Datatracker: cédula da carta do NETCONF
  10. RFC 2418: diretrizes e procedimentos dos WGs do IETF
  11. RFC 3710: carta do IESG
  12. RFC 6292: requisitos para ferramentas de carta
  13. IETF Datatracker: estado de draft-ietf-procon-2418bis
  14. IETF Datatracker: texto de draft-ietf-procon-2418bis
  15. IETF Datatracker: carta do WG PROCON
  16. RFC 3935: missão do IETF
  17. RFC 9281: entidades do processo de padronização do IETF