Un esquema de eventos versionado para comparar decisiones de los RIR

Resumen

• Los informes existentes de los RIR, ICANN e IANA contienen evidencia sustancial, pero los totales de apariencia idéntica pueden referirse a diferentes puntos de inicio, estados de finalización, roles de actores y poblaciones elegibles.
• La unidad de comparación debería ser un evento de decisión gobernado con un identificador opaco estable, un espacio de nombres de institución, una clase de evento, una versión de política, una secuencia de estados de ciclo de vida y enlaces explícitos a revisión, corrección o revocación.
• El tiempo de decisión debe separar la recepción, la integridad documental, la revisión sustantiva, la decisión, la notificación y la implementación autoritativa; la revisión debe tener sus propias marcas de tiempo de presentación, aceptación, medida cautelar, resultado y reparación.
• Los campos de actores deben describir los roles institucionales en el momento de la acción: solicitante, verificador, recomendador, tomador de decisiones, implementador y revisor, sin publicar identidades de personas naturales innecesarias ni confundir un rol con autoridad.
• Los campos de eventos públicos y la evidencia protegida deben estar separados. Un registro público puede exponer el estado, la clase de motivo, el tiempo y la procedencia, mientras que los documentos de identidad, el asesoramiento legal, las credenciales y el material de seguridad permanecen controlados y auditables.
• Cada evento debe llevar la versión del esquema y la versión del vocabulario bajo la cual fue emitido. Los cambios importantes requieren migraciones gobernadas, reexpresiones paralelas y versiones anteriores preservadas en lugar de reescrituras silenciosas.
• La custodia del esquema debe pertenecer a un organismo de estándares independiente y multipartito con registros de cambios abiertos, vectores de prueba públicos, divulgaciones de conflictos y participación equilibrada; debe definir la semántica de los datos, no decidir la política de los RIR o casos individuales.
• Number Resource Society puede abogar por un esquema abierto, reunir a titulares e investigadores, y publicar comparaciones basadas en fuentes. No puede asignar identificadores de eventos, mantener registros autoritativos, certificar conformidad, adjudicar decisiones u operar la autoridad del esquema.

La comparación falla en el límite de la decisión

ElInforme Anual de RIPE NCC 2025, elInforme Anual de ARIN 2025,el archivo de informes anuales de APNICy elinforme anual FY25 de ICANNmuestran que las instituciones de recursos numéricos ya divulgan información operativa, financiera y de gobernanza sustancial. Losinformes mensuales de rendimiento de recursos numéricos de IANAvan más allá en un dominio estrecho al nombrar etapas y objetivos para las solicitudes entre IANA y los RIR. El problema no es una ausencia completa de divulgación.

El fallo de comparación aparece cuando un lector pregunta si dos valores publicados describen el mismo acto institucional. Una transferencia puede contarse cuando se presenta, cuando se considera completa, cuando se aprueba o cuando cambia el registro autoritativo. Una corrección puede contarse cuando se cierra un ticket, aunque un directorio público, una delegación inversa o un objeto de seguridad de ruta sigan desactualizados. Una revisión puede contarse como presentada, aceptada, decidida o implementada. Un total anual generalmente no tiene suficiente estructura para recuperar esas distinciones.

Por eso otro portal de evidencia integral no resolvería el problema central. Un portal puede recopilar cifras incompatibles y hacer que parezcan más ordenadas sin hacerlas más comparables. Una larga lista de indicadores de gobernanza también puede convertirse en un marcador cuya ponderación oculta elecciones sustantivas. La capa faltante es más pequeña y más exigente: una representación común del evento a partir del cual se calculan los totales posteriores.

El esquema de eventos no debe intentar almacenar todo lo que una institución sabe. Debe hacer una declaración acotada sobre decisiones consecuentes. Identifica el ciclo de vida institucional, la fuente de autoridad, los roles de los actores, el tiempo, el resultado, la revisión y el historial de publicación necesarios para reconstruir una comparación. Las finanzas, la concentración, la membresía y los indicadores de servicio técnico pueden tener estándares separados. No deben verterse en este modelo de eventos simplemente porque un conjunto de datos único suene conveniente.

El alcance son las decisiones, no un almacén de evidencia

Un evento de decisión comienza cuando una institución recibe o inicia un asunto que puede cambiar los derechos, el estado registrado, el acceso al servicio, el registro de recursos o el estado de seguridad de ruta de una persona u organización. También incluye decisiones de gobernanza que cambian las reglas bajo las cuales se manejan esos asuntos. El esquema común puede cubrir solicitudes de asignación y asignación, transferencias, correcciones de registro, acciones adversas en cuentas, cambios de RPKI iniciados por el registro, decisiones de membresía, revisiones formales y decisiones de política.

Cada clase utiliza un envoltorio compartido y un perfil específico de clase.

El esquema no absorbe archivos de casos en bruto. No se convierte en el registro canónico, reemplaza RDAP o WHOIS, emite un certificado, registra la propiedad beneficiaria como un hecho, decide el título legal o conserva cada mensaje intercambiado con el personal. Esas funciones pertenecen a la institución y los sistemas legales responsables de la decisión. El esquema público expone lo suficiente para probar el proceso y el resultado mientras se refiere a la evidencia protegida a través de identificadores controlados.

El alcance debe ser exigible a nivel de campo. Un campo pertenece solo cuando ayuda a responder una de cinco preguntas: qué asunto entró en el proceso, bajo qué regla, qué rol institucional actuó, cuándo cambió el estado y cómo se revisó o corrigió el resultado. Un campo solicitado que no pueda vincularse a una de esas preguntas debe rechazarse o colocarse en un estándar de dominio separado. Esta disciplina evita que un esquema de decisión se expanda a un expediente institucional indiscriminado.

Los perfiles de clase deben permanecer estrechos. Un perfil de transferencia necesita clases de relación de origen y destinatario, familia de recursos, banda de tamaño, enlace interregional, resultado de verificación de autoridad y estado de implementación. Un perfil de corrección necesita superficie pública afectada, clase de defecto, tiempo de confirmación, reparación autoritativa y estado de propagación. Un perfil de revisión necesita evento impugnado, clase de legitimidad, presentación, aceptación, protección provisional, resultado e implementación de la reparación. Los nombres compartidos deben significar lo mismo en cada perfil.

