Resumo

  • Em 25 de setembro, o IESG abriu a consulta final sobre a revisão 17 do SATP Core, que poderá ser considerada Proposed Standard. Comentários são pedidos até 9 de outubro; não houve aprovação de RFC.
  • A seção 11.5 condiciona o efeito do aborto ao estado da transferência. Depois que a origem transmite commit-final, um aborto posterior não produz o recuo descrito para etapas anteriores.
  • A seção 10.8 exclui recuperação e retomada de sessão da versão corrente do protocolo. Isso não prova que arranjos externos de conciliação sejam inviáveis, mas impede tratá-los como função já especificada.

O problema de interromper uma transferência não começa quando as duas pontas discordam. Começa quando uma delas não sabe se a outra recebeu o último sinal. Essa diferença é central para a leitura do SATP Core, agora em última chamada de comentários no IETF. O documento pretende definir o protocolo entre gateways para ativos digitais e segue o caminho de um possível Proposed Standard. As consultas abertas anteriormente sobre arquitetura e casos de uso buscam status informativo; a reportagem já publicada sobre elas tratou da custódia em registros opacos. O novo ponto é a fronteira de reversão no próprio fluxo de mensagens.

O desenho do SATP coloca uma gateway em cada rede de ativos. A origem bloqueia o ativo e envia uma declaração assinada; a destinatária reconhece o estado e prepara o ativo correspondente sob seu controle. Na fase de compromisso, a destinatária informa que está pronta, a origem extingue o ativo antigo e transmite commit-final, e então a nova representação é atribuída ao beneficiário, com confirmação final. O objetivo é preservar um único estado válido, por meio de canal seguro e compromisso em duas fases. O objetivo não dispensa saber em qual estado concreto cada lado parou.

É nesse ponto que a seção 11.5 se torna decisiva. Antes da confirmação de prontidão, o rascunho descreve meios de liberar o bloqueio na origem ou reverter mudanças locais no destino. Mas também alerta que uma mensagem de aborto pode nunca chegar ao par se a gateway cair. Depois do envio de commit-final, o texto considera o aborto ineficaz. Há uma diferença entre existir uma instrução de parada e ela conseguir desfazer estados já assumidos. Não se trata de relatar uma falha em produção nem de afirmar que qualquer interrupção destrói o ativo; trata-se de ler o limite que o projeto declara.

A seção 10.8 impede outra inferência confortável. Recuperação e retomada da sessão não são suportadas nesta versão do SATP; podem ser assunto de versão futura ou especificação separada. Operadoras podem tentar conciliar registros, consultar um acordo ou recorrer a procedimentos manuais, mas o texto atual não padroniza essa retomada. Uma demonstração no caminho feliz tampouco comprova que uma sessão interrompida dispõe de uma saída segura. É preciso separar o histórico de mensagens enviadas da confirmação de que o outro lado agiu.

Os autores do rascunho enumeram riscos de interrupções, negação de serviço e participantes que atrasem ou omitam mensagens em momentos críticos, inclusive com custos financeiros para uma gateway. São hipóteses de segurança, não notícia de um incidente identificado. A carta do grupo de trabalho reconhece que as redes provavelmente precisarão de acordos legais ou de outra natureza, mas exclui sua implementação do escopo do protocolo. Assinaturas ajudam a atribuir declarações; não resolvem sozinhas disputas sobre perdas.

Até 9 de outubro, a comunidade pode comentar precisamente o que permanece reversível, qual evidência resiste a uma queda e como delimitar uma sessão que não pode ser retomada pelo protocolo. O prazo não aprova um padrão nem uma implantação. Para quem pretende adotar SATP, a pergunta operacional é quem autoriza atravessar o compromisso irreversível e qual plano existe caso a resposta final desapareça.

Fontes