Resumen

  • El IESG aprobó el 17 de agosto de 2026 draft-ietf-regext-ext-registry-epp-10 para publicarlo como Best Current Practice. La decisión endurece la documentación, la revisión y el mantenimiento del registro de extensiones EPP, no convierte la lista de IANA en una promesa universal de servicio.
  • Active tiene valor probatorio: existe implementación y uso en al menos una pareja registro–registrador o servidor–cliente. La disponibilidad ante un servidor, una cuenta y una operación concretos se prueba después, mediante el saludo, el inicio de sesión y el resultado de la orden.

El error estaba en el salto lógico

La escena inicial es hipotética. No describe un fallo conocido ni atribuye una conducta a un TLD. Su utilidad consiste en separar dos afirmaciones verdaderas que la automatización suele fusionar: «esta extensión está registrada» y «este endpoint la admite ahora».

IANA mantiene un mapa de coordinación. La ficha permite conocer el nombre, la referencia estable, la persona u organización registrante, el alcance TLD declarado, las divulgaciones de propiedad intelectual, el estado y las notas. Sin ese inventario sería más difícil descubrir implementaciones, rastrear responsables y evitar choques de espacios de nombres.

El servidor mantiene la frontera operativa. En el saludo EPP declara versiones, idiomas, objetos y extensiones disponibles. El cliente selecciona servicios al autenticarse. Los privilegios de esa identidad y la política local se aplican a cada orden. El resultado y el estado posterior del objeto ofrecen la evidencia final.

Por eso una ficha correcta puede coexistir con una ausencia en el saludo. Una extensión anunciada puede no estar autorizada para ese cliente. Una sesión negociada puede producir un rechazo legítimo de la operación. No es una inconsistencia del estándar; son preguntas distintas.

La nueva práctica hace más exigible la coordinación

El documento aprobado se titula “Extension Registry for the Extensible Provisioning Protocol”. Hasta que el RFC Editor lo publique seguirá siendo un Internet-Draft. Su destino es sustituir RFC 7451 y elevar el procedimiento de Informational a BCP.

También cambia el lugar de la conversación pública desde la antigua lista eppext a REGEXT. Una solicitud futura ya no puede señalar un Internet-Draft como referencia definitiva y el procedimiento de asignación temprana de RFC 7120 no se considera aplicable. La especificación debe ser estable, estar disponible con facilidad y contar con una versión inglesa enlazada en la ficha, aunque pueda haber versiones adicionales.

La política de registro continúa siendo Specification Required, definida por RFC 8126. IANA somete las peticiones a expertos designados. Estos valoran la arquitectura y si la documentación trata seguridad y privacidad. Deben apartarse ante un conflicto de interés y remitir a la comunidad los desacuerdos que no puedan resolver.

Hay además una obligación expresa sobre XML. Los esquemas, los URI de esquema y los URI de espacio de nombres deben estar bien formados, tener un significado apropiado y quedar registrados conforme a RFC 3688. Los espacios reservados a IETF se reservan para documentos del flujo IETF; una especificación propietaria necesita su propio espacio. El resultado es una ficha más confiable como referencia técnica, aunque siga sin observar el comportamiento de cada instalación.

Active no significa «en todas partes»

El nuevo procedimiento detalla los campos de la ficha: nombre, estado documental, referencia, registrante, TLD, IPR, estado operativo y notas. Una especificación que no es RFC debe utilizar Other como estado documental, evitando hacerla pasar por una RFC Informational.

Las definiciones de estado importan. Active corresponde a una extensión implementada y en uso. Inactive corresponde a una que no está implementada o utilizada, y también puede señalar que la especificación referenciada ha dejado de estar disponible.

La prueba mínima es deliberadamente permisiva. Si existe despliegue en una pareja registro–registrador o servidor–cliente, los expertos no deberían exigir adopción general para admitir la ficha. Esa regla permite que el inventario refleje innovación real antes de que sea masiva. A cambio, obliga al lector a no universalizar el dato.

