Resumo

  • O Internet-Draft individual de 28 de outubro acrescenta ao RTR uma assinatura para avisos por evento, remessas periódicas ou os dois modos, com seis novos tipos de pacote.
  • O Push Notify urgente informa tipo de mudança e número de série, mas não contém os objetos modificados. O Periodic Update é que traz a sequência de dados.

Se uma autorização de origem muda, o operador não ganha nada ao saber apenas que o servidor viu a mudança. Ele precisa saber quando o roteador recebeu e aceitou a versão certa. O novo rascunho de push RTR fala em resposta a incidentes críticos dentro de segundos. O desenho dos pacotes separa a sirene da carga.

A sirene atual aparece na RFC 8210: o cache pode mandar Serial Notify sem ser chamado. O roteador pode então emitir Serial Query ou Reset Query imediatamente, sem esperar o temporizador. O rascunho 8210bis vigente mantém o mesmo arranjo. O cache avisa, o roteador escolhe consultar, e a resposta leva anúncios e retiradas. O rótulo “pull” não apaga esse primeiro movimento iniciado pelo cache.

O texto novo propõe que o roteador assine um serviço após a sincronização inicial. Pode pedir notificações por evento, atualizações em intervalos, ambos ou cancelar a assinatura. Seis tipos adicionais de PDU entram no pedido à IANA. Isso dá ao cache uma lista de assinantes para manter e ao operador uma pergunta econômica simples: que redução do atraso compensa esse estado extra?

No modo de evento, Push Notify carrega identificação da assinatura, natureza do aviso e número de série. A proposta cita ROA, ASPA e chaves de roteador, mas o formato desse pacote não carrega os objetos alterados. Também não estabelece a sequência seguinte que os entregaria. A novidade do alerta, portanto, não mostra como o roteador receberia antes uma atualização verificável. Serial Notify já podia disparar uma consulta sem esperar a próxima rodada.

O pacote Periodic Update descreve a remessa: Cache Response, zero ou mais PDUs de dados e End of Data no intervalo aprovado. O cache escreve o número de série que supõe estar no roteador. Se a suposição divergir do estado real, o roteador deve recusar os dados. Esse veto impede que o relógio do remetente se imponha sobre um estado local diferente. Também obriga qualquer medição de rapidez a terminar na aceitação, não na saída do aviso.

O registro do IETF classifica o documento como proposta individual destinada a Standards Track, no estágio I-D Exists. Não há ensaio de implantação nem comparação de latência reproduzível. Uma versão que detalhe a transferência após o evento e meça o mesmo objeto nos dois caminhos mudaria a avaliação. Hoje o aviso de emergência e a entrega efetiva ocupam trilhos diferentes.