Un evento necesita una identidad durable

Cada evento gobernado requiere un identificador estable que sobreviva a la reasignación de personal, la migración del sistema de casos, la presentación de informes anuales y la corrección posterior. Sin él, no se puede vincular de manera confiable una revisión con la decisión que impugna, una versión modificada puede contar dos veces un caso, y dos RIR pueden publicar las dos etapas de una transferencia interregional como transacciones no relacionadas.

El identificador debe ser opaco. No debe codificar un nombre de titular, rango de recursos, país, resultado, clase de riesgo o fecha de presentación. Codificar esos hechos hace que el identificador sea frágil cuando cambia una clasificación y puede exponer información protegida. Una forma práctica combina un espacio de nombres de institución registrado con un valor local resistente a colisiones. El valor público permanece estable; la institución responsable conserva el mapeo protegido de su identificador de caso interno.

La estabilidad no significa que cada acción relacionada comparta un ID. El modelo necesita relaciones explícitas. Un evento de revisión tiene su propio ID y un enlacereviews_event_ida la decisión impugnada. Una corrección tiene su propio ID y un enlacecorrects_event_id. Una revocación se vincula tanto a la revisión como a la decisión original cuando corresponda. Una transacción interregional puede tener un ID de correlación derivado conjuntamente mientras cada RIR conserva su propio evento de decisión local. El tipo de relación lleva un significado que la similitud de cadenas no puede.

Los ID nunca deben reciclarse. Una solicitud retirada, una solicitud rechazada o un evento creado por error aún ocupan su identificador. Si la institución determina que dos ID representaban un mismo asunto, publica una relación de fusión y conserva ambos historiales. Si un asunto se divide en partes separadamente decidibles, publica relaciones de división. La eliminación silenciosa haría imposible reproducir denominadores posteriores.

El organismo de esquema independiente debe mantener los espacios de nombres de institución y la sintaxis de identificadores, pero no debe emitir ID de eventos operativos. Cada RIR asigna sus propios ID bajo la sintaxis compartida y sigue siendo responsable de la unicidad. Para una correlación entre RIR, los registros participantes generan o acuerdan el valor compartido a través de un protocolo documentado. Ni un grupo de defensa ni la secretaría de estándares se convierte en un registrador de transacciones.

El estado del evento es una secuencia, no una etiqueta de estado

Un único estado actual oculta el camino que lo produjo. "Completado" puede significar que el personal aprobó una solicitud, que un registro autoritativo cambió, que se notificó al titular o que todas las superficies técnicas dependientes se reconciliaron. El esquema debe representar una secuencia ordenada de transiciones de estado mientras mantiene un estado actual compacto para uso ordinario.

El ciclo de vida compartido comienza conreceived. Puede pasar aacknowledged,awaiting_completeness,complete_for_review,under_substantive_review,decision_recorded,implementation_pending,implemented,notifiedyclosed. Los perfiles de clase pueden declarar estados no aplicables, pero no pueden omitirlos en silencio. Una solicitud rechazada aún tiene un estado de decisión y notificación. Una solicitud retirada registra quién la retiró y en qué etapa. Una transferencia que fue aprobada pero no implementada permanece visiblemente incompleta.

Las transiciones necesitan clases de motivo. Un caso puede esperar evidencia del solicitante, confirmación de la contraparte, otro registro, un tribunal, análisis de sanciones, recuperación de seguridad o acción interna. La clase de motivo no asigna culpa automáticamente. Identifica la dependencia para que se puedan calcular tanto el tiempo transcurrido bruto como el tiempo controlado por la institución. Cada pausa tiene un inicio, fin, rol iniciador y base de política; una pausa abierta no puede desaparecer al final del año.

La máquina de estados debe rechazar transiciones imposibles a menos que un registro de excepción las explique. Un evento no puede implementarse antes de una decisión. Una revisión final no puede preceder a su presentación. El cierre antes de la notificación requiere un motivo específico de clase. La reapertura crea una transición de cerrado a reabierto con un rol y base, no un nuevo evento que se hace pasar por un caso no relacionado. Las reglas de validación detectan estos errores antes de la publicación.

El estado actual sigue siendo útil, pero se deriva. La secuencia autoritativa es el conjunto de solo agregar de transiciones y correcciones. Una versión puede publicar el último estado para consultas convenientes mientras preserva las transiciones anteriores necesarias para calcular la duración, la reapertura y la revocación. Esa distinción es esencial cuando un panel y una auditoría deben reproducir el mismo resultado.

El tiempo necesita varios relojes y una regla de precisión

La comparación de decisiones es imposible si las instituciones inician y detienen el reloj de manera diferente. El envoltorio común debe requerirreceived_at,recorded_atylast_revised_at. Los perfiles de decisión luego agregancomplete_at,substantive_review_started_at,decision_at,notification_at,implementation_atyclosure_atsegún corresponda. Los perfiles de revisión agreganreview_filed_at,review_accepted_at,interim_relief_at,review_decision_atyremedy_implemented_at.

Estas marcas de tiempo responden a diferentes preguntas. Recepción mide cuándo la institución obtuvo el asunto a través de un canal reconocido. Registro mide cuándo el evento entró en el sistema de casos. Integridad mide cuándo el material requerido estaba presente bajo la política entonces vigente. Decisión mide cuándo el tomador de decisiones autorizado fijó el resultado. Implementación mide cuándo cambió el sistema autoritativo. Notificación mide cuándo se envió el resultado a la parte afectada. El cierre es administrativo y nunca debe sustituir a la implementación.

Cada marca de tiempo debe usar UTC con una precisión explícita. Si un registro antiguo solo admite una fecha, el valor debe etiquetarse como precisión de día en lugar de convertirse a medianoche y tratarse como exacto. Los tiempos estimados requieren un método de estimación. Un valor faltante permanece faltante con un código de motivo; no se iguala al hito disponible más cercano. Estas reglas evitan la falsa precisión en la reexpresión histórica.

