Resumen

  • draft-gould-regext-epp-server-validation-00 estructura controles sincrónicos, asíncronos y programados, pero deja el tipo de validación a la política del servidor.
  • success sólo describe la última ejecución. Fecha, operación, transiciones y razones son opcionales.
  • Un recibo debe unir definición, versión, punto de observación, entradas, tiempo, destinatario, mensaje poll, acuse y corrección.

El mecanismo permite incluir controles DNS o DNSSEC en la respuesta de una transformación, pedirlos con info o recibirlos después por poll. También encola un cambio producido por una validación programada. Es una buena forma común para señales que hoy pueden ser propietarias.

La forma no unifica la política. dns y dnssec son ejemplos; el servidor decide el significado. Resolutor, algoritmos, reintentos y datos pueden variar. Dos éxitos escritos igual no necesariamente observaron lo mismo.

Sin reloj, el éxito envejece en silencio

La fecha, el desencadenante, el último éxito, el primer fallo y el último fallo son opcionales. También lo son las razones, que son texto del servidor y pueden llevar idioma. Una ausencia no significa «nunca». Sin fecha no hay frescura; sin transición no hay duración ni recurrencia.

DNS cambia con firmas, delegaciones, cachés y rutas. Por eso el enunciado válido es «la última ejecución registrada del tipo X tuvo éxito». Decir «el dominio está sano» añade cobertura continua y certificación que el esquema no ofrece.

Acusar el poll no corrige la causa

RFC 5730 entrega el primer mensaje de una cola por cliente, con identificador y contador. El cliente confirma recepción y el servidor lo retira. El acuse prueba entrega, no atención humana ni reparación. Una alerta puede ser retirada antes de llegar al equipo correcto.

Hay que separar hora de ejecución, entrada en cola, lectura, acuse y escalado. La visibilidad también cambia según el receptor: el servidor puede reservar los motivos de fallo al cliente patrocinador. Diferentes vistas pueden ser legítimas si queda registrada la política de divulgación.

El borrador abarca creación, renovación, transferencia, actualización, algunas eliminaciones, restauración, operaciones automáticas y acciones personalizadas. No cambia la orden; añade datos a la respuesta. El servidor conserva el control de cuándo y qué valida.

Recibo de estado

El recibo consigna tipo y versión de política, punto de observación, parámetros, entradas y fecha. Añade disparador o programación, historia disponible y ausencias explícitas. Conserva objeto, clase del receptor, identificador poll, tiempos de cola y acuse. Finalmente separa ticket, corrección y nueva validación.

Es una propuesta editorial, no texto del borrador. El documento del 19 de julio de 2026 es individual: Datatracker dice que no tiene respaldo formal, flujo ni estado RFC previsto, aunque la cabecera diga Standards Track. Tampoco prueba implementación.

Fuentes