Resumen

  • La versión 1 de prop-173 establecería condiciones específicas para consultas ordinarias y las presentaría en WHOIS, RDAP y la web. Sigue publicada para discusión en la lista Policy SIG; no es una política adoptada.
  • El documento tendría número de versión, fecha de entrada en vigor, historial y archivo. Sin embargo, la respuesta solo tendría que enlazar la política actual, sin la versión, fecha efectiva o huella aplicable al resultado concreto.

Separar una consulta de una descarga masiva

La mejor defensa de la propuesta es muy práctica. Una persona que busca un recurso en WHOIS no está solicitando una réplica de la base de datos. Un sistema que resuelve una incidencia mediante RDAP tampoco equivale automáticamente a un recolector. Si ambos reciben como única referencia un acuerdo diseñado para descargas masivas, el límite entre uso normal y reutilización regulada queda borroso.

La página oficial de prop-173 registra que la versión 1 se publicó en la lista de correo del Policy SIG el 17 de agosto de 2026. El estado visible es “Published to Mailing List”. En el expediente revisado no aparece una evaluación de impacto de la Secretaría, un consenso, una decisión de adopción ni un anuncio de implantación. Por eso el artículo describe lo que la propuesta haría, no lo que APNIC ya hace bajo ella.

El texto de la propuesta abarcaría a cualquier persona o sistema que acceda a datos de directorio bajo autoridad de APNIC mediante WHOIS, RDAP, búsquedas web o API equivalentes. Los datos remitidos o reflejados desde otro registro conservarían las condiciones de la fuente autoritativa. Los volúmenes altos, los extractos significativos y las bases sustitutas seguirían por la vía separada de acceso masivo.

El proyecto enumera usos operativos y de investigación técnica que serían permisibles: analizar políticas de encaminamiento, solucionar problemas, coordinar incidentes, mantener datos de registro y estudiar la resiliencia de Internet. Al mismo tiempo prohíbe prácticas como listas comerciales, mercadotecnia directa, cosecha sistemática, evasión de límites y reventa del directorio como producto. También prevé una revisión para quien crea que una restricción fue errónea.

Todo eso dota de forma pública a una frontera que hoy puede resultar difícil de leer. La cuestión nueva no es si las prohibiciones son demasiado amplias ni de quién es cada campo de una respuesta. Es qué ocurre cuando esa frontera cambia mientras una respuesta antigua sigue circulando.

El enlace siempre mira al presente

La sección de avisos de prop-173 llevaría la política hasta el momento de la consulta. WHOIS mostraría que los datos están sujetos a las condiciones y que consultar o usar el servicio implica aceptarlas. RDAP incluiría un aviso que identificase la política, un enlace con relación terms-of-service, una mención de propiedad intelectual y la URL de la política vigente. La interfaz web expondría el mismo vínculo.

La propuesta exige que esa URL sea HTTPS, estable, mantenida y sin redirecciones. Además, el documento central tendría número de versión, fecha efectiva, historial de revisiones y archivo de versiones anteriores. APNIC daría un aviso público razonable de las modificaciones, y ciertos cambios materiales volverían al proceso de consulta comunitaria.

Es una arquitectura defendible. Un único texto mantenido reduce divergencias entre protocolos. El archivo y la fecha de vigencia permiten estudiar la evolución. El aviso previo evita que una modificación importante aparezca sin señal. Mantener las respuestas breves también favorece clientes sencillos.

Pero el enlace estable identifica una ubicación, no una edición. La lista de elementos obligatorios en la respuesta no incluye el número de versión que se aplica, su fecha efectiva ni una huella del contenido. Un JSON guardado antes de una modificación seguirá apuntando después a la URL “actual”, que puede contener ya otras palabras.

Si el usuario preservó una marca temporal fiable y el archivo delimita cada vigencia con precisión, quizá pueda reconstruir la edición. Esa es una defensa importante y debe ir primero. Aun así, la marca temporal pertenece normalmente al cliente o a otra capa de transporte. La respuesta no lleva su propia clave de unión con las condiciones a las que decía someter el uso.

Un canario actual, no una prueba de implantación

La respuesta RDAP para 1.1.1.1 capturada durante el análisis ya contiene un aviso de “Terms and Conditions” con un enlace terms-of-service. También incluye avisos sobre la fuente y sobre cómo comunicar inexactitudes. No contiene una versión de la política, su fecha efectiva o la huella del documento.

Ese ejemplo tiene límites estrictos. No demuestra que prop-173 esté activa, no cubre WHOIS ni la web y no representa necesariamente todos los nodos del servicio. Solo permite observar una forma real: RDAP puede entregar un enlace a condiciones sin entregar la identidad de la edición de esas condiciones.

RFC 9083 explica por qué. Sus avisos describen el servicio o toda la respuesta; la descripción es obligatoria y los enlaces son opcionales. La estructura ofrece espacio para una referencia de términos y también para metadatos de versión, pero el estándar no crea por sí mismo un recibo de política de APNIC. La conformidad técnica y la trazabilidad institucional son controles distintos.

Qué demuestra el acuerdo masivo

El acuerdo de Whois masivo limita la reproducción, el almacenamiento, la transmisión y la entrega en bloque a terceros. Su importancia aquí no está en trasplantar esas cláusulas a cada consulta. Muestra que las reglas de reutilización siguen importando cuando la sesión de consulta ya terminó.

Prop-173 precisamente quiere evitar que el usuario ordinario tenga que adivinar si un contrato de descarga se le aplica. Una referencia de versión preservaría esa claridad en el tiempo. No sería un registro de derechos sobre cada campo, ni probaría la validez jurídica de una cláusula, ni establecería que el usuario la infringió. Solo fijaría el texto que el servicio invocó.

La declaración de privacidad de APNIC sitúa Whois y RDAP dentro de sus prácticas de tratamiento de información de registro y contacto. Precisar la edición de una política no convierte cualquier tratamiento en legítimo. Evita, más modestamente, que una discusión posterior use un documento distinto del que acompañaba al dato.

El proceso todavía puede corregir la unión

El proceso de desarrollo de políticas exige discusión abierta y consenso. Una versión publicada en una lista no es el final de ese proceso. Añadir el identificador de versión a los avisos puede ser una mejora incremental: conserva la política estable, el archivo, las facultades de protección y la revisión, mientras vuelve verificable la relación temporal.

La evidencia tampoco autoriza una acusación. No hay en las fuentes un usuario sancionado conforme a la versión equivocada, una modificación escondida, una consulta rota, una pérdida operativa o una conclusión judicial. APNIC puede mantener registros internos capaces de reconstruir cada despliegue. El hallazgo es documental: prop-173 v001 no exige que la prueba viaje con la respuesta.

Fuentes

Se consultaron la ficha de prop-173, el texto v001, el acuerdo de acceso masivo, la respuesta RDAP capturada, la declaración de privacidad, el proceso de políticas y RFC 9083. Describen el proyecto y un canario de la respuesta, no un caso de aplicación de prop-173.