Resumo

  • draft-ietf-netmod-yang-anydata-validation-00 propôs usar a identidade codificada do nó para localizar, na YANG Library da RFC 8525, o schema aplicável aos filhos de anydata.
  • anydata-complete aplicaria todas as regras do schema correspondente; anydata-candidate não executaria constraint checks. Nenhum dos resultados prova sozinho origem, autorização, estado operacional, encaminhamento ou resultado de negócio.

O contador recebeu um sinal verde e entrou no cálculo. Quando a fatura foi contestada, a equipe ainda tinha o payload, mas não a revisão do módulo, as features, os deviations nem o build do validador. O teste talvez tenha sido correto; o problema é que ninguém mais conseguia formular com precisão o que ele havia testado.

Esse é o ponto valioso da revisão 00 de Validating anydata in YANG Library context. Em YANG 1.1, anydata representa conteúdo modelável com YANG cujo modelo específico não era conhecido quando o módulo contêiner foi projetado. Filtros, respostas de datastore, edições, arquivos de instância e notificações usam essa abertura. O consumidor, porém, ainda precisa escolher qual schema avaliará os nós recebidos.

O rascunho começava pela identidade preservada na codificação. XML combina local name e namespace do módulo; JSON usa o identificador, qualificado pelo módulo quando necessário; CBOR pode usar SID, SID delta, nome qualificado ou instance-identifier. O validador seguiria essa identidade até o data node correspondente na YANG Library.

Não existe, contudo, uma Library sem contexto. A RFC 8525 associa cada datastore a um schema, forma o schema pela união de module-sets e descreve módulos com revisions, submodules, features e deviations. O content-id muda quando a Library muda, mas é específico da implementação e não um hash universal. Em uma árvore montada, também importam o mount path e o contexto local.

Candidate não é sinônimo de complete

anydata-complete deveria validar a subtree contra todas as regras do schema correspondente. anydata-candidate deixava de aplicar os constraint checks. A terminologia dialoga com a RFC 7950: running e startup impõem as restrições ao fim da operação, enquanto candidate pode adiá-las até commit ou validate.

Um candidate pass afirma que o caminho candidato aceitou a estrutura sem concluir esses testes. Um complete pass afirma que uma implementação identificada, sob entradas identificadas, não encontrou violação nas regras executadas. Dizer apenas que ambos são “YANG-valid” transforma uma distinção verificável em uma garantia vaga.

Uma falha também é limitada. Ela pode apontar tipo, faixa, must, when, cardinalidade, nó desconhecido ou contexto incompatível. Não determina o responsável. A origem pode estar errada, um intermediário pode ter reescrito o conteúdo, o consumidor pode ter escolhido a Library errada ou o validador pode divergir. A falha sustenta quarentena e investigação, não atribuição automática.

O rascunho ilustra o risco com um contador negativo de octetos enviado por um nó defeituoso em YANG-Push. Uma plataforma de análise poderia somar o tráfego de forma incorreta e afetar faturamento ou planejamento de capacidade. A validação completa pode capturar essa classe de erro. Ela não prova que um número positivo é atual, completo, autêntico ou referente à interface presumida.

O recibo precisa sobreviver ao software

Um registro reproduzível guarda hash, horário e encoding do payload, além da identidade decodificada do nó. Liga o content-id a um snapshot congelado da YANG Library e registra datastore, schema, module-sets, revisions, submodules, features, deviations e mount context. Também informa validador, build, flags, modo, diagnóstico e decisão posterior.

Esses campos explicam mudanças. Uma feature pode remover um nó; um deviation altera a regra; um mount muda a resolução; um upgrade do parser trata casos limítrofes de outro modo. Se os mesmos bytes mudarem de veredicto, o primeiro objeto de investigação passa a ser a diferença de contexto.

O rascunho tornava a validação opcional e permitia ao consumidor ignorar, registrar ou alertar sobre mensagens não conformes. A política continua fora do mecanismo. O dono dos dados deve decidir quais falhas interrompem automação, quais aceitam nova tentativa e quais exigem revisão humana.

O documento expirou

O Datatracker registra 2 de dezembro de 2025 como a data da revisão mais recente e mostra a versão WG 00 disponível naquele dia. O texto expirou em 3 de junho de 2026. Hoje aparece como Expired Internet-Draft, Expired & archived, Dead WG Document e IESG Expired; o campo Intended RFC status está como None.

O masthead histórico dizia separadamente Intended status: Standards Track. Essa intenção editorial não é aprovação da IETF. A análise de segurança permaneceu inacabada, não houve pedido à IANA e o Datatracker não lista shepherd.

Implementation Status apontava para um branch de libyang com anydata-candidate e pedia a remoção da seção antes de eventual publicação. Um branch demonstra no máximo um caminho experimental. Não comprova merge, implementações independentes, interoperabilidade ou uso em produção.

Schema correto não significa realidade comprovada

A RFC 8342 separa running, intended e operational: conformidade não prova que o dispositivo aplicou a configuração. A RFC 8341 trata controle de acesso: estrutura válida não concede autorização NACM. As RFCs de subscription e YANG-Push tratam seleção e entrega: uma subtree válida não exclui perda, replay, ordem incorreta ou reescrita.

Identidade do emissor, integridade de transporte e cadeia de custódia exigem evidências próprias. Contadores de equipamento, FIB, captura de pacotes, observação remota e conciliação financeira respondem a perguntas diferentes. O validador não pode falar por essas camadas porque sua saída é fácil de automatizar.

O legado útil da revisão 00 não é um novo selo universal. É tornar uma subtree antes opaca testável sob um contexto nomeado e preservar dois níveis diferentes de inferência. Com o contexto, o teste reduz a incerteza. Sem ele, o sinal verde só adia a disputa.

Fontes

Documento: revisão 00, status no Datatracker e histórico.

Contexto técnico: RFC 7950, RFC 8525, RFC 8342, RFC 8341, RFC 8528, RFC 8639 e RFC 8641.

Referencial analítico: Minimum Initial Specification, On Reality Layers e Running Code Primary.