Resumo

  • draft-ietf-opsawg-veloce-yang-00 exige referência a uma tag ou commit específico, e não ao HEAD mutável. A referência identifica o conteúdo, mas merge, issue fechada e CI verde não viram automaticamente consenso do grupo de trabalho.
  • Depois da publicação ainda é preciso preservar a decisão, rastrear o artefato entregue, conferir o module-set real via YANG Library, executar operações representativas e observar o serviço.

Uma equipe pode preservar cada linha de código e ainda perder a história que autorizou essas linhas.

Essa é a diferença entre um arquivo técnico e um registro institucional. Git é excelente para reproduzir o primeiro. O segundo depende de ligações entre discussões, decisões, pessoas responsáveis e objetos exatos.

O VELOCE entra nesse ponto. draft-ietf-opsawg-veloce-yang-00 propõe separar o módulo YANG do texto que o descreve. A prosa continuaria contendo explicação, referências, ações da IANA e considerações de segurança e operação. O módulo seria desenvolvido e mantido em um repositório de código, com diffs, issues, pull requests, validação e um ambiente contêiner reproduzível.

A proposta responde a uma incompatibilidade real. YANG é texto normativo, mas também fonte consumida por ferramentas. Um módulo importa dependências, seleciona features, declara revisions e pode usar arquivos SID. Revisar alterações pequenas como código pode ser mais preciso do que republicar um documento inteiro.

O material congelado é um Internet-Draft ativo do OPSAWG, de 25 de agosto de 2026. O cabeçalho diz Intended status: Experimental; o resumo do Datatracker não mostra status RFC pretendido. Só existe a revisão 00 no histórico. Não é RFC, processo aprovado em definitivo, experimento concluído ou implantação. As metas de dois anos para módulo novo e um ano para -bis incremental ainda precisam ser medidas.

A regra decisiva é não inserir o módulo no documento. A publicação deve apontar para uma versão marcada ou um hash de commit, nunca para o HEAD de uma branch. Assim, o módulo correspondente ao momento da publicação continua recuperável e verificável.

Uma tag resolve a pergunta “quais bytes?”. Ela é muito melhor que um endereço móvel. Pode alinhar autor, YANG Doctor, implementador e auditor no mesmo objeto.

Mas precisão de conteúdo não cria autoridade coletiva.

O RFC 8874 afirma que trabalho feito no GitHub não recebe status especial. O grupo de trabalho ainda pode aprovar, rejeitar ou modificar o resultado. O RFC também admite que a cópia no repositório não precisa refletir perfeitamente o consenso em cada instante, porque editores precisam administrar o documento.

Essa ressalva é fácil de esquecer diante de uma interface binária. PR aparece como Merged. Issue aparece como Closed. Check aparece como Passed. Um label pode dizer has-consensus. Todos registram ações reais; nenhum recebe mandato apenas pelo nome.

O consenso aproximado é avaliado por presidentes considerando diferentes espaços. O RFC 8874 exige confirmação das decisões na lista de discussão e alerta que participantes do repositório são um subconjunto selecionado. O RFC 2418 acrescenta que consenso não é votação por maioria e que decisões de reuniões devem voltar à lista.

Por isso, um merge pode estar correto e ainda não ser o recibo final de consenso. Editores têm discrição operacional; presidentes podem pedir que uma mudança espere pela avaliação coletiva. Assuntos de design que afetam implementação ou interoperabilidade exigem uma decisão rastreável.

O registro mínimo liga quatro coisas: a questão técnica, a resolução aceita, a determinação delimitada do presidente e o commit que implementa essa resolução. Sem essa ligação, decisão e código existem, mas a identidade entre ambos fica presumida.

CI oferece outro tipo de prova. RFC 8874 descreve a construção de documentos, validação de linguagens formais e testes. O VELOCE recomenda validar YANG e oferecer ambiente contêiner para execução local consistente.

O verde prova que verificações definidas passaram sobre entradas definidas. O alcance depende do commit, versão do validador, módulos importados, features, configuração, imagem e conjunto de testes. Não cobre testes ausentes e não demonstra comportamento idêntico entre produtos.

Automação forte exige um denominador forte. Cada resultado deve preservar ferramentas, versões, dependências, opções e exceções para que outra pessoa possa reproduzir o mesmo veredito.

Publicação resolve mais uma camada, não todas. Um RFC pode nomear exatamente o objeto revisado. Porém, não cria automaticamente o pacote do fabricante nem carrega o módulo no datastore.

Entre tag e equipamento estão custódia, build, assinatura, dependências, integração do fornecedor, imagem, distribuição e habilitação local. Um salto sem procedência pode quebrar a continuidade mesmo quando o commit original permanece intacto.

Também é necessário preservar material além dos objetos Git. RFC 8874 observa que issues, discussões de PR, reviews e wiki são mais vulneráveis a perda. Falha do serviço externo e comprometimento de credenciais privilegiadas importam. RFC 8875 complementa administração e backup.

Guardar o código e perder o motivo da aceitação mantém a forma, mas remove parte da legitimidade verificável.

O primeiro recibo de runtime vem do servidor. RFC 8525 permite que YANG Library informe module-sets de datastores, revisions, features e deviations. O operador pode comparar essa afirmação com o tag publicado e descobrir divergência.

Mesmo uma correspondência exata não prova o resultado. YANG Library é uma declaração do servidor sobre esquema. Operações NETCONF ou RESTCONF representativas, releitura de estado e observação independente do serviço continuam necessárias.

A lente de running-code preserva a ordem: tag no repositório, consenso na decisão, RFC na publicação, esquema e comportamento no sistema. Nenhuma camada precisa ser desprezada; nenhuma deve falar pela seguinte.

O princípio da especificação inicial mínima oferece o desenho construtivo. Padronizar as junções indispensáveis—objeto exato, validação reproduzível, decisão localizável e referência imutável—sem impor uma plataforma única. Ferramentas, distribuição e escolhas locais podem evoluir; adoção voluntária e interoperabilidade mostram o que funciona.

O alerta sobre representação também é prático. Uma issue movimentada não é toda a comunidade. Quem acompanha notificações é uma amostra. Reconectar decisões à lista e aos presidentes impede que familiaridade com a interface vire mandato invisível.

O VELOCE terá sucesso se acelerar manutenção sem comprimir cinco recibos em um. Quando alguém disser “está pronto”, é preciso perguntar: código, consenso, publicação, produto ou operação?

Fontes