Resumo

  • A revisão 16 decidiu manter o modelo de incidentes independente de confiança; a revisão 17 preserva uma Causa Raiz Provável estruturada, mas sem score, identidade e versão do produtor ou registro de calibração.
  • Os rascunhos vizinhos do NMOP para anomalias conservam confiança, preocupação e proveniência do anotador. O risco surge quando esse envelope a montante é descartado e apenas a causa escolhida continua circulando.
  • Uma causa tipada é uma hipótese operacional delimitada, não uma autorização para remediar. A cadeia de evidências deve ligar versão analítica, revisão do incidente, limiar de decisão, ação autorizada e resultado observado.

O teste do turno seguinte

O engenheiro que diagnosticou uma interrupção pode se lembrar de que interface-hardware-failure venceu por pouco uma hipótese de erro de configuração. O turno seguinte recebe algo diferente: um cartão de incidente com nó, porta, evento de perda de sinal, prioridade crítica e uma Causa Raiz Provável formal. A hesitação humana, o intervalo de telemetria e a alternativa quase empatada já não aparecem.

Esse cartão não é falso. Ele é incompleto de uma maneira que a padronização pode tornar invisível. Quanto mais bem formado o objeto, maior a tentação de ler sua precisão como certeza.

O histórico de draft-ietf-nmop-network-incident-yang mostra que a lacuna é uma escolha arquitetural, não um campo esquecido. A revisão 15 dizia que o trabalho correlato de detecção atribuía scores de confiança e preocupação. A revisão 16 retirou essa frase e registrou no changelog a decisão de manter o modelo de incidentes independente de confiança. A revisão 17, datada de 24 de setembro de 2026, conserva essa fronteira.

O ponto não é obrigar toda implementação a usar o mesmo número. É impedir que a passagem entre dois modelos apague a condição epistemológica daquilo que sobrevive.

O que o núcleo comum sabe dizer

O modelo permite abrir um incidente antes de sua origem ser conhecida. A lista de fontes pode começar vazia e ganhar conteúdo depois do diagnóstico. Quando existe uma hipótese causal, probable-causes pode indicar rede, nó e, opcionalmente, recurso; cause-name fornece uma identidade comum; um detalhe explica o caso; probable-events aponta para eventos relacionados. Domínio, prioridade e categoria são obrigatórios no agrupamento.

Há valor real nisso. Sistemas distintos podem trocar uma classe reconhecível em vez de comparar parágrafos livres. A referência ao recurso localiza a falha alegada. A ligação com eventos permite voltar a observações. Um incidente pode continuar útil enquanto novas fontes são incorporadas.

Mas cada campo responde a uma pergunta operacional diferente. Prioridade mede urgência, não probabilidade causal. Categoria classifica a família do incidente, não a qualidade do detector. Um evento relacionado demonstra associação, não suficiência causal. Um identityref interoperável torna o rótulo estável, não verdadeiro.

A própria definição de Causa Raiz Provável exige cuidado: é a condição de falha cuja remoção completa interrompe o incidente e impede recorrência, e não apenas uma condição contribuinte. O objeto, porém, não registra de forma padronizada um teste de remoção, uma janela de recorrência, uma comparação contrafactual ou hipóteses concorrentes. A definição estabelece a ambição sem certificar que toda instância já a comprovou.

A confiança continuou existindo em outra família de registros

Nos rascunhos de anomalias, o vocabulário ausente reaparece. draft-ietf-nmop-network-anomaly-lifecycle-07 define confiança de 0 a 100 para a anomalia ou estratégia de detecção e preocupação, também de 0 a 100, para a atenção operacional. O modelo registra versão e estágio da anomalia, identidade e nome do anotador, se ele é humano ou algorítmico e sua versão. Detecção, validação e refinamento formam um ciclo.