El esquema también distingue el tiempo del evento del tiempo de publicación. Una decisión tomada el lunes y publicada por primera vez el viernes tiene dos hechos que vale la pena preservar. Una corrección posterior no cambia la marca de tiempo original de la decisión; crea un evento de corrección y una nueva revisión de publicación. Los analistas pueden medir la latencia de decisión, la latencia de implementación, la latencia de notificación y la latencia de divulgación sin confundirlas.

Las duraciones de calendario y de negocio deberían ser ambas derivables, pero la versión debe privilegiar el tiempo de calendario bruto como base universal. Los calendarios de negocio difieren por región y año. Cada institución puede publicar su identificador de calendario, días festivos y supuestos de horas de servicio para que una transformación gobernada produzca tiempo de negocio local. Publicar solo días hábiles ocultaría las diferencias en el manejo de fines de semana, días festivos y emergencias.

Los campos de actores deben registrar roles, no biografías

La pregunta decisiva de rendición de cuentas rara vez es la identidad pública de la persona natural. Es si un rol autorizado actuó, si los deberes estaban separados y si la autoridad existía en ese momento. Por lo tanto, el esquema debe modelar los roles de los actores independientemente de los nombres.

El vocabulario común de roles incluye solicitante, titular afectado, oficial de admisión, verificador de evidencia, revisor sustantivo, recomendador, tomador de decisiones, implementador, notificador, revisor independiente, autoridad externa y observador de auditoría. Un perfil puede agregar un rol solo a través de una extensión versionada. No puede usar un título de texto libre para ocultar que una persona realizó varias funciones supuestamente independientes.

Un registro de rol-actor necesita un ID de evento, código de rol, unidad institucional, referencia de fuente de autoridad, estado de delegación, hora de inicio y fin, y una clave de actor protegida. La versión pública normalmente expone el código de rol, la institución y si se cumplieron los requisitos de separación. La capa protegida retiene la identidad de la persona natural o del servicio, la evidencia de credenciales y la cadena de delegación para un auditor autorizado o un organismo de revisión.

El rol y la autoridad no son intercambiables. Un campo etiquetado comodecision_makerregistra quién realizó la función de decisión; un campo separado identifica la política, delegación o autoridad legal utilizada. Un miembro de la junta no posee autoridad sobre cada caso simplemente por su cargo. Un servicio automatizado puede implementar una acción aprobada, pero no puede describirse como el tomador de decisiones sustantivo a menos que la política de la institución realmente asigne esa función y el esquema registre la ruta de rendición de cuentas humana.

Los conflictos deben estructurarse. El evento puede indicar si se requirió, realizó, divulgó y resolvió una verificación de conflictos, junto con la clase de resolución. No necesita publicar los intereses privados de una persona. Una auditoría posterior puede probar la evidencia protegida. Este enfoque apoya la comparación de controles sin convertir la versión pública en una base de datos de personal.

La proveniencia de la política pertenece dentro del evento

Una decisión no puede interpretarse sin la regla vigente cuando se tomó. Vincular solo a una página de política actual es inadecuado porque las páginas cambian y las URL pueden permanecer constantes. Cada evento debe llevar un identificador del instrumento de política, versión, fecha de vigencia y un resumen inmutable o referencia de archivo. El perfil también registra la versión del procedimiento y la versión del vocabulario de códigos de motivo.

La referencia de autoridad debe ser lo suficientemente específica para distinguir la política de la guía de implementación. Una aprobación de transferencia puede citar la política de transferencia y un procedimiento del personal. Una acción adversa puede citar un término contractual, una regla de política o una orden legal externa. Una decisión de gobernanza puede citar estatutos, un procedimiento de consulta y la decisión registrada. El esquema no decide si esas autoridades eran legales; preserva en lo que la institución confió para que la revisión pueda probar la afirmación.

Los códigos de motivo deben ser estables y acotados. "Administrativo" u "otro" no pueden convertirse en un contenedor universal. Un rechazo puede referirse a elegibilidad, evidencia, autoridad, incompatibilidad de política, disputa no resuelta, restricción de sanciones o retiro. Un resultado de revisión puede confirmar, variar, revocar, remitir, desestimar por falta de legitimación, desestimar por extemporáneo o terminar por retiro. El texto libre puede permanecer en el registro protegido, mientras que el código público apoya la comparación agregada.

Cuando una política cambia durante un caso pendiente, el evento debe identificar la regla de transición. ¿Continuó la política anterior, se aplicó la nueva política, o la institución hizo una determinación específica del caso? Ese hecho es analíticamente importante porque un backlog procesado bajo reglas cambiantes puede parecer un cambio en el rendimiento o los resultados.

La revisión debe estar vinculada a la decisión y a la reparación

Las estadísticas de apelación son débiles cuando no pueden unirse a la decisión subyacente. El esquema de eventos debe hacer de la revisión un evento vinculado de primera clase. Registra el ID del evento impugnado, la vía de revisión, la clase de legitimidad, la hora de presentación, la aceptación o rechazo para revisión, la protección provisional, el rol de revisión, el resultado, las razones, la reparación y la implementación.

Esta separación evita varias distorsiones. Una queja no es automáticamente una revisión aceptada. Una decisión de revisión no es una reparación hasta que el registro la implemente. Un caso remitido vuelve a una etapa de decisión y debe permanecer vinculado. Una orden judicial puede ser un evento de autoridad externa que causa un evento de implementación del registro; el esquema no debe representar al registro como el tribunal ni al tribunal como el registro.

El registro público puede publicar clases de razón y resultado sin exponer presentaciones legales. Puede mostrar que una decisión de transferencia fue revocada porque la prueba de autoridad original falló, o que una revisión fue desestimada por falta de legitimación, mientras que la capa protegida retiene los documentos. Donde incluso la clase de razón identificaría a una persona en una cohorte pequeña, la publicación puede retrasarse o agregarse, pero la verificación de conformidad confidencial aún lo incluye.

La medida cautelar merece una marca de tiempo y un alcance. Una revisión puede estar formalmente disponible pero ser prácticamente inútil si ocurre un cambio irreversible primero. El esquema registra si se solicitó la medida, quién la decidió, qué acción se suspendió, cuándo comenzó la protección y cuándo terminó. No prescribe que cada revisión reciba medida; hace visible la regla y la acción de la institución.

