Resumo

  • A revisão 14 do modelo YANG de incidentes separa o ciclo da instância de rede (raised, updated, cleared) do ciclo do operador (acknowledged, diagnosed, resolved).
  • Uma RPC incident-resolve pode mirar vários incidentes e o êxito aparece depois em notificação separada. A revisão YANG Doctors apontou que não há como associar a notificação à RPC que a originou.
  • Um recibo do comando ao cleared deve unir pedido, permissão, conjunto-alvo, execução, evento, chamado e teste do serviço. Trata-se de proposta editorial, não de requisito do IETF.

O estado final perdeu a origem

O documento do grupo NMOP organiza um problema que cresce com a automação: alarmes, métricas e anomalias de várias camadas precisam ser correlacionados antes de virarem uma quantidade administrável de incidentes. O modelo oferece operações para reconhecer, diagnosticar e resolver essas instâncias.

Sua assimetria é deliberada. O cliente chama incident-resolve com uma lista de incident-no. O servidor executa trabalho potencialmente demorado. Quando considera um incidente resolvido, envia mais tarde uma notificação separada e muda o estado para cleared. O modo concreto de resolver ficou fora do escopo.

O número preserva a identidade do incidente, não a identidade da chamada. Isso basta para saber qual registro mudou, mas não para distinguir duas tentativas concorrentes, uma repetição depois de timeout, uma cura autônoma ou o desaparecimento natural da condição. A notificação pode ser autêntica e o nexo causal continuar desconhecido.

A separação de ciclos é uma proteção

A instância de rede percorre raised, updated e cleared. O trabalho do operador percorre acknowledged, diagnosed e resolved. Esses dois vocabulários impedem que um sinal ausente seja automaticamente tratado como investigação concluída, ou que a conclusão humana apague uma condição ainda observada.

O rascunho também pede integração com o sistema de chamados do OSS. Recomenda uma tradução determinística para estados como Open, Assigned, In-Progress e Resolved, de modo a impedir que rede e chamado apresentem fechamentos opostos.

A regra determinística resolve consistência de representação. Não cria prova de execução. Se cleared for sempre transformado em Resolved, um evento sem origem conhecida ganhará uma conclusão administrativa perfeitamente sincronizada.

A revisão encontrou a lacuna verificável

Em 31 de agosto, a revisão inicial do YANG Doctors classificou o trabalho como Almost Ready, mas observou que os resultados das RPCs chegam por notificações sem um meio de correlacionar qual notificação pertence a qual chamada. O revisor fez a mesma pergunta para o diagnóstico e pediu clareza sobre identificadores, máquinas de estado, listas vazias, erros e direção da notificação.

O próprio parecer limita seu alcance. Ele diz que os autores e o responsável esperavam uma próxima iteração ainda não publicada e que ela deveria ser revisada. Portanto, o achado descreve a interface examinada. Não prova falha operacional, não condena a proposta e não permite afirmar que texto futuro repetirá o problema.

As atas do NMOP na IETF 126 já registravam perguntas sobre chave, número e ID do incidente. A discussão mostra que a identidade é uma superfície de projeto, mas não fornece resultado de implantação.

Permissão de entrada e autoria do resultado

O modelo pressupõe NETCONF ou RESTCONF com transporte seguro e autenticação mútua. NACM limita quais usuários acessam determinados dados e operações. Uma falha de resolução pode indicar causa provável não resolvida, permissão negada, timeout ou recurso indisponível.

Esses controles respondem quem entrou, o que podia pedir e por que o limite síncrono recusou uma operação. O vínculo assíncrono responde outra pergunta: qual chamada autorizada, se alguma, explica o estado observado depois.

Um mesmo principal autenticado pode chamar duas vezes. A primeira pode expirar do ponto de vista do cliente enquanto continua no servidor. A segunda pode ser aceita, e uma proteção local pode resolver a condição antes de qualquer uma. Sem identidade de invocação, escolher uma origem é inferência, não registro.

Há ainda uma obrigação de sigilo. Ler incidentes pode revelar o estado avariado da rede, e muitas chamadas de diagnóstico ou resolução podem consumir recursos. Um recibo completo deve ficar sob controle de acesso. A superfície pública pode mostrar somente classe de ação, janela temporal, autorização, qualidade da correlação e teste de serviço.

Lotes distribuem crédito e responsabilidade

Imagine uma chamada com os incidentes 81, 82 e 83. O primeiro é eliminado pela ação solicitada; o segundo some após failover local; o terceiro é reclassificado quando a topologia é atualizada. Os três podem terminar fora da lista ativa. Só um, porém, prova a eficácia daquele comando.

Contar os três como êxito transfere crédito para o orquestrador. Também apaga a decisão prudente de um operador que recusou uma ação arriscada. A revisão 14 admite que resolver pode afetar serviços em produção e que o cliente pode não agir quando o impacto não é trivial. A não execução e a alternativa escolhida precisam sobreviver à métrica final.

O texto alerta que topologia desatualizada prejudica a identificação de causa provável e a análise de impacto. Uma mudança de conhecimento pode alterar o incidente sem que uma intervenção tenha corrigido o equipamento. A distinção é indispensável para aprender com o ocorrido.

O estado do padrão também é limitado

A revisão 14 foi publicada em 18 de agosto de 2026. A última chamada do grupo NMOP terminou em 3 de setembro. No recorte de 9 de setembro, o Datatracker ainda dizia In WG Last Call, sem AD responsável e sem telechat. A revisão 14 é Internet-Draft ativo com intenção Standards Track; não é RFC nem aprovação final do IETF.

Em 7 de setembro, a validação YANG registrou zero erros e zero avisos. Esse resultado importa para a consistência do esquema. Não prova interoperabilidade, implantação ou encadeamento de uma ordem ao restabelecimento. Um teste convincente precisaria combinar chamadas simultâneas, conjuntos sobrepostos, cura autônoma, atraso de eventos e resultado parcial.

Registrar sem forçar causalidade

O recibo do comando ao cleared começa com uma identidade única de invocação. Congela incidentes e revisões-alvo, principal e papel, versões de NACM e política de mudança, impacto previsto, aprovação necessária e alternativa escolhida.

Depois registra aceitação ou erro por incidente, versão do servidor e do modelo, repetições, divisões e contingências. A notificação recebida é ligada à chamada, classificada como mudança independente ou marcada como correlação desconhecida. O sistema não precisa inventar um pai para cada estado verde.

No fechamento, o recibo inclui regra de tradução do OSS, estado e autor do chamado, teste do serviço, causa residual ou desvio, responsável por rollback e correções. Isso pode existir fora do protocolo e preservar detalhes sensíveis.

The Policy Mirror separa os lugares em que o poder é escrito: NACM concede, a RPC pede, o servidor observa, o chamado conclui e o teste de serviço confronta a realidade. Running-Code Primacy exige que a execução ligue esses vestígios. Reality, Not Advocacy contém a acusação: o rascunho oferece linguagem útil; cleared apenas não comprova sua própria causa.

Fontes