Resumen

  • RFC 8334 separa un registro de lanzamiento de una solicitud de lanzamiento. En el modelo de solicitud, una creación válida puede devolver el resultado EPP 1001, applicationID y pendingCreate aunque el registro aún no haya asignado el dominio.
  • El recibo demuestra aceptación de la operación, no prioridad jurídica, asignación, publicación registral, delegación DNS ni disponibilidad del servicio. Cada conclusión pertenece a otro actor y a otro momento.
  • La trazabilidad exige conservar transacciones, fase, versión de política, estados y mensajes poll ordenados, y el domain:panData final. Después debe leerse por separado el objeto de dominio y cada plano operativo.

Los sistemas adoran los finales breves. «Éxito» cabe en una celda, colorea un icono y permite que otro proceso empiece. Pero un protocolo puede terminar correctamente una orden cuyo efecto de negocio aún está abierto.

La respuesta de ejemplo de RFC 8334 lo dice sin rodeos: Command completed successfully; action pending. El código es 1001. La respuesta incluye la fase y un applicationID. Lo que terminó fue la orden. Lo que sigue pendiente es la acción que decidirá la suerte de la solicitud.

RFC 8334, publicada en marzo de 2018 en la vía de estándares del IETF, tiene tres autores: J. Gould, W. Tan y G. Brown. IANA registra la extensión de fases de lanzamiento con esa RFC como referencia. Gavin Brown es el sujeto de este perfil por su contribución colectiva a una distinción operacional especialmente fértil. No es autor único, operador del registro, árbitro de marcas ni titular de la decisión.

El perfil oficial del IETF conservado el 31 de agosto de 2026 indica que Brown acumula veinticinco años en DNS y nombres de dominio; trabajó veintidós en Team Internet PLC, antes CentralNic, catorce de ellos como CTO, y ahora trabaja en ICANN. Enumera cuatro RFC, incluida RFC 8334, y funciones públicas como la presidencia del trabajo RESTful Provisioning Protocol y la revisión en ARTART. Es contexto fechado, no autoridad transferible.

Solicitud y registro son sustantivos distintos

Un Launch Registration es un registro único realizado durante una fase cuando el servidor aplica el modelo de orden de llegada. Un Launch Application es una intención de registrar: el servidor puede aceptar varias solicitudes para el mismo nombre y seleccionar más tarde una para asignarla.

La palabra «puede» es decisiva. RFC 8334 no afirma que todo lanzamiento admita varias solicitudes. Un servidor puede no soportar ese modelo y debe rechazar la forma correspondiente. La política de cada fase decide si lo usa y cómo elige entre candidatos.

Si la creación de una solicitud es válida, el servidor debe crear el objeto de solicitud, asignar un identificador, marcar el estado RFC 5731 como pendingCreate y devolver el applicationID. El identificador permite seguir una solicitud concreta aun cuando el nombre de dominio sea común a varias.

La operación tuvo efecto real: existe un objeto nuevo y correlacionable. Sin embargo, ese objeto no es todavía el registro estable del dominio. applicationID no es un título sobre el nombre. pendingCreate no es una manera extravagante de decir «ya creado»; conserva que la acción está por resolverse.

Cuando una interfaz etiqueta ambos hechos como domain_created, elimina la gramática que permitiría investigar. El cliente cree que posee el dominio. Finanzas reconoce un activo. DNS recibe una incidencia por falta de delegación. Atención al cliente intenta explicar una espera sin saber qué política la gobierna. Nombrar cada objeto evita ese contagio: solicitud recibida, validación, decisión de asignación, objeto de dominio, publicación, delegación y servicio.

El recibo exacto de 1001

RFC 5730 define EPP y su código 1001: la orden se completó correctamente, con acción pendiente. La respuesta puede repetir el identificador de transacción del cliente y debe aportar el del servidor. Ambos permiten unir los registros de las dos partes.

Para una solicitud de lanzamiento, el recibo debería incluir hora, cliente patrocinador, nombre solicitado, endpoint, transacciones, fase, subfase, forma de creación, política aplicable, resultado, applicationID, estado RFC 5731 y estado de lanzamiento.

Con ello puede afirmarse que ese servidor aceptó y registró esa solicitud bajo ese contexto. No puede afirmarse todavía que el solicitante tenga prioridad de marca; que la validación haya terminado; que el registro haya seleccionado la solicitud; que exista un objeto de dominio final; que RDAP lo publique; que la zona padre lo delegue; ni que haya un servicio accesible.

La diferencia distribuye mandatos. El cliente registrador presenta. Un validador evalúa una prueba cuando corresponde. El registro ejecuta su política. Otro proceso proyecta datos públicos. El operador de zona publica. Los servidores autoritativos responden. El prestador del servicio configura. El éxito de uno no autoriza a hablar en nombre de los demás.

La etiqueta de fase no contiene sus reglas

RFC 8334 define sunrise, landrush, claims, open y custom. La fase debe viajar en la orden. El servidor debería validarla y puede validar una subfase. Las fases pueden solaparse y un atributo permite nombrar subdivisiones o fases personalizadas.