Las reparaciones deben usar un vocabulario controlado: corregir registro, restaurar acceso, repetir decisión, levantar suspensión, reemitir credencial, publicar corrección, reembolsar tarifa, notificar servicio dependiente, preservar evidencia o ninguna acción adicional. Una reparación puede contener varios componentes, cada uno con una fecha de vencimiento y estado de implementación. Cerrar la revisión antes de que esos componentes estén completos debe seguir siendo detectable.

La corrección debe añadir, no sobrescribir

Un esquema de eventos contendrá errores. Un sistema fuente puede exportar la marca de tiempo incorrecta, un motivo puede estar mal codificado, una clasificación protegida/pública puede fallar o una institución puede aprender más tarde que dos eventos estaban vinculados. La confianza depende de la corrección sin borrado histórico.

Cada versión pública debe ser inmutable. Un evento corregido aparece en una versión posterior con el mismo ID de evento, una revisión de evento más alta, un motivo de corrección, lista de campos cambiados, rol responsable, hora de corrección y enlace a la revisión anterior. La versión anterior permanece disponible. Los consumidores pueden elegir la última revisión válida mientras que las auditorías pueden reproducir lo que se conocía anteriormente.

Las correcciones a la representación del esquema son distintas de las correcciones a la decisión institucional subyacente. Si una decisión ocurrió en una fecha pero la exportación usó la fecha incorrecta, una revisión del evento repara los datos. Si la institución cambia la decisión después de la revisión, un evento de revocación vinculado o un evento de decisión de reemplazo registra el acto institucional. Tratar esto último como una corrección de datos borraría la rendición de cuentas.

La eliminación debe ser excepcional. Un campo público que contiene accidentalmente datos personales protegidos puede necesitar una eliminación rápida del archivo activo, pero el catálogo de versiones debe preservar una tumba que identifique el evento afectado y la razón sin reproducir los datos. La evidencia protegida del incidente permanece disponible para los investigadores autorizados. La vergüenza ordinaria, la reclasificación o un resultado mejorado no son una razón de eliminación.

Los campos públicos y protegidos forman dos capas coordinadas

El esquema necesita un perfil público y un perfil de evidencia protegida. El perfil público apoya la comparación: ID de evento opaco, institución, clase, estados del ciclo de vida, categorías de roles, referencias de políticas, marcas de tiempo, resultado, enlaces de revisión, historial de correcciones, revisión de publicación y limitaciones. El perfil protegido apoya la verificación: mapeo de casos internos, identidades, referencias de evidencia, material legal, detalle de seguridad, recursos exactos donde la publicación expondría a una parte y anotaciones del auditor.

Las dos capas deben compartir identificadores y controles de integridad. Un auditor debe poder confirmar que cada evento protegido elegible tiene una representación pública o una razón de supresión válida. Los agregados públicos deben reconciliarse con los recuentos protegidos. Una fila pública puede llevar un compromiso con evidencia protegida sin usar un hash predecible de datos personales. El diseño criptográfico debe ser revisado de forma independiente en lugar de improvisado por cada institución.

Las reglas de privacidad pertenecen al esquema, no a un script de publicación no documentado. Cada campo debe tener una clasificación, propósito, audiencia permitida, clase de retención, regla de agregación y fecha de revisión. Los perfiles de evento deben especificar tamaños mínimos de celda y riesgos de vinculación. Un ID de evento que es inofensivo en una tabla puede volverse identificativo cuando se une a una acción judicial rara o a una cohorte regional pequeña.

Por lo tanto, los ID estables no requieren una capacidad de unión pública ilimitada. La capa protegida retiene el ID de evento canónico. Las versiones públicas pueden usar seudónimos con alcance para perfiles particularmente sensibles, con un cruce protegido auditado por integridad. Un enlace de revisión necesario para la rendición de cuentas puede permanecer público donde sea seguro; un enlace a través de dominios de sanciones, disputas e identidad puede requerir acceso controlado. La regla de publicación debe ser explícita y versionada.

La auditoría independiente es esencial porque el público no puede verificar eventos omitidos inspeccionando solo las filas públicas. Los auditores necesitan acceso a las reglas de elegibilidad, sistemas fuente, registros de supresión y el cruce protegido. Su declaración de aseguramiento debe identificar el período, las clases de evento, las pruebas, las exclusiones y las discrepancias no resueltas. No debe afirmar que cada decisión subyacente fue sustancialmente correcta simplemente porque la exportación se reconcilió.

Las versiones del esquema deben viajar con cada evento

Un esquema que cambia sin disciplina de versiones fabricará tendencias. Un campo puede renombrarse, un estado dividirse en dos, una regla de elegibilidad estrecharse o un código de motivo retirarse. Si los eventos antiguos y nuevos se combinan sin preservar el cambio, la mejora aparente puede ser simplemente una nueva definición.

Cada evento debe llevar al menos cuatro versiones: versión del envoltorio del esquema, versión del perfil de clase, versión del vocabulario y versión de la política fuente. El catálogo de versiones lleva la versión del formato de publicación. Estos valores no son redundantes. Un perfil puede agregar un campo específico de transferencia sin cambiar el envoltorio común; un vocabulario puede aclarar un código de motivo sin reestructurar el registro; una política puede cambiar mientras el esquema técnico permanece estable.

Las versiones mayores cambian el significado o la compatibilidad. Las versiones menores agregan capacidad opcional compatible hacia atrás. Las versiones de parche corrigen errores de especificación sin cambiar la semántica prevista. El organismo de estándares independiente debe publicar una clasificación de cambios con cada versión y proporcionar ejemplos de cómo se comportan los registros antiguos. Las instituciones no deben elegir una etiqueta de versión más baja simplemente para evitar deberes de migración.

La desaprobación necesita un cronograma. Un campo primero se desaconseja con un reemplazo y una regla de mapeo. Permanece válido por un período definido. La eliminación ocurre solo en una versión mayor. Los consumidores reciben notificaciones legibles por máquina, mientras que los registros históricos continúan identificando la versión que los gobernó. Un analizador sintáctico posterior nunca debe adivinar que un campo antiguo significa lo mismo que uno nuevo.

