Resumo

  • RFC 9922 fornece tipos e groupings YANG reutilizáveis para agendamentos baseados em data e hora. Estado, contador, last-occurrence e upcoming-occurrence descrevem o plano de tempo; não são um recibo de ação.
  • O RFC não presume que ação o agendamento dispara e deixa conflitos fora de escopo. A autorização local, a invocação, a execução, a compensação e a verificação de efeito precisam permanecer rastros independentes.

Na troca de turno, a observação costuma parecer suficiente: “a rotina de manutenção está habilitada, a versão é a esperada e houve ocorrência na semana passada”. É uma boa observação do calendário. O problema começa quando ela vira uma afirmação sobre o que o calendário teria feito fora dele.

Uma ocorrência não é uma operação. Uma previsão não é uma permissão. Um contador não é uma comprovação de que todo trabalho previsto chegou ao fim. Essas distinções soam pedantes apenas enquanto não há falha para explicar. Depois de uma alteração indevida ou de um serviço que não voltou, elas se tornam a diferença entre uma investigação possível e uma tela verde sem autor, alvo ou resultado.

RFC 9922, o modelo comum YANG do IETF para agendamento, é deliberadamente mais modesto que uma plataforma de automação. Ele oferece tipos e groupings para que módulos representem agendamentos de eventos, políticas, serviços ou recursos. Regras básicas de recorrência, formas UTC, fusos horários, listas de períodos e regras derivadas de iCalendar podem ser entendidas de modo comum. O módulo consumidor é que define qual objeto está sendo agendado e o que, se algo, ocorrerá quando a hora chegar.

O estado pertence ao calendário, não ao resultado imaginado

Os groupings de schedule-status podem expor estado, versão, tipo de agendamento, hora local do host, última atualização, contador de recorrência, última ocorrência, próxima ocorrência, última ocorrência falha e contador de falhas. Cada dado pode ser essencial para observação. Nenhum deles, isoladamente, contém a cadeia inteira de controle.

Em uma recorrência, upcoming-occurrence só pode aparecer quando o estado está habilitado. Isso mostra que o host calculou uma próxima ocorrência segundo a regra que representa. Não mostra que o executor estará de pé; que os recursos estarão disponíveis; que uma identidade terá a autorização correta; que o destino aceitará a chamada; ou que a ação terminará bem. last-occurrence registra uma ocorrência anterior e é distinto de last-failed-occurrence. A separação é útil, mas não transforma nenhuma das duas em um identificador de transação, resposta de equipamento ou medição de impacto.

O limite também é técnico. O módulo ietf-schedule define identidades, tipos e groupings; por si só não oferece nós graváveis, estado de leitura ou RPCs. Ele não altera uma rota, não provisiona uma capacidade e não gira uma credencial. Quem reutiliza a linguagem comum precisa definir o contexto de sua ação, seus controles e suas consequências de segurança.

O RFC é explícito: não assume a natureza das ações disparadas por agendamentos, e a detecção ou resolução de conflitos de agendamento está fora do escopo. Esse recuo protege a interoperabilidade. Um vocabulário compartilhado não deveria decidir silenciosamente qual serviço vence uma disputa por janela, se uma exceção de emergência pode sobrepor uma regra, ou como se trata uma colisão. Tais decisões pertencem ao lugar que arca com a política e o risco.

Quatro registros para uma mudança que se queira afirmar

Uma organização que pretenda dizer “a mudança programada ocorreu” deve ligar, sem fundi-los, quatro registros. O primeiro registra a definição temporal: regra, versão, exceções, fuso, relação com a fonte de tempo e ocorrência calculada. O segundo registra a decisão local: principal, escopo requerido, política vigente e resultado da autorização. O terceiro é o recibo de execução: ID imutável, alvo, início, fim, resposta, erro e retorno ou compensação. O quarto mede independentemente se o estado prometido de recurso ou serviço de fato apareceu.

Os quatro podem se desalinhar sem que nenhum campo esteja mentindo. Um relógio impreciso calcula a hora errada. O programador fica ativo enquanto o worker de invocação para. Uma política recusa uma chamada pontual. Um dispositivo aceita a solicitação e uma validação posterior impede o estado desejado. O RFC 9922 chama atenção para sincronização de tempo deficiente, recorrências excessivamente frequentes e a ausência de logs detalhados de gatilhos e resultados — fatores que tornam esses desvios difíceis de reconstruir.

RFC 8413 mostra uma separação parecida em outro domínio. O estado planejado de recursos pode auxiliar o cálculo de uma LSP futura, porém a disponibilidade na solicitação é apenas uma expectativa de melhor esforço; a política do operador pode recusar o cálculo, e a instanciação e a sinalização posteriores são passos próprios. Não é uma implementação de RFC 9922. É um lembrete concreto de que previsão, decisão e estado realizado não são sinônimos.

Também não são sinônimos uma sessão de gestão segura e uma ação autorizada. RFC 9922 espera transporte seguro e autenticação mútua para a gestão YANG. O RFC 8341 NACM trata separadamente do acesso a operações, dados, ações e notificações. Uma sessão que pode ler o calendário não recebe daí autoridade para atuar; uma operação permitida não se torna prova de efeito no mundo operacional.

A disciplina de Heng Lu ajuda a não perder a escala: modelo, publicação e status pertencem à camada de representação; o caminho que avalia o tempo, consulta a política no instante da chamada, chega ao alvo com uma identidade de ação e verifica o efeito pertence à realidade que precisa funcionar. Uma camada comum fina é uma força, desde que não seja apresentada como o resultado que outra camada ainda deve produzir.

Fontes