El campo TLD tampoco es una afirmación de cobertura. Un TLD concreto documenta el ámbito declarado. Any dice que la extensión no está ligada a uno solo y N/A que no trata el procesamiento de nombres de dominio. Ninguna de esas etiquetas impone implementación.

Un panel que comprima todo en «registrada = sí» y «activa = sí» pierde la parte decisiva: quién la usa, dónde se observó y cuándo. Ese contexto debe acompañar la decisión automatizada.

Permitir funciones parecidas preserva la realidad desplegada

EPP se diseñó con un núcleo común reducido y mecanismos de extensión porque cada registro combina políticas, productos y restricciones diferentes. La consecuencia previsible es que aparezcan soluciones distintas para necesidades parecidas. El registro existe también para hacer visible ese solapamiento.

Los expertos pueden pedir que una propuesta todavía no desplegada reconsidere su diseño si ya hay una extensión similar. Pero la similitud, por sí sola, no debe causar el rechazo cuando se cumplen los demás requisitos. Si una solución ya funciona entre un servidor y su cliente, el examen debe reconocer ese hecho.

La decisión es prudente: IANA cataloga; no selecciona un ganador ni declara equivalencia semántica. Dos extensiones asociadas a precios, elegibilidad o nombres internacionalizados pueden diferir en sus datos, reglas y efectos. El cliente necesita el URI exacto del saludo y la referencia exacta de ese URI. Una descripción funcional aproximada no basta para sustituir protocolos.

El saludo abre la cadena de autoridad en vivo

RFC 5730 obliga al servidor a enviar un saludo cuyo menú informa versiones e idiomas, URI de objetos y, de forma opcional, URI de extensiones. El mismo protocolo permite que los privilegios de gestión varíen según el cliente.

En el inicio de sesión, el cliente escoge una versión y un idioma compatibles y nombra los servicios de objetos y extensiones que quiere utilizar. La autenticación correcta conserva identidad y autorización durante la sesión. Es una evidencia más fuerte que el catálogo, pero aún no equivale a aceptar todas las órdenes.

Los códigos de resultado distinguen prohibiciones de política local, dependencias entre objetos, valores semánticamente inválidos para el servidor, servicios sin implementar, violaciones de política de datos y fallos transitorios o terminales. Agruparlos bajo un solo indicador «compatible» elimina la información que permite recuperarse con seguridad.

Una secuencia verificable sería: especificación registrada; estado actual de la ficha; saludo reciente del servidor objetivo; negociación del cliente concreto; forma de orden admitida; transacción exitosa; reconciliación del estado final. Saltarse un peldaño convierte una prueba institucional en una suposición operativa.

Una vista actual no sustituye al historial

El procedimiento contempla insertar, modificar, desactivar y eliminar entradas. Para retirar un registro de consenso IETF se necesita aprobación del IESG. Otras entradas pueden retirarse o desactivarse mediante aprobación del IESG o a petición del registrante, con consulta a los expertos. Cuando el responsable desaparece, un experto puede corregir sus datos.

La ficha puede pasar de Active a Inactive. Si la especificación deja de estar disponible de forma persistente, debe permanecer inactiva hasta recuperar una referencia fiable. Son controles apropiados para que la vista presente no engañe.

Sin embargo, el propio texto señala una carencia: el registro no ofrece historial y una entrada eliminada ya no puede seguirse allí. Las organizaciones que dependan de ella deben conservar observaciones con fecha, copias o huellas de la especificación, saludos, decisiones de negociación y planes de cambio. De otro modo, desaparece la justificación de una integración sin que desaparezca su dependencia.

La frontera institucional queda así mejor definida. IANA y los expertos responden por la coordinación pública. El operador del servidor responde por las capacidades anunciadas y su política. El registrador responde por el uso de sus clientes. La legitimidad aumenta cuando cada afirmación conserva el dueño que puede demostrarla.

Fuentes