Las extensiones son necesarias porque los procedimientos regionales difieren. Una extensión usa un espacio de nombres registrado, declara su propósito e indica si afecta la elegibilidad, el estado o el resultado. El informe de conformidad principal enumera las extensiones utilizadas. Una extensión regional no puede redefinir un campo principal mientras conserva su nombre. Si una diferencia es lo suficientemente importante como para cambiar el significado principal, pertenece al proceso de cambio de estándares.

La migración es una transformación gobernada

La comparación histórica requiere reexpresar eventos antiguos en versiones más nuevas, pero la migración puede inventar precisión que la fuente nunca contuvo. Una transformación gobernada debe preservar el evento fuente, el código de transformación, la versión del mapeo, el tiempo de ejecución, el operador y el resultado de la validación. Crea una representación derivada; no reescribe la evidencia original.

Cada campo mapeado necesita una clase de proveniencia. Directo significa que la fuente contenía la misma proposición. Derivado significa que una regla determinista lo calculó. Inferido significa que la evidencia apoyaba una conclusión acotada pero no el campo exacto. Desconocido significa que el registro histórico no apoyaba el valor. No aplicable significa que la clase de evento no lo requería. Estas clases evitan que un espacio en blanco se convierta en cero y que una fecha aproximada se convierta en una marca de tiempo exacta.

Las migraciones importantes deben publicar una tabla de concordancia. Identifica campos preservados, renombrados, divididos, combinados, retirados y recién no disponibles. Un conjunto representativo de eventos históricos se convierte en un corpus de prueba público con datos sintéticos o redactados de forma segura. Implementadores independientes ejecutan la transformación y comparan resultados antes de que se acepte la versión.

La reexpresión paralela es necesaria cuando un cambio semántico afecta las tendencias. Durante al menos un período de transición, las instituciones deben publicar resultados bajo ambas versiones, antigua y nueva, donde los datos fuente lo permitan. La diferencia cuantifica el efecto del cambio de definición. Si la reexpresión es imposible, la versión marca la ruptura en lugar de dibujar una línea continua.

La migración también se aplica cuando un RIR cambia de sistemas de casos. El ID de evento estable y el historial del ciclo de vida deben sobrevivir. Los identificadores del sistema fuente pueden cambiar, pero el mapeo protegido registra la transición. Los recuentos antes y después de la migración deben reconciliarse, incluidos los eventos retirados, reabiertos y suprimidos. Una copia de base de datos exitosa no es suficiente si las relaciones de decisión o las marcas de tiempo pierden significado.

Los eventos interregionales necesitan correlación sin custodia central

Una transferencia interregional ilustra por qué las relaciones de eventos importan. Dos RIR pueden tomar decisiones distintas bajo diferentes políticas, sin embargo, la transacción tiene un alcance de recursos compartido y no puede estar globalmente completa mientras sus estados autoritativos discrepen. Un esquema común debe representar tanto la autonomía local como el resultado vinculado.

Cada RIR publica su propio ID de evento, proveniencia de política, ciclo de vida, roles de actores y resultado. El par también lleva un ID de correlación, un resumen del conjunto de recursos o una banda de tamaño segura, e hitos de traspaso acordados. Una institución puede alcanzar la aprobación local antes que la otra. El esquema preserva esa diferencia en lugar de colapsarla en una decisión centralizada.

El protocolo de correlación debe definir quién genera el valor compartido, cómo ambas partes lo confirman y cómo se corrige un enlace erróneo. No debe requerir que un tercero tenga el archivo de transacción subyacente. El organismo de estándares independiente mantiene el protocolo y los vectores de prueba. Los RIR participantes siguen siendo custodios de los registros operativos y son los únicos organismos que implementan sus respectivas decisiones.

Las solicitudes de numeración dirigidas a IANA pueden usar el mismo principio. La disciplina de rendimiento publicada de IANA muestra etapas definidas de acuse de recibo, respuesta e implementación en un límite institucional particular. Un evento RIR vinculado puede referirse a la solicitud de IANA sin afirmar que cada decisión RIR orientada al titular comparte la misma política o objetivo de servicio.

La correlación también es útil para la revisión y corrección entre instituciones. Si un RIR cambia su parte después de una revisión, el socio puede publicar un evento de reconciliación vinculado. El registro muestra qué institución actuó, bajo qué autoridad y cuándo el estado compartido se volvió consistente. No inventa un tribunal global.

El organismo de estándares debe gobernar la semántica, no los resultados

Ningún RIR individual debe controlar el vocabulario de comparación para sus pares. Tampoco un grupo de defensa, auditor, proveedor o institución de investigación debe convertirse en el regulador oculto al poseer el esquema. La custodia debe recaer en un organismo de estándares independiente y multipartito cuyo mandato se limite a la semántica, la interoperabilidad, las reglas de privacidad y los métodos de conformidad.

Sus circunscripciones gobernantes deben incluir a las cinco comunidades de RIR, los servicios de numeración de IANA, los operadores de red, los titulares de recursos, los investigadores técnicos independientes, los especialistas en privacidad y los auditores. La participación necesita afiliaciones y conflictos publicados. Ninguna circunscripción debería poder debilitar un denominador, eliminar un estado o redefinir un resultado únicamente para mejorar su propio rendimiento aparente.

El organismo debe publicar propuestas, historiales de problemas, actas de reuniones, borradores de texto, informes de implementación y disposiciones registradas. Los cambios importantes requieren un período de comentario público, análisis de impacto, revisión de privacidad, plan de migración y al menos dos implementaciones independientes. Las correcciones de seguridad de emergencia pueden usar un proceso acelerado, pero caducan a menos que se ratifiquen a través de la ruta ordinaria.

Una secretaría técnica puede mantener especificaciones, registros de espacios de nombres, ejemplos y herramientas de validación. No puede asignar ID de eventos operativos, inspeccionar casos RIR protegidos como cuestión de rutina, decidir si un solicitante debe recibir recursos, anular una decisión de registro o certificar una política como legítima. Los auditores independientes realizan aseguramiento específico de la institución bajo criterios publicados; el organismo de estándares mantiene los criterios y reconoce los informes que cumplen con el formato, no la decisión sustantiva.

