Um agendamento YANG pode manter autoridade vencida

Summary

O RFC 9922 padroniza tipos e agrupamentos YANG reutilizáveis para datas, recorrências, guardas e estados. Ele deixa fora do escopo a natureza da ação disparada e a solução de conflitos; por isso, um estado habilitado não informa sozinho quem ainda tem autoridade sobre o efeito.
Daniel Kade propõe um recibo de autoridade da ocorrência, ligando versão e hash do agendamento, ação, alvo, patrocinador institucional, política atual, principal de execução, tempo e resultado. É uma proposta operacional, não requisito do RFC nem alegação de falha conhecida.

A regra temporal atravessa uma organização que não fica parada

Agendar é enviar uma decisão ao futuro. A técnica permite reservar capacidade antes da demanda, aguardar uma janela de manutenção e repetir medições sem recriar o comando. A automação funciona porque o instante da aprovação não precisa coincidir com o instante do efeito.

Nesse intervalo, porém, a organização muda. Pessoas saem, serviços trocam de dono, políticas ganham novas versões, alvos passam de laboratório para produção e contas permanecem ativas durante transições. Nada disso precisa invalidar a sintaxe da recorrência.

O painel pode, então, mostrar uma sequência impecável: regra válida, próxima ocorrência dentro do limite, versão atual, nenhuma colisão, tempo confiável. Esses fatos provam que o agendador compreendeu sua instrução. Não provam que a instituição mantém hoje a mesma autorização.

O caso não depende de invasão ou negligência. Um sistema obediente e uma reorganização legítima bastam. A pergunta decisiva é qual autoridade transforma aquela instrução antiga em uma decisão vigente nesta ocorrência.

A validade descrita pelo RFC 9922 é temporal

Publicado em março de 2026, o RFC 9922 é um documento Standards Track de consenso do IETF. Ele define o módulo ietf-schedule, com tipos e agrupamentos comuns para agendar eventos, políticas, serviços e recursos. Há suporte a evento único, período e recorrência, de uma regra básica a uma representação próxima de iCalendar.

O escopo é deliberadamente modular. O texto não presume qual ação será disparada e não resolve detecção ou tratamento de conflitos entre agendamentos. O módulo comum, isoladamente, não expõe nós graváveis, nós de estado operacional nem RPCs. Módulos consumidores reutilizam, refinam e ampliam seus agrupamentos.

Isso é adequado. Um alarme, um teste OAM, uma reserva e uma alteração destrutiva não deveriam receber a mesma política universal de autorização de uma biblioteca de calendário. O controle específico surge onde o tempo é conectado ao efeito.

No agrupamento generic-schedule-params, validity é a data depois da qual um agendamento não pode mais começar. Ocorrências posteriores não são executadas. Limites de início e fim, além da ação de descarte, protegem contra pedidos vencidos ou fora da janela aceita.

Nada aí identifica o órgão aprovador, a função atual do criador, a política aplicável na execução ou a necessidade de nova decisão após mudança do alvo. Estar dentro do prazo não equivale a continuar autorizado.

A versão mais recente não é uma assinatura institucional

Os agrupamentos de estado do RFC 9922 podem mostrar enabled, disabled, finished, out-of-date e conflicted. Também carregam versão, última atualização, contadores, ocorrência anterior e seguinte, último erro e total de falhas.

São informações úteis, mas cada uma responde a uma pergunta operacional. A versão indica qual definição está corrente, não quem a aprovou. last-update registra alteração, não ratificação. Um contador de falhas zerado não detecta uma ação bem-sucedida cujo mandato deixou de existir.

Na tabela de correspondência com o antigo DISMAN-SCHEDULE-MIB, o RFC 9922 marca schedOwner como “Not Supported”. Ao mesmo tempo, admite que módulos futuros podem acrescentar fonte e precedência quando agendas vêm de origens diferentes.

O dado não permite afirmar que produtos não guardam dono ou aprovador. Eles podem ampliar o modelo. A conclusão segura é apenas que proprietário e patrocinador não compõem o estado genérico comum. Se uma organização precisa deles como prova, deve fazer a ligação na camada consumidora.

É por isso que a frase “o agendamento atual executou com sucesso” engana quando usada como autorização. “Atual” pode designar apenas a última versão salva. “Sucesso” pode significar somente que o gatilho chamou a operação.

NACM protege a requisição; a ocorrência futura precisa de identidade própria

O RFC 8341 define o NACM para controlar operações e conteúdo de NETCONF e RESTCONF. Uma sessão autenticada é associada a usuário e grupos. O servidor usa as regras vigentes quando começa a processar a mensagem. Isso pode proteger criação, alteração e exclusão do agendamento, bem como ações expostas pelo módulo consumidor.

Portanto, não se trata de dizer que YANG ignora controle de acesso. O ponto é identificar qual principal e qual regra governam uma execução muito posterior.

O RFC 8341 descreve requisições iniciadas por sessões de usuário e distingue certos acessos iniciados pelo servidor. Ele não determina se toda ocorrência futura herda a identidade original, usa uma conta de serviço, vira uma nova ação sujeita à política atual ou consome uma delegação institucional durável.

Uma cópia de segurança deve sobreviver à troca de administrador. Uma rotação de chave, retirada de rota ou preempção de recurso pode precisar de nova autorização se alvo ou risco mudarem. As duas decisões podem ser corretas; o problema é deixar a escolha escondida em um padrão de implementação.

Também é preciso separar criador, patrocinador institucional, principal técnico e autoridade que aprova o efeito. Um único nome de usuário antigo é ruim tanto para continuidade quanto para revogação seletiva.

Relógio autenticado não concede poder

