Resumen

  • El borrador individual sobre evaluaciones de fiabilidad en RDAP llegó a la revisión 03 el 13 de septiembre de 2026. No es un documento adoptado por REGEXT ni un RFC.
  • Ahora solicita el nombre reliabilityAssessment con una especificación independiente congelada como referencia.
  • La lista de IANA consultada no contiene aún ese identificador; la solicitud publicada no demuestra recepción, revisión ni asignación.
  • Registrar un significado interoperable y aprobar una política de confianza son decisiones distintas.

El nombre necesita un texto, no una presunción

Dos equipos pueden escribir software compatible antes de que una comunidad convierta el diseño en un estándar. Para hacerlo necesitan una referencia inequívoca. No necesitan fingir que el consenso ya se ha producido. La revisión 03 de RDAP Extension for Structured Reliability Assessment Metadata explica cómo intenta resolver esa diferencia.

El proyecto añade a las respuestas RDAP una envoltura para evaluaciones de registradores y dominios. Su nueva versión declara que no cambia el modelo de datos, el identificador, el nombre del miembro JSON ni el formato en la red. Lo que cambia es el documento presentado como fundamento del registro.

La revisión 02 había previsto esperar hasta la publicación de un RFC. La 03 dice que faltaba una referencia estable, no que un RFC fuera la única vía posible. Sus autores han publicado bcsec-RDAP-RA Version 1 y solicitan el registro contra ese texto. Según su explicación, la condición se cumple mediante una nueva publicación; no se dispensa.

No debe confundirse la iniciativa con su resolución. El registro IANA examinado para esta noticia sigue sin incluir reliabilityAssessment. Escribir una solicitud en una especificación tampoco acredita que el expediente haya sido entregado o aprobado. El estado oficial continúa siendo el de un Internet-Draft individual activo, I-D Exists.

Un cauce de registro que no exige consenso previo

La política vigente es Specification Required. RFC 8126 exige revisión y aprobación de un experto designado, además de una especificación pública duradera, clara y técnicamente suficiente para implementaciones interoperables independientes. Considera ideal un RFC, pero admite expresamente documentación publicada fuera de esa ruta.

RFC 7480 establece el registro de extensiones RDAP y su plantilla. El borrador de grupo RDAP Extensions propone precisar la estabilidad de las referencias y el examen de solicitudes. Sus reglas siguen siendo trabajo en curso; citarlo no las convierte en una sustitución definitiva del RFC.

Por tanto, el registro no es una reserva automática de nombres. Pero la eventual aprobación de sus expertos tampoco equivaldría a adopción por REGEXT. La publicación independiente lo afirma de forma explícita: no declara consenso y deja al grupo la opción de no adoptar el proyecto. Bertoldi Cybersecurity la publica en solitario y atribuye el diseño técnico conjunto con Simon Pietro Romano al borrador individual.

Corregir sin mover la referencia bajo los pies

El texto independiente promete mantener fijos los bytes de su URL canónica, incluso ante una errata editorial. Los errores se anunciarían en un documento separado, sin efecto normativo. Una corrección que afecte a la interoperabilidad daría lugar a una especificación nueva, en otra dirección, mientras la anterior seguiría disponible. Se ofrece un espejo; si discrepa, manda la dirección canónica.

La descarga realizada acredita disponibilidad actual, no permanencia futura. El compromiso sí establece una frontera útil: informar de un error no es lo mismo que modificar silenciosamente aquello que dos implementaciones tomaron como contrato.

El apéndice C declara idéntico modelo de datos respecto al borrador, aunque enumera diferencias de publicación. Las referencias a borradores pasan a ser informativas o se reformulan los requisitos pertinentes; se retiran o reescriben las invitaciones a revisión. La especificación independiente no solicita un nuevo tipo en RDAP JSON Values. El Internet-Draft sí persigue ese registro por separado.

Si finalmente aparece un RFC, el solicitante prevé pedir que la referencia del registro apunte a él. Será otra decisión que habrá que observar, no una actualización automática del software instalado. Tampoco convertirá la envoltura en una metodología de puntuación, un umbral de actuación o una garantía sobre los evaluados.

Fuentes