Resumo

  • Publicada em 13 de setembro de 2026, a revisão 03 continua sendo um Internet-Draft individual, não um documento adotado pela REGEXT nem um RFC.
  • O pedido passa a usar uma especificação independente e fixa. Modelo de dados, identificador e formato transmitido permanecem iguais.
  • A lista da IANA consultada não contém reliabilityAssessment. Um pedido descrito no texto não comprova recebimento, revisão ou aprovação.
  • Registrar um significado técnico não equivale a obter consenso sobre o projeto ou autorização para decisões operacionais.

O que muda está na coluna da referência

Antes de implementar uma extensão, é preciso saber qual documento define seu nome. Não é necessário confundir essa necessidade com outra pergunta: a comunidade de padronização endossa o projeto? A revisão 03 de RDAP Extension for Structured Reliability Assessment Metadata separa as duas questões por meio de uma nova organização documental.

A proposta leva avaliações de registradores e nomes de domínio às respostas RDAP. A revisão de 13 de setembro declara que não alterou modelo de dados, identificador da extensão, nome do membro JSON ou formato na rede. A mudança está na seção 13: o texto que fundamenta o registro solicitado para reliabilityAssessment.

A revisão 02 previa esperar um RFC. Agora, os autores explicam que faltava uma referência estável, não que um RFC fosse uma condição universal. Publicaram separadamente bcsec-RDAP-RA Version 1 e usam esse documento no pedido. A exigência de estabilidade não foi dispensada; a proposta afirma ter fornecido o que faltava.

Isso ainda não é um registro concluído. A lista RDAP Extensions da IANA congelada para esta apuração não inclui o identificador. O Datatracker mantém o trabalho como rascunho individual ativo, com estado I-D Exists. O texto de um pedido também não prova que uma solicitação formal tenha chegado à análise.

Publicar fora dos RFCs não elimina a revisão

A política vigente é Specification Required. Pelo RFC 8126, ela exige aprovação de especialista designado e uma especificação permanente, publicamente acessível e suficientemente clara para implementações independentes interoperáveis. Um RFC é uma via ideal, mas publicações externas são expressamente admitidas.

O RFC 7480 criou o registro RDAP e seu formulário. O rascunho de grupo de trabalho RDAP Extensions propõe orientações mais explícitas sobre referências fixas e revisão. Continua sendo um rascunho; citá-lo não o transforma numa regra final que substitui o RFC 7480.

Portanto, analisar um pedido não é apenas reservar um nome. Ao mesmo tempo, cumprir critérios de registro não produz consenso da IETF. A especificação independente preserva explicitamente a liberdade da REGEXT de não adotar o trabalho. Bertoldi Cybersecurity a publica sozinho, reconhecendo o desenho técnico conjunto com Simon Pietro Romano por meio do rascunho individual.

Corrigir o documento passa a exigir outra trajetória

O texto independente promete não editar os bytes canônicos, nem para correções editoriais. Erros iriam para uma errata separada, sem força normativa. Uma correção que afete interoperabilidade exigiria nova especificação em outro URL, preservando a antiga. Há também um espelho declarado, com precedência do endereço canônico em caso de divergência.

São compromissos de manutenção do publicador. Uma recuperação bem-sucedida demonstra disponibilidade naquele momento, não permanência futura. Ainda assim, o arranjo torna visível a diferença entre reconhecer um erro e alterar silenciosamente as regras seguidas por uma implementação.

O apêndice C afirma que o modelo de dados é idêntico, mas enumera diferenças editoriais e procedimentais. Referências a trabalhos inacabados tornam-se informativas ou têm as regras necessárias reescritas. Convites à revisão e questões abertas são retirados ou reformulados. O documento fixo não solicita, por conta própria, registro em RDAP JSON Values; o rascunho individual segue essa via separadamente. Alinhamento técnico não significa intercambialidade para qualquer procedimento.

Se surgir um RFC, o registrante diz que pedirá a atualização da referência do registro. Nem o RFC nem essa atualização estão estabelecidos. Tampouco a atualização migraria automaticamente sistemas já implantados. O formato comum transporta resultados de avaliação, sem escolher método, limiar ou medida de aplicação.

Fontes