O RFC 9922 alerta que agendamento depende de tempo preciso. Erros podem disparar eventos no intervalo errado; recorrências muito frequentes podem esconder anomalias ou manter o sistema ocupado; sem logs detalhados de cada gatilho e resultado, incidentes ficam difíceis de reconstruir.

O RFC 3339 padroniza datas e horas. O RFC 7317 oferece configuração YANG de fuso e NTP. O RFC 8915 define Network Time Security, com identidade da fonte, autenticação dos pacotes, prevenção de replay e vínculo entre pedido e resposta.

Essas propriedades dão confiança a “eram duas da manhã”. Não sustentam “a ação ainda podia ocorrer”. Um relógio autêntico pode disparar pontualmente um mandato vencido. Uma ação legítima pode falhar por hora errada.

O recibo deve conservar duas provas separadas: fonte, horário e incerteza de um lado; autoridade, política, principal e decisão do outro. Um único selo de válido esconde qual delas falhou.

Reservas futuras mostram o tamanho do intervalo

O RFC 8413 descreve reserva programada de recursos de engenharia de tráfego. Um LSP futuro pode ser calculado e reservar capacidade agora, embora só seja estabelecido no início da janela. O framework pede correlação entre o LSP e a reserva para explicar por que o recurso foi separado, administrar preempção e liberar após cancelamento. A política do operador continua controlando limites e reotimização.

O RFC 8934 concretiza isso em PCEP. Um PCE stateful mantém LSPs agendados; no início, o PCC dispara o estabelecimento e, no vencimento, pode remover o LSP conforme os atributos. Pedido, cálculo, sincronização, ativação e exclusão acontecem em momentos diferentes.

Esses documentos não relatam falha de autorização. Eles revelam uma superfície de decisão adiada. O caminho pode continuar viável e a capacidade, reservada, enquanto o pedido comercial foi cancelado em outro sistema ou o proprietário mudou. Disponibilidade, correção protocolar e autorização são três junções.

O recibo de autoridade da ocorrência

Não é necessário reabrir o módulo comum. A camada que liga calendário e ação pode emitir um recibo compacto para cada ocorrência ou para uma série homogênea e delimitada de baixo risco.

O recibo deve ligar:

identificador estável, versão e hash exato da definição;
instância da recorrência, hora planejada e hora observada;
classes de ação e alvo, com compromissos protegidos para valores sensíveis;
criador e patrocinador institucional atual;
base de autorização na criação e versão atual de política ou delegação;
principal executor e resultado atual de permitir ou negar;
fonte de tempo e incerteza relevante;
decisão de conflito, precedência ou preempção;
compromisso do estado pretendido, estado aplicado e resultado;
motivo de falha, cancelamento ou não execução deliberada;
ligações de substituição e correção.

Isso não exige aprovação humana a cada minuto. Uma decisão assinada pode cobrir classe de ação, conjunto de alvos, teto de risco e faixa de ocorrências. Mudanças na versão, no patrocinador, no alvo, na política ou no efeito encerram a reutilização.

Também não é preciso publicar usuários, topologia ou configuração. A superfície pública pode expor classe institucional, identificador de política, hashes, custodiante e disposição; os detalhes ficam em evidência protegida.

O objetivo é responder “por que esta execução ainda era permitida?” com a mesma precisão usada para “quando ela ocorreu?”.

As objeções ajudam a calibrar

Continuidade é a primeira objeção. Um agendamento institucional não deve morrer quando o criador muda de cargo. Certo: o recibo deve permitir transferência explícita para um papel durável, sem depender de conta abandonada.

Custo é a segunda. Reavaliar política complexa a cada segundo pode ser inviável. Um lease de autorização em cache pode cobrir ocorrências equivalentes, desde que tenha escopo, duração e gatilhos de invalidação claros.

A terceira é duplicação. NACM, orquestrador e plataforma de auditoria talvez já tenham os dados. O recibo pode ser uma junção entre evidências existentes. A pergunta é se um operador autorizado consegue conectar versão, principal atual, ocorrência e resultado sem depender da memória da equipe.

A quarta é a modularidade. O RFC 9922 não conhece ações porque não deve conhecê-las. Logo, o controle cabe ao módulo consumidor ou à camada de garantia. Respeitar esse limite é mais útil do que culpar a biblioteca temporal.

Limites da evidência

As fontes descrevem padrões, não ambientes de produção. Elas não demonstram que um fornecedor, operador ou projeto execute agendas com autoridade ultrapassada. Não há aqui incidente, vulnerabilidade explorada, perda ou violação comprovada. Também não se pode concluir que implementações existentes não guardem proprietário, principal de serviço, nova autorização ou logs detalhados.

O recibo proposto não é exigência do IETF. O RFC 9922 é um documento Standards Track de consenso, com objetivo preciso, e atribui corretamente as considerações específicas aos módulos que reutilizam seus agrupamentos.

A conclusão defensável é menor: um agendamento pode continuar válido no vocabulário temporal e operacional do RFC 9922, enquanto a autoridade institucional de sua ação é um fato separado. Se não houver registro de continuidade, transferência, reavaliação ou retirada, o rótulo enabled passa a prometer mais do que o modelo prova.

Um agendamento YANG válido não prova que sua ação ainda está autorizada

Por que isso importa

Summary

A regra temporal atravessa uma organização que não fica parada

A validade descrita pelo RFC 9922 é temporal

A versão mais recente não é uma assinatura institucional

NACM protege a requisição; a ocorrência futura precisa de identidade própria

Relógio autenticado não concede poder

Reservas futuras mostram o tamanho do intervalo

O recibo de autoridade da ocorrência

As objeções ajudam a calibrar

Limites da evidência

Sources

Contexto aprofundado do perfil

Strategic Circle

Leadership Alliance

Briefing do Strategic Circle

Briefing da Leadership Alliance