Esa información ubica la operación, pero no reproduce toda la política. Dos registros pueden llamar sunrise a procesos con ventanas, proveedores, precios, documentos y criterios de desempate distintos. Parte de la decisión queda deliberadamente fuera de banda.

Por eso la evidencia necesita la versión de política y su vigencia. Sin ese documento no se sabe qué formulario era válido, qué marca o aviso era obligatorio, si se permitían competidores, qué transiciones cabía saltar o qué fecha cerraba la asignación.

RFC 7848 define objetos de marca y marca firmada utilizados en mecanismos relacionados. RFC 8334 admite, según fase y forma, marcas, objetos firmados, códigos y constancias de aviso. Son pruebas de procedencia. Una marca válida puede satisfacer una condición; no ejecuta la asignación. Un aviso aceptado demuestra una interacción; no crea el dominio.

Tampoco debe invertirse la carga. No toda forma exige todos los objetos. Antes de señalar una ausencia, el auditor debe demostrar qué fase, subfase, forma y política estaban activas. La especificación mínima ofrece interoperabilidad; la decisión local debe quedar fechada y atribuida.

El historial asíncrono es la prueba

Los estados de lanzamiento incluyen pendingValidation, validated, invalid, pendingAllocation, allocated, rejected y custom. Mientras el estado no sea final, una implementación que use estados de lanzamiento mantiene pendingCreate. Algunas transiciones pueden omitirse conforme a la política.

Eso impide evaluar el proceso con una fotografía final. Hay que saber qué decisión ocurrió, cuándo, bajo qué regla y qué mensaje llegó al cliente. Una solicitud puede quedar inválida; otra validarse y esperar; una tercera puede seguir una ruta diferente prevista por la política.

La cola poll de RFC 5730 transporta los cambios asíncronos. Los mensajes tienen ID, se recuperan y se confirman. RFC 8334 recomienda el canal para estados intermedios y exige un mensaje RFC 5731 domain:panData para los finales allocated y rejected.

Una auditoría conserva orden, ID de mensaje, puesta en cola, recepción, confirmación, estado, aplicación y transacciones. El panData de asignación demuestra que esa solicitud fue elegida. El de rechazo demuestra que no produjo ese registro. Una espera larga, una cola vacía para un observador no autorizado o una búsqueda pública sin resultados no sustituyen la decisión final.

Las reglas de confidencialidad refuerzan esa frontera. La propia existencia de una solicitud puede ser confidencial. Las operaciones sin autorización reciben 2201; algunas vistas pueden estar filtradas. «No lo veo» describe permisos y superficie de observación, no necesariamente el estado real.

Un dominio asignado aún atraviesa otras capas

Tras allocated, corresponde leer el objeto de dominio de RFC 5731. Luego empiezan comprobaciones nuevas: publicación del registro o RDAP, inclusión de la delegación en la zona padre, respuesta de los servidores autoritativos y funcionamiento de la aplicación.

Cada desfase apunta a un responsable distinto. Asignación sin objeto de dominio: aprovisionamiento registral. Objeto sin delegación: publicación de zona o configuración. Delegación sin respuesta: operación DNS. DNS correcto sin servicio: aplicación, certificado, red o hosting.

La primacía del código en ejecución no reduce todo al último paquete. Exige leer cada plano según lo que puede probar. EPP da fe de EPP. El registro da fe de su objeto. RDAP muestra su proyección. DNS responde desde una perspectiva y un instante. Una conexión observa el servicio. La integridad está en conservar las uniones y no fabricar una verdad total con el primer recibo.

La cadena que debe sobrevivir

Una investigación debería reconstruir al menos:

  1. transacciones, hora, cliente patrocinador, dominio, endpoint y resultado;
  2. fase, subfase, forma, versión de política y vigencia;
  3. applicationID, pendingCreate, estado inicial y permisos de lectura;
  4. validador, marca, objeto firmado, código o aviso cuando la política los haga pertinentes;
  5. estados y mensajes poll ordenados, con recepción, confirmación, saltos y excepciones;
  6. domain:panData final de asignación o rechazo;
  7. objeto RFC 5731 resultante si hubo asignación;
  8. publicación, RDAP, zona, DNS autoritativo y servicio como observaciones separadas y fechadas;
  9. base de confidencialidad, filtrado, retención y responsable de auditoría.

La cadena no burocratiza el éxito: lo define con precisión. Protege al solicitante, que puede probar la aceptación. Protege al registro, que puede mostrar que aceptar no era asignar. Permite al validador explicar su intervención sin apropiarse de la decisión. Y evita exponer el contenido de las solicitudes solo para demostrar que el sistema funcionó.

El valor de RFC 8334 está en hacer visible el tiempo intermedio. Con applicationID, la espera tiene identidad. Con estados y poll, tiene historia. Con panData, tiene cierre. La buena gobernanza empieza cuando «éxito» deja de borrar esas tres cosas.

Fuentes