Resumo

  • OPSAWG adotou o VELOCE e publicou a revisão 00 como documento do Working Group em 25 de agosto de 2026. Esse estado não é RFC, BCP nem política final da IETF.
  • O resumo atribuído da reunião do mesmo dia afirma que o ponteiro da IANA foi confirmado, mas o texto publicado ainda declara não haver ações IANA. A pull request 49, que propõe estados, hashes e rotas de aprovação, continuava aberta e sem merge no corte da pesquisa.
  • Uma conclusão em reunião de projeto não equivale à confirmação de consenso do grupo na lista de discussão. Um merge no GitHub não equivale à aprovação do grupo, de um Area Director ou do IESG. Uma linha da IANA pode registrar uma versão aprovada sem decidir sua substância normativa.
  • A revisão já evita apontar para uma cabeça móvel de branch: a referência deve ser uma versão marcada. Falta mostrar, em uma única trilha, como a versão posterior é aprovada, obtida e verificada pela IANA, e contra qual versão se testa conformidade.

A adoção abriu o documento; não fechou todas as decisões

O resultado da adoção registra que as presidências de OPSAWG encontraram apoio suficiente e pediram que o texto individual fosse reenviado como draft-ietf-opsawg-veloce-yang-00, sem outras alterações. O Datatracker apresenta a revisão 00 como documento do grupo desde 25 de agosto. Isso dá ao grupo a responsabilidade pelo texto. Não torna cada mecanismo de manutenção futura automaticamente consensual ou aprovado.

A proposta separa o módulo YANG do RFC que o apresenta. O RFC apontaria para uma versão específica, marcada no repositório. Uma branch principal pode mudar depois da publicação; um commit ou tag identificável permite recuperar os mesmos bytes a que a publicação se referiu. O projeto também considera atualizar um módulo adotado no repositório da IETF e alterar no RFC apenas a referência para essa nova versão. Há uma razão prática para experimentar isso: uma correção pequena e bem examinada não precisa, por definição, arrastar uma substituição integral do RFC.

Mas o antigo recipiente fazia um trabalho invisível. Quando o módulo estava no RFC, o leitor via juntos o texto normativo, a versão publicada, a autoridade de publicação e a referência estável. Ao separar o arquivo, é preciso registrar esses elementos de novo: quem escolheu a versão, qual é a identidade imutável, onde ela sobrevive, por qual ato ela se tornou atual e qual versão um implementador deve usar para afirmar conformidade.

Os autores reconheceram essas questões publicamente antes da IETF 126. A discussão sobre ponteiros pergunta se o RFC deve apontar a uma tag Git, a uma entrada IANA ou a outro alvo; pergunta o que um ponteiro para a versão mais recente deveria significar; e pergunta como preservar uma conformidade testável após atualização. As atas de OPSAWG na IETF 126 registram alternativas envolvendo GitHub, um ambiente controlado pela IETF, publicação IANA, arquivo e recuperação. O horário acabou e a discussão seguiu na lista. Trata-se de incerteza de desenho, não de prova de mau procedimento.

O resumo da reunião de 25 de agosto acrescenta que o repositório GitHub seria mantido, que colaboradores poderiam abrir issues e pull requests, que opiniões de encontros quinzenais seriam resumidas na lista e que objeções levariam a debate adicional antes do merge. Diz também que a indireção pela IANA foi confirmada. A fonte, porém, deve conservar sua escala. É um relato atribuído de reunião de projeto, não uma chamada de consenso formal do Working Group ou uma decisão do IESG. RFC 8874 afirma que trabalho feito no GitHub não recebe status especial e que decisões de consenso do grupo devem ser confirmadas na lista de e-mail. Uma reunião pode preparar uma escolha; não pode absorver essa confirmação.

No texto da revisão 00, a situação é mais estreita: não há ações IANA. RFC 8126 trata uma seção explícita de nenhuma ação como determinação consciente de que a IANA não precisa agir naquele documento. A frase não impede que uma revisão posterior faça um pedido válido. Ela impede que se trate uma direção debatida como se já fosse uma instrução de registro.

O desenho de PR 49 ainda não é um registro em vigor