draft-ietf-nmop-network-anomaly-semantics-06 serializa confiança, preocupação, estratégia, tipo e versão do anotador. Seus exemplos admitem confiança nula. Guardar o envelope, portanto, não inventa certeza; ele pode registrar honestamente que o julgamento ainda não foi quantificado.

Uma arquitetura saudável pode manter o incidente compacto e o julgamento rico. O problema começa quando a chave entre ambos é frágil, mutável ou temporária. Alarmes e métricas são agregados, uma causa é selecionada, o incidente ganha uma identidade duradoura e o contexto analítico fica em um painel que será recalculado. Meses depois, o rótulo causal permanece no histórico, mas já não se sabe qual versão do detector, qual população de calibração ou quais sinais incompletos o produziram.

Isso é um risco de compressão. Reduzir milhares de observações a um incidente é necessário; decidir o que atravessa a redução é um ato de governança.

Confiança, preocupação e prioridade não formam um único semáforo

Confiança pergunta quão fortemente uma estratégia considera a observação anômala. Preocupação pergunta quanto a condição merece atenção ou correção considerando impacto provável e conhecimento operacional. Prioridade do incidente acrescenta a urgência de tratar o objeto agregado.

As combinações importam. Uma mudança de tráfego prevista pode ser inequivocamente anômala e pouco preocupante. Um indício óptico fraco em um serviço crítico pode ter baixa confiança e alta preocupação. Um incidente pode receber prioridade máxima porque o custo potencial é enorme, embora a causa líder continue disputada.

Copiar o mesmo 90 para as três dimensões destruiria informação. Scores dependem do produtor, do conjunto de referência, da janela de observação, das regras ou treinamento e do método de calibração. Noventa em um detector não é necessariamente comparável a noventa em outro. A independência do núcleo comum protege a interoperabilidade de uma falsa universalidade; ela não autoriza eliminar as diferenças na camada de decisão.

Autorização controla a ação, não valida a hipótese

A revisão 17 espera transportes seguros, autenticação mútua e controle de acesso, inclusive por NACM. Isso é indispensável: o registro pode expor serviços identificáveis e a forma quebrada da rede; operações de diagnóstico e resolução podem consumir recursos ou modificar o serviço em produção.

Autenticação responde quem se conectou. Autorização responde quem pode ver uma causa ou invocar uma operação. Nenhuma delas mede se a inferência foi bem calibrada. Um principal devidamente autorizado pode agir sobre uma hipótese ruim; um diagnóstico muito confiável não concede, por si só, permissão para alterar a rede.

A decisão automatizada precisa carregar as duas dimensões separadamente: por que se acreditou na causa e por que a instituição permitiu a ação.

Implementação declarada é evidência limitada

O rascunho lista o Huawei iMaster NCE como implementação do modelo com gestão por intenção e ferramentas de IA, RESTCONF, ciclo de vida, notificações e consulta da lista de incidentes. Isso conta como evidência de código em execução.

A mesma seção adverte que as informações vieram dos contribuidores, não foram verificadas pelo IETF, não significam endosso e não compõem um catálogo completo. O registro congelado não fornece um traço de interoperabilidade sobre a preservação de confiança e versão do anotador, nem relatório de calibração, acurácia ou resultado de incidentes em produção.

A conclusão responsável é estreita: há uma implementação declarada; a conservação do envelope de confiança permanece uma pergunta empírica.

O artigo anterior trata de outra junção

BTW já publicou A Cleared Incident Does Not Prove Which Command Cleared It. O texto analisa, na revisão 14, a distância assíncrona entre um pedido incident-resolve e uma notificação posterior de estado cleared: qual comando produziu a mudança?

Este briefing começa antes. Ele pergunta qual evidência sustentava a causa antes que alguém escolhesse um comando. Um identificador de requisição perfeito não recupera confiança descartada. Uma causa bem calibrada ainda requer autorização e prova de resultado. São falhas em junções diferentes; nenhuma substitui a outra.

Fontes