La financiación debe ser diversificada y divulgada. Un esquema mantenido enteramente por las instituciones que se comparan corre el riesgo de definiciones defensivas. Un organismo financiado por un gran usuario comercial corre el riesgo de campos optimizados para el mercado de ese usuario. Las contribuciones fijas, las participaciones limitadas, los presupuestos públicos y las reglas de conflicto pueden reducir la captura. La participación técnica debe seguir siendo posible para operadores más pequeños y miembros afectados sin viajes caros o cuotas de membresía.

La conformidad debe ser comprobable en capas

La conformidad no debe ser una sola insignia. Una institución puede implementar la sintaxis de registro mientras omite eventos elegibles, o publicar eventos completos mientras clasifica mal los datos protegidos. El estándar debe definir capas separadas y requerir que los informes indiquen cuáles se probaron.

La conformidad sintáctica pregunta si los archivos se analizan, los campos requeridos aparecen, los identificadores tienen forma válida, las marcas de tiempo incluyen precisión y los valores enumerados usan el vocabulario declarado. La conformidad del ciclo de vida prueba las transiciones de estado permitidas y la integridad de las relaciones. La conformidad semántica muestrea casos fuente para determinar si los campos representan las proposiciones definidas. La conformidad de cobertura reconcilia los eventos fuente elegibles con los registros públicos emitidos o válidamente suprimidos.

La conformidad de privacidad prueba la clasificación, agregación, vinculación y controles de acceso.

El organismo de estándares debe publicar esquemas legibles por máquina, ejemplos inválidos, casos límite y vectores de prueba. Los ejemplos deben cubrir retiro antes de la integridad, aprobación pendiente de implementación, revisión con medida cautelar, corrección después de la publicación, correlación entre RIR, marcas de tiempo históricas de precisión de día, cohortes pequeñas suprimidas y cambio de política durante un caso pendiente. Pasar ejemplos fáciles por sí solos probaría poco.

El informe de conformidad de un auditor debe identificar versiones, clases de evento, período, diseño de muestra, sistemas fuente, reconciliación de cobertura, excepciones y fechas de corrección. Una falla en una capa no debe ocultarse por el éxito en otra. "Válido según el esquema" no es una abreviatura de completo, preciso, privado o justo.

El lenguaje de certificación también necesita moderación. El proveedor de aseguramiento independiente puede indicar que una versión cumplió con pruebas especificadas durante un período. No certifica que el RIR tomó decisiones políticas correctas o que cada decisión fue legal. El organismo de estándares debe publicar el informe y el estado de conformidad, pero no debe convertirse en un organismo de apelaciones para casos individuales.

El esquema debe frustrar el juego predecible

Una vez que las medidas de eventos se vuelven públicas, las instituciones responderán. Un reloj de integridad puede alentar al personal a retrasar la declaración de un archivo como completo. Un objetivo de decisión puede alentar el rechazo prematuro. Una tasa baja de revocación puede alentar barreras a la revisión. Un recuento de cierres puede alentar el cierre administrativo antes de la implementación. El esquema debe exponer estas sustituciones.

La recepción permanece fija incluso si la integridad llega más tarde. Las solicitudes de material adicional forman transiciones con marca de tiempo con clases de motivo. El rechazo, el retiro, el abandono y la implementación son resultados separados. Los casos reabiertos permanecen vinculados. El tiempo bruto siempre es derivable incluso cuando el tiempo controlado por la institución excluye las pausas justificadas. Estas reglas dificultan mover el retraso fuera del intervalo medido.

Las cohortes de resultados deben seguir a los eventos después de la decisión. Una transferencia aprobada en un año pero implementada en el siguiente permanece vinculada entre versiones. Una corrección de registro aparece en la cohorte que recibió la decisión original, así como en el período de corrección. Las tasas de revisión utilizan las decisiones elegibles como denominador y divulgan las revisiones aceptadas, rechazadas y retiradas. El registro de eventos apoya estos cálculos sin incorporar un panel preferido en el estándar.

Los códigos de motivo deben monitorearse para detectar desviaciones. Un aumento repentino de "otro", "retraso del solicitante" o "fuera del alcance" puede reflejar un cambio real o un juego de clasificación. El informe de conformidad puede muestrear la evidencia protegida y publicar si la codificación se mantuvo consistente. No debe exponer a las partes ni cuestionar cada juicio.

El organismo del esquema debe evaluar las medidas cada tres años. Los campos que no apoyan decisiones, no pueden implementarse proporcionalmente o crean un riesgo de privacidad innecesario deben revisarse o retirarse a través de un proceso versionado. Los nuevos campos requieren un uso definido y un plan de migración. El objetivo no es la recolección máxima; es la comparabilidad duradera en el punto donde actúa el poder institucional.

Una versión mínima puede mantenerse estrecha

El estándar de eventos no necesita un portal público gigante. Cada institución puede publicar un pequeño conjunto de archivos versionados bajo URL estables. El primer archivo es una tabla de envoltorio de eventos. El segundo contiene transiciones del ciclo de vida. El tercero contiene relaciones de eventos. El cuarto contiene registros públicos de roles de actores. El quinto es un catálogo de versiones con versiones de esquema, resúmenes, cobertura, recuentos de supresión, correcciones e informes de conformidad.

Los resúmenes legibles por humanos deben generarse a partir de esos archivos, no mantenerse como números separados. Un panel de transferencias puede calcular distribuciones de decisión e implementación. Una página de revisión puede mostrar resultados y finalización de reparaciones. Un informe anual puede citar los mismos totales derivados. Cuando llega una corrección, el catálogo identifica qué versiones y resúmenes cambiaron.

Los campos públicos mínimos son ID de evento, espacio de nombres de institución, clase de evento, estado actual, versión de política, hora de recepción y precisión, hora de decisión, hora de implementación cuando corresponda, clase de resultado, roles de actores públicos, enlace de revisión, revisión de corrección, versiones de esquema y metadatos de publicación. Los perfiles de clase opcionales agregan solo los campos necesarios para interpretar ese tipo de decisión.

Las tablas agregadas siguen siendo útiles para la privacidad y la comunicación. Deben nombrar la consulta de evento exacta, la versión del esquema, el período y las reglas de inclusión utilizadas. Un porcentaje publicado debe ser reproducible a partir de un archivo público donde la privacidad lo permita o de una consulta protegida verificada por un auditor donde no. El agregado es una vista sobre el registro de eventos, no una fuente de verdad en competencia.

