Resumo

  • draft-ietf-netmod-yang-next-agreement-00 separa as questões entre inclusão na próxima versão, possível consideração, adiamento para além da próxima versão e fechamento já ocorrido ou proposto.
  • Essa organização é um recibo de classificação preso à revisão 00. Uma coluna, um closed no GitHub ou o estado WG Document não demonstra inclusão final, significado normativo, compatibilidade, implementação, ferramentas ou uso em produção.

Uma equipe de engenharia recebe uma planilha com quatro cores. Verde significa “incluir”, amarelo “considerar”, cinza “depois” e vermelho “fechar”. Em pouco tempo, o verde vira compromisso de produto e o vermelho vira prova de que o problema acabou. Foi essa promoção silenciosa que precisa ser evitada ao ler YANG Next Agreement.

O documento não entrega uma nova linguagem YANG. Ele pega o inventário de netmod-wg/yang-next e cria uma superfície para o grupo discutir o tamanho e a direção de uma futura revisão. A contribuição da revisão 00 é decidir quais perguntas devem avançar antes que a disponibilidade de autores e implementadores escolha, por acaso, o desenho do núcleo.

O estado mostra o fórum, não o resultado

O Datatracker lista a revisão 00 como Internet-Draft ativo do WG NETMOD, atualizado em 23 de junho de 2026. O WG state é WG Document; o IESG state é I-D Exists; o campo estruturado Intended RFC status está vazio. Separadamente, o cabeçalho do texto informa Intended status: Informational e expiração em 25 de dezembro de 2026.

Essas superfícies não devem ser fundidas em uma aprovação inexistente. WG Document indica um veículo reconhecido para trabalho do grupo. I-D Exists registra que o draft existe. O cabeçalho registra uma intenção textual. Nenhum desses fatos aprova as quatro categorias ou cada item nelas contido.

O próprio draft limita sua missão: discutir e tentar obter acordo sobre o escopo e a forma da próxima versão de YANG. Ele declara que não há objetivo de publicar este documento como RFC e admite que um dashboard do GitHub pode acompanhar as questões. Trata-se de uma agenda auditável, não do padrão final.

A força das quatro vias é permitir dizer “não agora”

Segundo o texto, o rastreador tinha cerca de 125 issues abertas e 35 fechadas. Elas variavam em escala, complexidade, importância e impacto de compatibilidade. Se o conteúdo da próxima versão dependesse apenas de quem quisesse trabalhar em cada item, o resultado poderia crescer sem uma decisão coletiva sobre o problema central.

A primeira via reúne o que os autores acreditam dever entrar. A segunda guarda o que pode ser considerado se houver interesse. A terceira mantém propostas fora da próxima versão, sem impedir retorno futuro. A quarta reúne itens fechados ou a fechar, inclusive mudanças consideradas grandes, complexas ou prejudiciais.

O ganho é de contenção. Uma especificação inicial menor permite experimentar, atribuir resultados e reverter decisões. Adiar uma função não a declara inútil; preserva a escolha para um contexto com evidência melhor.

Ainda assim, o grupo mais forte não é norma. A seção 2 fala no que “os autores acreditam” e reconhece que algumas clarificações podem, após revisão, não exigir mudança. O Appendix Issue 152 oferece uma classificação diferente. O mapa é um objeto de disputa legítima.

Fechar pode significar coisas incompatíveis

O texto reúne sob fechamento: issues já fechadas no GitHub, issues abertas que o autor propõe fechar, duplicatas, mal-entendidos sobre YANG, mudanças vistas como danosas e questões que pertencem a protocolos. Prioridade baixa, complexidade ou workaround também aparecem como motivos.

Um duplicate não extingue o assunto; ele pode ter sido agregado em outro identificador. Mover para o protocolo muda o foro. Propor fechamento não é uma conclusão dos chairs. E uma ideia fechada sob a necessidade de compatibilidade com YANG 1.1 pode reaparecer quando se considera YANG 2.0. O draft reconhece explicitamente esse retorno.

Por isso, evidência de fechamento exige o ID, a data, a conversa, a posição na revisão exata, o motivo e qualquer avaliação posterior de consenso. Guardar apenas closed conserva o estado da fila e perde o julgamento técnico.

O consenso precisa de objeções identificáveis

As atas do IETF 120 registram interesse em YANG Next, mas falta de clareza sobre YANG 1.1, 1.2 ou 2.0. O chair pediu motivações e objetivos e disse que Git não substituiria o processo de consenso. No IETF 121, a pontuação havia sido feita por uma equipe auto-selecionada e aberta. Participantes pediram que o resultado voltasse ao WG. A ideia de um draft resumido era obter buy-in sobre a direção, não declarar que ele já existia.

RFC 7282 descreve rough consensus como localizar, entender e tratar objeções fundamentadas. Assim, cada item exige texto específico, discussão na lista ou reunião, objeções, respostas e uma avaliação delimitada dos chairs. Uma etiqueta administrativa não carrega esse conjunto.

Uma escada que não aceita atalhos

O primeiro degrau é o inventário: identidade da issue, autor, exemplo, estado e tempo. O segundo é classificação: posição na revisão 00, justificativa e alternativas. O terceiro é consenso: registros de lista e reunião, objeções e avaliação. O quarto é normativo: texto exato de uma especificação posterior.

O quinto degrau é compatibilidade, cobrindo gramática, semântica, módulos, extensões, deviations, clientes e servidores. O sexto é implementação, com ferramentas independentes, testes negativos e interoperabilidade. O sétimo é implantação: migração gradual, observabilidade, rollback e resultado.

A revisão 00 entrega principalmente o segundo degrau. Isso já é útil. Não autoriza saltar os cinco seguintes.

YANG 2.0 trata da linguagem; module versioning, da identidade e das ramificações; schema comparison, da classificação de diferenças; module filename, da descoberta; YANG Packages, da composição. O acordo de quatro vias não define esses mecanismos, e eles não transformam a classificação em consenso.

Fornecedores devem ler “incluir” como início de estudo. Mantenedores devem criar branches e corpus de teste. Operadores devem monitorar, não migrar. O princípio de especificação inicial mínima de Heng Lu ajuda a manter a fronteira: decisões pequenas e visíveis primeiro, escolhas futuras localizadas e adoção voluntária depois de resultados reproduzíveis. A camada simbólica organiza atenção; a realidade começa quando ferramentas independentes concordam e a operação pode observar e reverter.

Fontes

Documento e histórico: YANG Next Agreement revisão 00; Datatracker; histórico.

Processo e contexto: atas NETMOD do IETF 120; atas NETMOD do IETF 121; RFC 7282; RFC 7950; draft YANG 2.0 revisão 00.

Interpretação: Minimum Initial Specification; On Reality Layers; Running Code Primary.