A pull request 49 permanecia aberta e não fundida. Ela propõe um registro de referências a arquivos e módulos YANG com estados permanente e proposto, URL precisa, SHA-256, contatos de controle e caminhos de aprovação por IESG ou por outra autoridade definida. Esses campos ajudam a desagregar funções: o hash fixa os bytes; o estado separa candidato de referência atual; o contato localiza a custódia; a aprovação identifica quem pode decidir mérito.

Não são, contudo, campos já aceitos pela IANA para esse fim. O registro corrente de YANG Module Names opera sob RFC Required e lista nome, arquivo, namespace, prefixo, referência e notas. Ele não exibe hoje os campos VELOCE propostos para hash, estado de aprovação, contato controlador ou recibo decisório. Portanto, o registro congelado não permite afirmar que a IANA criou a nova tabela, aceitou sua regra ou buscou um módulo VELOCE.

Cada ato tem autor próprio. O autor propõe. Revisores e mantenedores lidam com o repositório. O Working Group forma consenso. Um Area Director ou o IESG pode ter o papel de aprovação que o texto determinar. A IANA faz a inscrição delimitada. A linha do registro preserva a identidade do resultado. Uma tag, um merge, uma decisão de consenso e uma inscrição podem estar ligados, mas não são a mesma prova.

Essa separação não é burocracia contra velocidade. A revisão 00 já manda usar uma versão marcada, e preserva os procedimentos de consenso. A PR 49 tenta dar hashes e caminhos de aprovação à IANA, não liberdade ilimitada. Uma primeira revisão de WG pode razoavelmente não ter decidido todas as perguntas que uma experiência revelou. O erro seria transformar a lacuna temporária em autoridade implícita, ou tratá-la como se provasse que a experiência é ilegítima.

Um recibo entre a decisão e o endereço

Para cada atualização posterior, VELOCE poderia manter um recibo público e curto que conecte:

  1. o efeito normativo alegado e o Working Group responsável;
  2. a chamada de consenso na lista, suas datas, objeções relevantes e disposição das presidências;
  3. a revisão exata que pede o registro e a autoridade que aprova;
  4. URL do repositório, commit imutável, tag e SHA-256;
  5. autor, revisores, pessoa que fez merge e autoridade aprovadora, sem colapsar os papéis;
  6. solicitante, hora, URL obtida, bytes obtidos e verificação pela IANA;
  7. linhas anterior e nova, data de vigência e elo de substituição;
  8. versão da publicação, última versão aprovada e versão usada no teste de conformidade;
  9. compatibilidade, testes, espelhos, cópias de segurança, recuperação, retirada e reversão; e
  10. evidência de implantação ou adoção operacional, guardada separadamente.

O recibo não cria veto e não chama de consenso uma reunião produtiva. Ele aponta para a confirmação pública posterior. Tampouco desloca o juízo técnico para a IANA: a autoridade indicada decide que um candidato se torna atual; a IANA verifica e registra o artefato aprovado conforme uma política estabelecida. A Nota 63 de Heng Lu é uma lente de desenho institucional, não evidência sobre VELOCE. Registro e proveniência tornam uma decisão auditável sem transferir ao registrador o poder de tomar a decisão.

Também é preciso proteger a palavra conformidade. RFC 9907 continua sendo o BCP publicado: declarações normativas YANG são tratadas como prosa normativa de RFC e módulos novos ou atualizados são registrados em IETF XML e YANG Module Names. VELOCE pode propor outra forma de manutenção, mas ainda não substituiu esse ponto de partida. A versão citada em um RFC, a última aprovada, a linha IANA atual e a versão testada podem coincidir, mas o sistema deve dizer quando não coincidem.

Sources

  1. OPSAWG charter
  2. VELOCE Datatracker record
  3. IETF 126 OPSAWG minutes
  4. Pull request 49
  5. Heng Lu Note 63
  6. IANA YANG parameters
  7. OPSAWG VELOCE adoption result
  8. VELOCE pointer discussion
  9. 25 August VELOCE call summary
  10. draft-ietf-opsawg-veloce-yang-00
  11. RFC 8126
  12. RFC 8874
  13. RFC 8875
  14. RFC 9907