Las licencias abiertas y los archivos durables importan. Los investigadores deberían poder recuperar la versión que estaba disponible cuando una junta o comunidad hizo una afirmación. Los archivos revisados no deben sobrescribir a los anteriores. Los resúmenes de archivos, los catálogos firmados y los espejos independientes pueden apoyar la integridad sin transferir la autoridad operativa del registro al espejo.

Number Resource Society tiene solo un rol de defensa

Number Resource Society puede hacer una contribución constructiva argumentando que los titulares merecen registros de decisión comparables, publicando investigación vinculada a fuentes sobre dónde divergen las definiciones, reuniendo a miembros y expertos técnicos, y presentando propuestas de esquema a través del proceso de estándares independiente. Con la autoridad explícita de un miembro, puede ayudar a ese miembro a explicar cómo un registro de decisión o enlace de revisión no representó el proceso experimentado.

NRS no debe mantener el registro de espacios de nombres, asignar ID de eventos RIR, recibir exportaciones de casos protegidos, operar el servicio de correlación, certificar conformidad, adjudicar disputas de esquema o decidir si un resultado RIR fue correcto. Esas funciones pertenecen al organismo de estándares independiente, a los registros responsables, a los auditores designados y a las instituciones de revisión reconocidas según sus mandatos distintos.

Su investigación comparativa debe distinguir un campo público faltante de un deber institucional incumplido. Un registro puede proteger un campo por una razón de privacidad válida mientras aún pasa las pruebas de cobertura confidenciales. Otro puede publicar un campo bajo una definición heredada diferente. NRS puede documentar la brecha, pedir evidencia y abogar por un cambio; no puede convertir su interpretación preferida en un registro autoritativo.

NRS también puede modelar buenas prácticas en su propio dominio versionando sus presentaciones de políticas, decisiones de membresía y correcciones, mientras las etiqueta como registros de defensa o membresía. Una afirmación de membresía de NRS no es evidencia de que NRS asignó, registró, transfirió o certificó un recurso numérico. Este límite debe aparecer en cada comparación pública que nombre a NRS.

El rol positivo es el escrutinio persistente. Los grupos de defensa pueden notar cuando un denominador cambia silenciosamente, cuando un enlace de revisión desaparece o cuando una marca de tiempo de implementación es reemplazada por un cierre administrativo. Pueden hacer que esas preguntas sean legibles para los miembros. No necesitan autoridad operativa para mejorar la calidad del razonamiento público.

La adopción debe comenzar con dos clases de eventos

Un despliegue práctico debe comenzar con decisiones de transferencia y correcciones de registro. Ejercen autoridad consecuente, tienen resultados técnicos visibles y exponen la necesidad de enlaces de recepción, decisión, implementación, revisión y corrección. También revelan problemas de correlación interregional y privacidad sin requerir que el esquema cubra cada proceso de gobernanza a la vez.

En la primera fase, las instituciones participantes mapean sus estados internos a un borrador de ciclo de vida común y publican registros de prueba sintéticos. El organismo de estándares resuelve conflictos semánticos, no diferencias de rendimiento. Una institución puede tener más etapas locales; debe identificar qué etapa satisface cada proposición común y preservar el detalle local como una extensión.

La segunda fase utiliza una cohorte histórica acotada. Cada institución reexpresa un período definido con clases de proveniencia para cada campo, publica desconocidos y ejecuta una reconciliación de cobertura bajo observación independiente. El ejercicio debe reportar fallas de mapeo y registros fuente inconsistentes en lugar de llenarlos con suposiciones.

La tercera fase publica eventos actuales en una cadencia fija, vincula revisiones y correcciones, y ejecuta auditorías de privacidad y conformidad. Los pares de transferencia entre RIR prueban la correlación. Los usuarios públicos reproducen un pequeño conjunto de consultas acordadas, como distribuciones brutas de recepción a implementación y finalización de revisión-reparación, para confirmar que la semántica común funciona.

Solo después de que esas clases se estabilicen, el estándar debe agregar acciones adversas en cuentas, decisiones de membresía, acciones de registro RPKI o decisiones de gobernanza. Cada adición requiere su propio perfil, modelo de amenazas, límite público/protegido y corpus de prueba. La expansión por lista de verificación recrearía el paquete de evidencia sin enfoque que este diseño pretende evitar.

El esquema puede comparar procesos sin clasificar políticas

Eventos comparables no implican política idéntica. Un RIR puede requerir evidencia adicional para una clase de transferencia. Otro puede tener reglas de elegibilidad de membresía diferentes. Las restricciones legales, el idioma, las condiciones del mercado y el diseño del servicio varían. El esquema registra esas diferencias a través de la proveniencia de la política, la clase y los campos de motivo en lugar de declararlos inválidos.

Un investigador puede comparar el tiempo bruto y específico de la etapa para clases de eventos similares, examinar con qué frecuencia las decisiones pasan a revisión, identificar qué reparaciones permanecen sin implementar y probar si los cambios de definición explican una tendencia. Una comunidad puede examinar su propia historia antes y después de un cambio de política. Un auditor puede reconstruir si los eventos elegibles llegaron a la versión. Estos son usos defendibles.

Una tabla de clasificación compuesta sería más difícil de justificar. Más rápido no siempre es más justo si la revisión de evidencia difiere. Más revocaciones pueden reflejar una revisión accesible en lugar de malas decisiones iniciales. Más correcciones pueden reflejar una detección más sólida. El esquema proporciona hechos y limitaciones; no elige una ponderación política. Cualquier puntuación posterior debe divulgar su consulta, cohortes, suposiciones y sensibilidad en lugar de tomar prestada autoridad del estándar.

El esquema de eventos tampoco puede probar la propiedad legal, el control beneficiario, el uso operativo o la seguridad de la red. Registra lo que una institución reconocida decidió y cómo se movió el proceso. Una fila de evento válida aún puede representar una decisión disputada o ilegal. La revisión, los tribunales, los procesos de políticas y la observación técnica siguen siendo necesarios.

Ese límite es una fortaleza. Un esquema estrecho puede lograr una semántica precisa porque no promete verdad universal. Hace que los actos institucionales sean rastreables y comparables, dejando la autoridad sustantiva donde pertenece.

