Resumo

  • draft-ietf-netconf-error-registries-00 propõe dois registros IANA para tags e identidades de erro YANG; a revisão inicial ainda é incompleta e não transforma um nome estável em diagnóstico de causa.
  • A automação precisa preservar sessão, operação, solicitante, autorização, caminho, identidade qualificada pelo módulo, informações estruturadas, resultado da transação, remediação, leitura e efeito no serviço.

O orquestrador recebe invalid-value e prepara a nova tentativa.

Parece uma resposta rigorosa: existe uma grafia padronizada, pronta para uma condição de software. No RESTCONF, porém, a mesma tag pode acompanhar HTTP 400, 404 ou 406. Em situações de controle de acesso, o servidor pode responder 404 com invalid-value para não confirmar que um recurso protegido existe. A mensagem está correta justamente porque não entrega toda a realidade ao chamador.

É essa fronteira que torna relevante o draft-ietf-netconf-error-registries-00, publicado em 30 de setembro de 2026. O documento ativo do grupo NETCONF propõe uma Lista de Erros de Protocolo YANG e um registro de Identidades de Erro YANG. A finalidade é evitar que cada autor ou implementação reconstrua uma fonte canônica a partir de vários RFCs.

A revisão 00 pretende seguir o Standards Track e expira em 3 de abril de 2027. Não é RFC, registro aprovado pela IANA, prova de implementação nem teste de interoperabilidade. Em cinco páginas, abre uma superfície de governança.

O primeiro registro guardaria error-tag, tipos válidos, severidade, error-info, descrição e referência. O segundo guardaria nome da identidade, identidade-base quando aplicável, informação adicional e referência. Ambos seriam mantidos por IETF Review.

Há ganho concreto. Uma fonte comum reduz divergência de grafia, torna extensões descobríveis, liga o valor ao documento responsável e permite tratar criação, mudança, descontinuação e substituição em público. É um plano de controle para o vocabulário.

Mas a própria revisão 00 mostra o grau de precisão necessário. As descrições de error-tag, error-type e error-severity ainda estão como TBD. O texto diz que o conteúdo inicial vem do Apêndice A do RFC 6241, mas incorpora somente in-use, invalid-value, too-big, missing-attribute e bad-attribute. O apêndice continua com access-denied, resource-denied, rollback-failed, data-missing, operation-not-supported, operation-failed, malformed-message e várias outras tags.

A lista de identidades também conserva sinais da primeira edição. filter-unsupported, insufficient-resources e no-such-subscription aparecem repetidas. Identidades presentes nos RFCs citados ficaram de fora: RFC 8639 contém stream-unavailable, suspension-timeout e unsupportable-volume; RFC 8641 contém cant-exclude, no-such-subscription-resync, on-change-unsupported, on-change-sync-unsupported e sync-too-big. A política é referenciada pelo RFC 5226, embora o RFC 8126 seja a edição atual do BCP 26 e o tenha substituído.

Esses fatos não autorizam chamar um padrão futuro de defeituoso. Eles descrevem a revisão 00. Antes de virar dependência de automação, a proposta ainda precisa de unicidade, cobertura, referências atuais e semântica explícita. Tabelas privadas para mascarar lacunas apenas recriariam a fragmentação que o trabalho procura remover.

Mesmo o registro perfeito não seria um prontuário do incidente.

O RFC 6241 permite vários elementos <rpc-error> na mesma resposta NETCONF. Cada elemento pode carregar a camada conceitual, a tag de protocolo, severidade, tag específica do modelo ou da implementação, XPath do nó afetado, mensagem legível e informação estruturada. Essas dimensões diferenciam classificação, contexto e alvo.

O RFC 8640 demonstra a hierarquia em erros de assinatura. filter-unsupported usa a tag ampla invalid-value; insufficient-resources, resource-denied; on-change-unsupported, operation-not-supported; sync-too-big, too-big; unchanging-selection, operation-failed. A identidade específica viaja em error-app-tag com o módulo, como ietf-subscribed-notifications:no-such-subscription.

Nem essa identidade deve ser lida fora da operação. A identidade-base viável depende de a RPC estabelecer, modificar, excluir, encerrar ou ressincronizar a assinatura. Em estabelecimento e modificação, error-info pode sugerir parâmetros para uma solicitação futura. Descartar RPC, módulo e dicas deixa uma palavra onde existia uma estrutura de evidência.

unchanging-selection ilustra a compressão intencional. O RFC 8641 permite essa razão quando a seleção aponta para dados inexistentes ou para dados que o receptor não pode ler. Ela também pode aparecer quando uma mudança de acesso torna invisíveis atualizações antes visíveis. Corrigir o caminho, obter permissão e reconstruir o filtro após uma mudança de política são respostas distintas. O protocolo as aproxima para proteger abstração e sigilo.

no-such-subscription preserva a mesma defesa. Segundo o RFC 8639, o identificador pode não existir, pertencer a outro assinante ou referir-se a uma assinatura configurada para a qual a RPC não serve. O resultado seguro é suficiente: a operação não pode atuar naquele identificador. O cliente não ganha direito a uma consulta indireta aos registros internos.

insufficient-resources comprime outra incerteza. O publisher não consegue produzir a assinatura, mas a identidade não revela se falta memória, CPU, largura de banda, fila, limite da implementação ou cota. Não diz quem controla a capacidade, quando ela volta ou qual carga deve ceder.

O registro é autoridade sobre nomes, não oráculo de eventos.

O recibo mínimo começa antes do erro: protocolo e sessão, RPC, identificador da requisição, principal autenticado e decisão de autorização. Mantém datastore e caminho, tag ampla, identidade qualificada e sua base, error-info, revisão de servidor e módulos e resultado da transação. Depois da intervenção, registra a alteração autorizada, a leitura do estado e o resultado observado no serviço.

Cada elo impede uma equivalência falsa. Um 404 não prova ausência. Uma identidade específica não prova causa física. Uma nova solicitação aceita não prova mudança de estado. Uma mudança confirmada não prova recuperação do serviço.

O princípio de especificação inicial mínima de Heng Lu oferece a divisão adequada. O processo de padronização define o menor vocabulário interoperável e suas regras de extensão. A decisão futura permanece com quem possui os fatos futuros: servidor, operador e proprietário do serviço. O registro localiza a governança do nome sem centralizar o julgamento causal.

A distinção entre camadas de realidade protege a mesma disciplina. operation-failed é um símbolo. Nó ausente, permissão revogada, fila esgotada e parâmetro impossível são realidades diferentes. O símbolo pode cobri-las de propósito. Tratá-lo como a realidade cria certeza fictícia.

A primazia do código em execução acrescenta o último recibo. Repetir a chamada ou concluir uma escrita não basta. É preciso reler o estado e observar o serviço pretendido. Só então a remediação deixa de ser uma intenção registrada e se torna um fato operacional.

Fontes