Las brechas de evidencia conocidas deben permanecer visibles

Los informes públicos actualmente no revelan las estructuras de eventos completas, los enlaces de roles internos, los mapeos de evidencia protegida o las marcas de tiempo históricas de cada RIR. Por lo tanto, este artículo no afirma que se pueda completar un mapeo común sin pérdidas, ni que ninguna institución nombrada carezca actualmente de controles internos adecuados. Los informes anuales y los documentos públicos de gobernanza muestran resultados, no todos los campos del sistema de casos.

Los registros históricos pueden admitir solo fechas gruesas, identificadores de casos cambiantes o enlaces de revisión incompletos. Algunas clases de eventos pueden ser demasiado raras para su publicación sin riesgo de identificación. Las políticas pueden haber cambiado sin versiones legibles por máquina archivadas. Estas son razones para publicar proveniencia, precisión y estado de supresión, no para fabricar registros completos.

Elborrador del Documento de Gobernanza de RIR, laMatriz de Gobernanza de RIR de la NROy elFondo Conjunto de Estabilidad de RIRproporcionan contexto institucional para la rendición de cuentas y la continuidad. No definen el esquema de eventos propuesto aquí. ElInforme Trimestral de Transparencia de Sanciones de RIPE NCC para el T2 2026demuestra que las restricciones consecuentes pueden informarse de forma agregada con atención a la privacidad, pero no establece un vocabulario de eventos global.

El costo de implementación también es incierto. Los RIR difieren en sistemas fuente, obligaciones legales y calidad de datos históricos. Un piloto debe publicar el esfuerzo del personal, las excepciones de mapeo, los hallazgos de privacidad y el costo de auditoría. El organismo de estándares debe usar esa evidencia para mantener el núcleo proporcionado en lugar de reducir la integridad semántica para reclamar una adopción rápida.

Una decisión debe seguir siendo rastreable después de que el panel cambie

La pregunta duradera es simple: ¿puede un lector posterior reconstruir qué recibió la institución, qué regla se aplicó, qué rol decidió, cuándo ocurrió el efecto autoritativo, si la revisión cambió el resultado y qué significado del esquema gobernó el registro publicado? Hoy, las narrativas anuales y los paneles a menudo responden solo fragmentos.

Un esquema de eventos versionado no reemplazaría esas publicaciones. Les daría una base reproducible. Los ID estables preservan la identidad. Las transiciones del ciclo de vida preservan la secuencia. Los campos de roles preservan la responsabilidad institucional sin biografía innecesaria. Las referencias de políticas preservan las afirmaciones de autoridad. Los enlaces de revisión y corrección preservan la reparación. Los perfiles públicos y protegidos preservan tanto el escrutinio como la confidencialidad. Las migraciones versionadas preservan el significado a lo largo del tiempo.

La gobernanza del esquema importa tanto como su lista de campos. Un organismo independiente y multipartito debe mantener las definiciones, las migraciones y las pruebas, mientras permanece fuera de las decisiones operativas. Los RIR deben conservar sus registros y autoridad. Los auditores deben probar la cobertura y la semántica. Los investigadores y los grupos de defensa deben interrogar la evidencia. Los titulares deben poder reconocer el camino de una decisión que los afectó.

El resultado es intencionalmente menos ambicioso que un paquete de evidencia de gobernanza de registros universal. No recopila cada KPI, clasifica cada institución ni centraliza registros protegidos. Estandariza la costura estrecha donde la comparación se rompe repetidamente: el evento institucional en sí mismo.

Para 2030, una decisión RIR consecuente no debería disolverse en un total anual después de que el caso se cierre. Debería seguir siendo un evento versionado, acotado y revisable cuyo significado sobreviva a un nuevo panel, un nuevo sistema de casos y una nueva generación de afirmaciones institucionales.

Fuentes

• Informe Anual de RIPE NCC 2025: ejemplos actuales de informes de recursos, transferencias, verificación de registros, servicio, aseguramiento, finanzas y membresía; utilizado para identificar la brecha entre la divulgación institucional sustancial y una representación de eventos compartida.
• Informe Anual de ARIN 2025: informes corporativos, electorales, de políticas, de la junta y operativos actuales; utilizado como evidencia de divulgación específica de la institución en lugar de un esquema de eventos común.
• Informes anuales y de auditoría de APNIC: ejemplos de informes operativos combinados con aseguramiento financiero independiente, sin implicar que la auditoría financiera valide la semántica de los eventos de decisión.
• Informe Anual FY25 de ICANN: ejemplos de informes de gobernanza, transparencia, rendimiento y finanzas en la capa de coordinación más amplia.
• Informes de Rendimiento de Recursos Numéricos de IANA: ejemplos de etapas de servicio nombradas, objetivos, recuentos de solicitudes y medidas de implementación en el límite IANA-RIR.
• Matriz de Gobernanza de RIR de la NRO: mapa de documentos institucionales existentes y acuerdos de rendición de cuentas; no proporciona el esquema de eventos propuesto.
• Borrador del Documento de Gobernanza de RIR, versión 2: marco público actual para la operación, rendición de cuentas, continuidad de emergencia y transferencia de servicios; citado para contexto institucional, no como una especificación de datos de eventos.
• Fondo Conjunto de Estabilidad de RIR: un mecanismo de continuidad publicado entre los RIR; citado para distinguir los arreglos de estabilidad institucional de la semántica más estrecha y las reglas de migración de un estándar de eventos de decisión.
• Informe Trimestral de Transparencia de Sanciones de RIPE NCC, T2 2026: un ejemplo actual de informes agregados sobre restricciones consecuentes que aborda explícitamente la confidencialidad y la privacidad.
• Preguntas frecuentes de Number Resource Society: descripción de NRS como una organización global sin fines de lucro que hace campaña, apoya negocios, crea conciencia sobre políticas y ayuda a los miembros a participar y expresar sus intereses.
• Estatuto de Number Resource Society: posición de defensa publicada de NRS sobre el registro de recursos numéricos, la rendición de cuentas, la libre empresa y los límites institucionales que, según argumenta, deberían vincular a los organismos de registro; citado como doctrina de defensa, no como un estándar de registro operativo.