Nota:65: La Primacía del Código en Ejecución: El Parche Necesario para Preservar el Diseño Original de Internet

Las siete notas anteriores de Heng.lu en esta secuencia son:

Nota:52 Sobre Cuando el Poder Registral se Desvincula de la Responsabilidad: Por Qué el Modelo Actual de Coordinación de los RIR No Puede Sobrevivir en su Forma Actual
Nota:53 Sobre los Recursos Numéricos de Internet No Son Propiedad Política
Nota:56 La Gobernanza Densa de los Registros Regionales de Internet Convierte la Unicidad en Doble Extracción
Nota:58 De la Doble Extracción a la Inversión de la Soberanía: Cómo las Naciones Pierden el Control Soberano ante los RIR por US$100
Nota:59 La Penalización de la Pobreza: Cómo el Modelo RIR Impone un Impuesto a los Pobres Mientras lo Llama Igualdad
Nota:61 Traición al Código en Ejecución: Cómo el Sistema RIR Volvió el Consenso Contra la Comunidad Técnica
Nota:62 Lavado de Mandato: De la Fantasía RIR a la Arquitectura de Transición

Los siete ensayos anteriores no eran un programa de reforma para los Registros Regionales de Internet.

Eran una autopsia.

Rastreaban la misma patología institucional a través de distintas capas: responsabilidad desvinculada de las consecuencias; recursos numéricos rebautizados como propiedad política; unicidad convertida en doble extracción; soberanía invertida; pobreza gravada en nombre de la igualdad; consenso vuelto contra las redes que debía servir; y finalmente un mandato lavado hasta que un administrativo comenzó a sonar como un soberano. La secuencia importa porque el fracaso no fue una mala junta directiva, un mal registro, una demanda judicial o un evento de mercado incómodo. Fue un defecto sistémico apareciendo bajo distintos disfraces. La página de autor de CircleID ahora muestra claramente esa secuencia, incluyendo Running-Code Betrayal y Mandate Laundering. (circleid.com)

Este ensayo no trata de convertir a los RIR en mejores gobernantes.

Trata de explicar por qué el orden registral actual no puede ser el punto final, y por qué la reparación menos disruptiva es un suplemento al diseño técnico original de Internet.

Ese suplemento es la Primacía del Código en Ejecución (Running-Code Primacy).

La necesidad de ello ya no es teórica. En un intercambio reciente en CircleID, John Curran presentó la forma más sólida del argumento incumbente. Su tesis es que la autoridad del sistema RIR no es simplemente un subproducto de una coordinación técnica limitada, sino el resultado de una cadena histórica: el White Paper, ICANN, la ASO, ICP-2, la transición de la supervisión de la IANA y la continua gobernanza multilateral del sector privado. Afirma que la autoridad del sistema RIR es el resultado de operar dentro del modelo multilateral del sector privado que el Gobierno de Estados Unidos impulsó. (circleid.com)

Ese argumento es útil porque hace visible la disputa.

La cuestión ya no es si existió una delegación histórica. Por supuesto que existió. La cuestión es si una función de coordinación históricamente delegada puede luego expandirse hasta convertirse en un mandato permanente de gobernanza mediante la misma maquinaria procesal que controla. La respuesta incumbente es sí: delegación, reconocimiento, continuidad institucional y procedimiento comunitario se convierten en un mandato autorrenovable.

La respuesta exigida por el diseño técnico original de Internet es no.

La tradición original de Internet era más estrecha, más dura y mejor. RFC 3935 afirma que el objetivo del IETF es “hacer que Internet funcione mejor”; fundamenta el trabajo en competencia técnica, implementación en el mundo real y “consenso aproximado y código en ejecución”. También establece que, cuando el IETF no es responsable de un protocolo o función, no intenta ejercer control sobre ello. (rfc-editor.org) RFC 7282 repite la vieja frase de David Clark: “Rechazamos: reyes, presidentes y votaciones” y “Creemos en: consenso aproximado y código en ejecución”. (rfc-editor.org) RFC 9592 deja aún más claro el punto antisoberano: el IETF no dirige, controla ni patrulla Internet, y no es “la policía de los protocolos”. (rfc-editor.org)

Esa tradición nunca significó que los documentos fueran mágicos. Significaba que los documentos importaban cuando ayudaban a que los sistemas funcionaran. Significaba que el proceso era tolerado porque servía al despliegue. Significaba que una sala era útil solo cuando se disciplinaba a sí misma alrededor de la realidad operacional.

La capa registral tomó prestada esa legitimidad.

Nunca aceptó plenamente esa disciplina.

Ese es el parche que falta.

Qué significa la primacía del código en ejecución.

La Primacía del Código en Ejecución significa que los sistemas de coordinación de Internet deben interpretarse de manera estricta, tomando como referencia la función técnica mínima que originalmente justificó la existencia de las redes en funcionamiento.

La capa de recursos numéricos existe para proteger sistemas en funcionamiento: unicidad, interoperabilidad, continuidad relacionada con el enrutamiento, afirmaciones de seguridad, prueba de control y la semántica común mínima necesaria para que redes independientes puedan trabajar juntas.

No existe para fabricar autoridad política.

No existe para vigilar la moralidad comercial.

No existe para convertir la geografía de un servicio en un título de propiedad.

No existe para convertir una lista de correo en una legislatura.

No existe para permitir que un registro privado haga desaparecer activos de red ya operativos porque cambió su teoría interna de políticas.

Un registro no es un Estado.

Un contacto en una base de datos no es un poder corporativo notarial.

Una región de servicio no es un pueblo.

Una sala de políticas no es una legislatura.

Un registro puede describir la realidad operativa. No la crea.

Esto no es conservadurismo. La Primacía del Código en Ejecución no dice que los sistemas desplegados nunca puedan cambiar. Dice que el poder institucional sobre el cambio no debe justificarse mediante delegación histórica, reconocimiento circular o procedimientos rituales. Debe justificarse mediante reglas deterministas que los operadores puedan verificar localmente y mediante adopción en sistemas en funcionamiento.

El orden correcto es: especificación inicial, estado del libro mayor distribuido, validación local, implementación en ejecución, adopción voluntaria, conjunto de compatibilidad y luego documentación.

El orden incorrecto es: sala de políticas, declaración, obligación reclamada, etiqueta de cumplimiento y cumplimiento operativo forzado.

El sistema RIR fracasó porque eligió cada vez más el segundo orden.

La corrección clave es esta: después de la especificación inicial, no existe una institución continua a la que pedir permiso. Ningún comité decide si la no adopción constituye una infracción. Ningún registro declara inválido a un participante simplemente porque se niega a aceptar un cambio posterior. Solo existen el código, el estado del libro mayor, la validación, la adopción, la compatibilidad, el rechazo local, la bifurcación y la interoperabilidad selectiva.

Un operador que rechaza un cambio posterior no rompe Internet. Puede permanecer en un conjunto de compatibilidad más antiguo. Puede bifurcarse. Puede desconectarse. Puede dejar de interoperar con participantes que hayan adoptado reglas incompatibles. Pero no puede romper la interoperabilidad de otros que continúan ejecutando código mutuamente compatible.

La intuición de diseño es la misma que hace útiles a los libros mayores distribuidos: no se necesita una institución permanente para decidir la validez ordinaria. Los participantes validan localmente las transiciones de estado bajo reglas deterministas. Un estado inválido no es castigado por una institución. Es ignorado por los participantes que no lo aceptan.

Ese es el parche esencial que falta en la coordinación de recursos numéricos.

La falla de diseño estuvo presente desde el principio.

La primera arquitectura de los RIR asumía un mundo de bajo valor.

Los recursos numéricos parecían técnicos, abundantes, administrativos y de bajo conflicto. En ese mundo, la informalidad parecía eficiente. Las listas de correo abiertas parecían representativas. La administración basada en contactos parecía suficiente. Los contratos de responsabilidad limitada parecían inofensivos. Un registro regional podía parecer una simple libreta de direcciones.

La escasez de IPv4 destruyó esa premisa.

Las direcciones IPv4 se volvieron escasas, transferibles, financiables, arrendables, capitalizables, objeto de litigios, sujetas a sanciones e integradas en redes activas. La capa de registro dejó de estar por encima de entradas administrativas. Pasó a estar por encima de infraestructura productiva. Pasó a estar por encima del valor de los activos. Pasó a estar por encima de la continuidad de clientes, el despliegue en la nube, las operaciones de telecomunicaciones, la conectividad nacional, las órdenes judiciales y la asignación de capital.

La forma institucional no se ajustó para corresponder a ese nuevo riesgo.

Se expandió.

El resultado es un sistema que todavía habla el lenguaje de la coordinación técnica mientras ejerce los efectos de una gobernanza de infraestructura. Pide a los operadores que traten el proceso de registro como neutral, mientras las decisiones del registro afectan el destino comercial. Llama “comunidad” a sus participantes, aunque muchos de quienes soportan las consecuencias nunca otorgaron una representación legal clara a las personas presentes en la sala.

NRS expone el problema estructural con claridad: los registros numéricos de Internet fueron diseñados como organismos de coordinación técnica, pero una vez que la escasez de IPv4 convirtió las direcciones en activos valiosos, la discrecionalidad del registro se transformó en poder económico; cuando los sistemas de coordinación controlan capital, la centralización se convierte en un riesgo estructural y la descentralización pasa a ser una cuestión de ingeniería de sistemas más que de ideología. NRS también plantea la dirección opuesta de diseño: una sola Internet, infraestructura abierta y autónoma, y gobernanza descentralizada con mínima participación humana como núcleo. (nrs.help)

Ese es el verdadero problema. La capa de registro nunca fue adaptada para el momento en que una tabla de coordinación se convirtió en una puerta de acceso a activos.

La Primacía del Código en Ejecución es esa adaptación.

No es una doctrina de “mejor RIR”.

Es una disciplina post-RIR.

Las tres reglas del parche

La gramática constructiva es la Nota 64 revisada: Especificación Inicial Mínima, Decisión Futura Localizada y Adopción Voluntaria para los Sistemas de Coordinación de Internet: Especificación Inicial Mínima, Decisión Futura Localizada y Adopción Voluntaria.

Los nombres permanecen sin cambios. La lógica debe ser precisa.

Especificación Inicial Mínima significa que la capa común contiene únicamente reglas deterministas y verificables localmente necesarias para la unicidad, la interoperabilidad, la prueba de control, la seguridad compartida y las afirmaciones de seguridad. No contiene preferencias de modelos de negocio, teorías de precios, sentimientos políticos regionales, poderes de ejecución discrecional ni expansión de la misión institucional.

Decisión Futura Localizada no significa que una institución decida qué decisiones futuras son locales. Eso ya reintroduciría la capa de autoridad. Significa que la especificación inicial realiza el trabajo de limitación de antemano. Tras el despliegue, las decisiones futuras ordinarias permanecen en manos de los participantes que ejecutan el código. Un participante puede adoptar, rechazar, bifurcar, desconectarse o interoperar de forma selectiva. Ningún participante puede alterar la interoperabilidad de otros que continúan ejecutando reglas mutuamente compatibles.

Adopción Voluntaria significa que el cambio posterior solo se vuelve real mediante implementación, validación, despliegue y uso. La publicación no es realidad. La recomendación no es realidad. El reconocimiento institucional no es realidad. La no adopción no crea un estado de invalidez. Un participante que no adopta un cambio posterior permanece en su conjunto de compatibilidad existente. Un participante que emite estados inválidos según las reglas deterministas de otro puede ser ignorado localmente. El efecto es selección de compatibilidad, no castigo institucional.

Estas tres reglas no rehabilitan la soberanía del registro.

Evitan que reaparezca bajo otro nombre.

APNIC: La estructura legal era el riesgo

APNIC muestra el primer fallo: el mínimo nunca se especificó de forma suficientemente estricta desde el principio.

No es una historia de códigos de conducta. No es una historia de etiqueta. No es una historia sobre si un crítico fue lo suficientemente educado con una institución incumbente.

Es una historia de estructura legal.

En marzo de 2023, LARUS publicó una revisión legal advirtiendo que la estructura de gobernanza de APNIC creaba riesgos no solo para una empresa en Brisbane, sino para la gobernanza de Internet en toda la región Asia-Pacífico. La revisión afirmaba que el Director General de APNIC tenía poder legal último para cerrar APNIC y destituir al Consejo Ejecutivo electo, y que eran necesarias reformas urgentes de gobernanza. También señalaba que la estructura planteaba dudas sobre la seguridad de la gobernanza de Internet para más de mil millones de usuarios en la región Asia-Pacífico. (larus.net)

El primer anexo, el extracto de ASIC, proporciona la base corporativa. APNIC Pty Ltd estaba registrada como una empresa privada australiana limitada por acciones, registrada en Queensland. Paul Byron Wilson figuraba como director y secretario. La información de acciones mostraba una única acción ordinaria emitida, y a Paul Byron Wilson como miembro titular de esa acción. (larus.net)

Esa no es una forma normal de alojar una función crítica de coordinación regional de Internet.

El segundo anexo, el dictamen legal del Dr. Peter Felter, extrae la conclusión de gobernanza. Describe la estructura pública de APNIC —miembros, elecciones, Consejo Ejecutivo, Director General y Secretaría— como un comité especial basado en el artículo 9.3 de los Estatutos de APNIC Pty Ltd. Afirma que APNIC Pty Ltd ha sido durante 25 años una empresa privada controlada mediante un director, un accionista y un secretario, todos la misma persona. (larus.net)

Esa distinción importa.

La institución pública orientada a la comunidad no era el contenedor legal final. Era una estructura construida sobre una empresa privada.

El dictamen legal explica entonces por qué esta distinción importa. Se indica que los estatutos de APNIC están sujetos a los Estatutos Sociales y a los poderes de la corporación y sus directores, funcionarios y miembros. Bajo esa interpretación, la estructura pública de APNIC podría ser modificada por resolución del director de APNIC Pty Ltd; el dictamen describe a APNIC como, en efecto, un departamento de APNIC Pty Ltd. (larus.net)

El punto más grave del dictamen no era que APNIC fuera técnicamente ilegal. Era que legalidad y legitimidad no son lo mismo. El dictamen argumenta que el mecanismo de fideicomiso no resuelve el problema porque los poderes del Consejo Ejecutivo siguen derivando de la resolución del director que establece el comité especial. También señala que APNIC Pty Ltd es una empresa privada con acciones cuya estructura y objeto no se corresponden con el modelo de organización sin acciones sin fines de lucro que normalmente se asociaría a un registro regional de interés público. (larus.net)

Ese es el primer fallo de diseño en su forma más pura.

Un sistema de coordinación de números a escala regional no debería depender de una estructura que requiera abogados para explicar por qué una empresa privada con una sola acción, un comité especial, un fideicomiso y un consejo electo se combinan de alguna forma en control legítimo del registro de Internet de Asia-Pacífico.

Una capa de coordinación crítica debería ser legible desde fuera.

No debería requerir confianza en documentos detrás de documentos.

No debería requerir que los miembros descubran, después de años de dependencia institucional, que la capa electa puede no ser la capa legal final.

No debería dar la apariencia de gobernanza de miembros mientras el poder formal reside en otro lugar.

Por eso la Especificación Inicial Mínima debe incluir validez distribuida, no confianza institucional. No porque una institución futura necesite mejor gobernanza, sino porque un sistema futuro post-RIR no debe necesitar esa institución en absoluto.

La capa común no debería depender de la estructura oculta de control de una empresa privada. Debería definir reglas deterministas de validación, estados de prueba de control, reglas de transición de estado, reglas de conflicto, replicación de libros mayores, rutas de salida, rutas de bifurcación y conjuntos de compatibilidad. Si APNIC desaparece, se captura a sí misma, cambia su postura legal o se niega a reconocer un estado válido, la red en funcionamiento no debería depender del reconocimiento de APNIC para saber quién controla qué recursos numéricos.

El registro no debería ser la fuente de validez.

Debería serlo el estado del libro mayor distribuido, validado bajo la especificación inicial.

ARIN: La política se encontró con la realidad de los activos

ARIN muestra el segundo fallo: la realidad legal y de mercado puede adelantarse a la teoría del registro.

El evento decisivo fue la transacción Nortel/Microsoft. Cuando Nortel entró en bancarrota, sus 666.624 direcciones IPv4 se convirtieron en activos valiosos dentro del procedimiento. Las direcciones fueron vendidas a Microsoft por 7,5 millones de dólares. ARIN intervino bajo la teoría de que las direcciones no eran propiedad y que no podían venderse libres de la política del registro. Industry Canada apoyó esa postura. El tribunal de bancarrota la rechazó; Microsoft más tarde firmó un acuerdo de “legacy”; y el resultado práctico fue claro: la política del registro no podía seguir siendo la única fuente de realidad una vez que los tribunales y los mercados trataban los recursos numéricos como activos. (btw.media)

La lección importante no es que ARIN fuera especialmente defectuoso.

La lección es que la capa de registro había entrado en una nueva categoría.

Un registro es valioso porque operadores, tribunales, compradores, vendedores, acreedores y redes confían en él. No se vuelve autoritativo negando esa dependencia. Solo permanece útil si refleja con suficiente precisión la realidad legal, de mercado y operativa.

Una vez que IPv4 se volvió escaso, el proceso del registro se convirtió en una interfaz de mercado. Las reglas de transferencia, las evaluaciones de necesidad, los retrasos en el reconocimiento y las restricciones regionales dejaron de ser detalles administrativos. Se convirtieron en fricciones de activos. El análisis público describe hoy un libro de reglas fragmentado de los RIR en el que cinco sistemas regionales gobiernan un mercado que se negocia entre aproximadamente 18 y 45 dólares por dirección, con reglas conflictivas capaces de inmovilizar activos, retrasar fusiones y obligar a estructuras corporativas separadas solo para poder mantener bloques de direcciones. (btw.media)

Eso no es coordinación neutral.

Es un efecto regulatorio sin responsabilidad regulatoria.

ARIN demuestra por qué importa la Adopción Voluntaria. La política del registro solo mantiene credibilidad mientras describe lo que los actores realmente implementan, negocian, financian, litigan y utilizan. Se vuelve peligrosa cuando la publicación se trata como suficiente para fabricar la realidad.

Un registro que se niega a la realidad no se vuelve soberano.

Se convierte en una base de datos obsoleta.

En un diseño de Primacía del Código en Ejecución, la lección es aún más clara. Los tribunales y los mercados no necesitan un registro incumbente para decidir si existe valor. Los operadores no necesitan un comité para saber si un bloque enruta. Los participantes necesitan reglas deterministas que permitan prueba de control, resolución de conflictos, transiciones de estado visibles en un libro mayor y compatibilidad. El antiguo registro puede publicar una vista. Un cliente de software puede mostrar una vista. Un explorador de libro mayor puede mostrar una vista. Ninguno es la fuente de validez.

No hay un registro al que migrar.

No hay un registro al que preguntar.

Solo existe un estado distribuido que los participantes validan, aceptan, rechazan, bifurcan o con el que interoperan.

AFRINIC: Cuando la teoría del registro amenazó los activos en funcionamiento

AFRINIC es el caso central porque redujo el problema a su esencia.

La historia incorrecta es que un miembro problemático paralizó un registro regional.

Ese es el relato moral del incumbente.

La historia estructural es distinta. AFRINIC intentó convertir el uso comercial, la geografía de clientes, el arrendamiento, la relación con los miembros y la interpretación interna de políticas en un poder declarado para desregistrar recursos numéricos ya en funcionamiento. Una vez hecha esa afirmación, el conflicto dejó de poder permanecer como un desacuerdo en una sala de políticas. Se convirtió en una prueba de si un registro privado podía usar la retórica regional y el silencio normativo para amenazar activos integrados operativamente.

Los hechos no requieren exageración teatral. Informes públicos describieron la disputa de AFRINIC como un simple conflicto comercial sobre direcciones IP que se convirtió en la mayor historia de gobernanza de Internet en África. También señalaron que Cloud Innovation había sido a menudo presentado como el villano, mientras que material documental posterior apuntó a fuerzas destructivas dentro del propio AFRINIC y a litigios retrasados, prolongados y continuados por representantes de AFRINIC a su costo. (btw.media)

Eso es importante porque invierte la narrativa habitual.

El litigio no creó la falla estructural.

La expuso.

El fallo relevante ya estaba presente cuando un registro privado trató la ausencia de permiso explícito como base para control coercitivo. El arrendamiento no era una amenaza a la unicidad. La geografía de clientes no era una asignación duplicada. El uso comercial no era un fallo de seguridad de enrutamiento. Un modelo de negocio desaprobado por un registro no era un invariante global.

Sin embargo, la interpretación del registro colocó estos elementos dentro de un marco de revocación.

Ese es el momento en que la coordinación se convierte en gobernanza.

Informes registran que AFRINIC envió a Cloud Innovation una carta en marzo de 2021 alegando violaciones de políticas y amenazando con la terminación de su membresía; que en julio de 2021 el Tribunal Supremo de Mauricio prohibió a AFRINIC cancelar la membresía de Cloud Innovation; y que un nuevo intento de cancelación fue bloqueado en diciembre de 2021. (btw.media) Esa secuencia no es la historia de un registro protegiendo con calma Internet. Es la historia de la autoridad del registro encontrándose con el derecho ordinario.

Tampoco fue el colapso institucional causado por demasiado poder del registro. El problema más profundo fue el bloqueo estructural. Si un registro tiene monopolio de reconocimiento sobre activos vivos de alto valor, cualquier fallo interno se convierte en un riesgo de continuidad de Internet. Si los miembros no pueden abandonar el sistema de reconocimiento, el fallo del registro se convierte en poder de rehenes.

Un registro puede corregir fraude de registro demostrable en sus propios datos.

Puede evitar asignaciones duplicadas mientras el modelo de registro exista.

Puede mantener afirmaciones de seguridad mientras los participantes dependan de él.

Pero esas son funciones transitorias de una arquitectura antigua.

En una arquitectura post-RIR, esas funciones no las realiza un registro. Se codifican en el estado de un libro mayor distribuido, reglas de prueba de control, reglas de conflicto y transiciones verificables localmente.

Un organismo privado no debería convertir el arrendamiento en traición regional.

No debería convertir la geografía de clientes en un desencadenante de revocación.

No debería tratar el desacuerdo comercial como invalidez técnica.

No debería convertir la continuidad de activos en permiso.

AFRINIC demuestra la necesidad de una Decisión Futura Localizada correctamente entendida. No existe un órgano central que decida que una futura decisión comercial “pertenece localmente”. Más bien, la especificación inicial debe garantizar que estas decisiones nunca entren en la capa común en primer lugar. El arrendamiento, la geografía de clientes, el uso comercial, la fijación de precios, la financiación, la mezcla de clientes y la estrategia de despliegue quedan fuera de las reglas de validez deterministas, a menos que afecten directamente a la unicidad, la seguridad, la prueba de control o la interoperabilidad.

Un operador no puede romper la interoperabilidad de otros operadores alquilando direcciones.

No puede romperla sirviendo clientes fuera de una región histórica del registro.

No puede romperla usando un modelo de negocio que el registro desaprueba.

En todo caso, un operador puede no cumplir reglas deterministas que otros participantes ejecutan. En ese caso, los demás rechazan localmente el estado inválido. No hay capa de castigo. No hay tribunal de cumplimiento. No hay soberano regional.

Esa línea no es ideológica.

Es operativa.

La carta de la NRO: la vía de escape hacia arriba

La evidencia más seria no es el intento de exceso de AFRINIC.

Es la respuesta colectiva del sistema.

En 2022, la Number Resource Organization escribió al Gobierno de Mauricio. La carta describía a la NRO como el organismo de coordinación de los RIR del mundo y afirmaba que los RIR gestionan los recursos numéricos en sus respectivas regiones. Señalaba que los cinco registros cumplen la función de administrar recursos numéricos bajo reglas adoptadas regionalmente o políticas globales adoptadas por unanimidad. (nro.net)

La misma carta criticaba el litigio de Cloud Innovation, afirmaba que se habían presentado más de 25 demandas, se quejaba de órdenes judiciales que congelaron las cuentas de AFRINIC y detuvieron elecciones, y sostenía que AFRINIC había solicitado repetidamente a Mauricio ser reconocido como una organización internacional. La NRO instaba al gobierno a tomar medidas para preservar la independencia de AFRINIC y la estabilidad de Internet en África. (nro.net)

Ese es el documento más revelador de toda la historia.

Cuando un registro privado entró en conflicto con tribunales ordinarios, el reflejo del sistema no fue reducir el alcance del mandato.

No fue eliminar el bloqueo de los registros.

No fue separar la administración de registros de la ejecución.

No fue definir validación distribuida.

No fue cuestionar si el poder unilateral de desregistro sobre activos en funcionamiento había sido ilegítimo desde el principio.

El reflejo fue una vía de escape hacia arriba.

Un organismo privado de coordinación no puede ser técnico cuando quiere discreción, comunitario cuando quiere legitimidad, contractual cuando quiere tarifas, no-propietario cuando quiere evitar responsabilidad, y cuasi-internacional cuando quiere inmunidad frente a los tribunales.

Ese conjunto no es gobernanza.

Es una forma sistémica de “lavado de mandato”.

Si los RIR quieren privilegios de derecho público, deben aceptar responsabilidad de derecho público. Si quieren flexibilidad de derecho privado, deben aceptar litigación de derecho privado. Lo que no pueden exigir de forma coherente es discreción privada, importancia de infraestructura pública, baja responsabilidad, representación débil, estatus de monopolio e inmunidad cuasi-diplomática al mismo tiempo.

Ese es el camino de colapso.

La Primacía del Código en Ejecución lo rechaza.

Cuando un registro se enfrenta a resistencia legal, no debe escapar hacia arriba buscando inmunidad. La arquitectura debe contraerse hacia abajo, reduciéndose a la función estricta de código en ejecución que originalmente la justificó.

Menos soberanía.

Ningún registro como fuente de validez.

Menos ejecución.

Más validación distribuida.

La revisión de ICP-2 no es suficiente

El sistema actual reconoce que algo se ha roto.

La página de comentarios públicos de ICANN sobre el segundo borrador del documento de gobernanza de los RIR señala que la propuesta establecería reglas y criterios para reconocer nuevos RIR, obligaciones operativas y requisitos para los RIR existentes, así como reglas de desreconocimiento; si se adopta, reemplazaría a ICP-2. La misma página indica que el proceso fue iniciado después de que la NRO solicitara a la ASO proponer actualizaciones para dotar al sistema de RIR de mayor rendición de cuentas ante la comunidad de Internet. (icann.org)

Eso puede ser necesario como medida de continuidad.

No es suficiente como teoría de legitimidad.

Las reglas de reconocimiento y desreconocimiento responden a una pregunta tardía: ¿cuándo ha fallado un registro lo suficiente como para ser eliminado?

La pregunta anterior es más importante: ¿por qué un registro debería tener suficiente poder como para fallar de forma catastrófica en primer lugar?

Un sucesor de ICP-2 que solo endurezca el reconocimiento, la auditoría, la transición y el desreconocimiento puede mejorar la higiene institucional mientras preserva el error de categoría. Sigue asumiendo que el RIR es la forma soberana primaria de coordinación de recursos numéricos.

La Primacía del Código en Ejecución plantea un conjunto distinto de preguntas.

¿Cómo continúa Internet si un RIR colapsa?

¿Cómo se mantienen verificables las asignaciones de recursos numéricos sin permiso de una entidad incumbente?

¿Cómo sobrevive la unicidad sin discrecionalidad monopólica?

¿Cómo se evita que los registros se conviertan en herramientas de ejecución coercitiva?

¿Cómo se mantienen las decisiones comerciales fuera de la validez determinista, salvo cuando existe un invariante global real en riesgo?

¿Cómo permanece la coordinación utilizable sin un registro autoritativo?

¿Cómo valida un operador el estado ordinario sin consultar a un organismo permanente?

¿Cómo evita el rechazo convertirse en una etiqueta de infracción?

Estas no son preguntas de reforma.

Son preguntas post-RIR.

Por qué este es el parche del diseño original

El problema no es si a alguien le gustan o no los registros incumbentes.

El problema es si la capa de recursos numéricos sigue obedeciendo la disciplina de diseño que hizo posible Internet: reglas comunes mínimas, validación local, adopción voluntaria y código en ejecución.

La Primacía del Código en Ejecución no es una estrategia de relaciones públicas ni un compromiso institucional. Es la reparación técnica implícita en el diseño original. Si Internet fue construido para rechazar reyes, presidentes y votaciones como fuentes de verdad técnica, entonces la capa de recursos numéricos no puede recrear esas formas a través de procesos de registro, delegación histórica o teatro comunitario.

El consenso por sí solo puede convertirse en ritual. El código en ejecución por sí solo puede ser subordinado si la capa de registro se coloca por encima como fuente de reconocimiento. La regla que falta es interpretativa y arquitectónica: cuando el proceso institucional entra en conflicto con la función técnica mínima que requieren los sistemas en funcionamiento, el código en ejecución tiene prioridad; y cuando se propone un cambio posterior, este solo se vuelve real mediante la adopción voluntaria de los participantes que ejecutan las reglas de validación.

Así es como se preserva el diseño original, no como se abandona.

Internet fue importante porque se convirtió en el primer sistema global de comunicaciones que no requería permiso previo de un único soberano, ministerio, iglesia, corporación o guardián. Si ese logro sigue siendo digno de defensa, la capa de recursos numéricos no puede convertirse en la excepción que invalida la regla.

Un sistema construido para evitar reyes no puede permitir que un contable aspire a ser uno.

El parche restaura la jerarquía original: código primero, operadores primero, validación determinista primero, estado distribuido primero; las instituciones, si llegan a existir durante la transición, solo como artefactos no autoritativos, nunca como fuentes de validez.

Qué requiere la coordinación post-RIR

La coordinación post-RIR no significa caos.

Significa que la capa común se vuelve más delgada, más objetiva, más determinista y más distribuida que el actual monopolio de los RIR.

No hay un registro al que migrar.

No hay un nuevo registro que coronar.

No hay un nuevo sacerdocio.

Hay un libro mayor distribuido del estado de los recursos numéricos, con reglas de validación deterministas, mecanismos de prueba de control, manejo de conflictos, conjuntos de compatibilidad, historial de transiciones de estado y verificación local por parte de los participantes.

La capa común debe preservar la unicidad de identificadores, la prueba de control, el estado de transferencia, el estado de delegación, las afirmaciones de seguridad relacionadas con el enrutamiento, la auditabilidad, los metadatos de conflicto y la visibilidad de bifurcaciones.

La capa de operadores debe controlar el uso comercial, el arrendamiento, la geografía de clientes, las prácticas de enrutamiento, la financiación, la selección de contrapartes y las reglas de negocio no invariables.

La capa de adopción debe determinar qué se vuelve real. Una regla de coordinación solo importa si los operadores pueden implementarla, las contrapartes pueden aceptarla, los mercados pueden confiar en ella, los tribunales pueden entenderla y la interoperabilidad se mantiene sin convertir el reconocimiento del incumbente en la única fuente de realidad.

La capa de ejecución no debe fusionarse con la capa de estado. Un libro mayor distribuido puede registrar estado. Puede validar transiciones. Puede exponer conflictos. Puede hacer la prueba portátil. No debe convertirse al mismo tiempo en fiscal, juez, autoridad sancionadora, regulador de mercado, moralista comercial y custodio de activos.

Lo más importante es entender correctamente la portabilidad.

En un mundo de libro mayor distribuido, la portabilidad no significa pasar de un registro a otro registro. Eso sigue siendo pensamiento de registro. No hay un registro al que migrar. La prueba de control del titular, el historial de estado y la capacidad de transferencia no están atrapados dentro de una base de datos incumbente. Existen en un estado verificable compartido que los participantes validan localmente y que las contrapartes aceptan voluntariamente.

Sin eso, cada registro es un punto de bloqueo.

Con eso, el registro deja de ser fuente de validez.

Por lo tanto, la coordinación post-RIR necesita cuatro propiedades de diseño.

Primero, validez determinista. Un participante debe poder saber si una transición de estado, prueba, delegación, transferencia o afirmación es válida aplicando la especificación localmente.

Segundo, conjuntos de compatibilidad. Si los participantes adoptan reglas futuras diferentes, el sistema debe describir claramente los límites de compatibilidad en lugar de tratar la disidencia como una infracción.

Tercero, prueba distribuida de control. Un titular no debe “mover” sus recursos a otro registro; debe demostrar control mediante un estado válido en el libro mayor que cualquier contraparte pueda verificar sin aprobación del incumbente.

Cuarto, visibilidad de bifurcaciones. Si los conjuntos de reglas divergen, la divergencia debe ser explícita. Los participantes deciden qué conjunto de compatibilidad ejecutar y con qué contrapartes interactuar. Una bifurcación puede aislar participantes, pero no da a una de las partes poder institucional para borrar a la otra.

Eso no es un argumento a favor de cinco monopolios mejores.

Es un argumento contra el monopolio como fuente de validez.

Por qué el camino de fallo es predecible

Si nada cambia, el camino de fallo es claro.

Primero, más disputas pasarán de las salas de políticas a los tribunales. Los activos escasos atraen escrutinio legal. Se pedirá a los tribunales que congelen cuentas, preserven registros, bloqueen elecciones irregulares, nombren administradores judiciales, reconozcan transferencias o determinen quién puede actuar en nombre de un registro.

Segundo, los Estados dejarán de tratar a los RIR como asociaciones técnicas inofensivas. La continuidad del direccionamiento afecta a la conectividad nacional, las sanciones, la aplicación de la ley, la resiliencia de telecomunicaciones, la infraestructura en la nube y la seguridad económica. Ningún Estado aceptará indefinidamente una entidad privada extranjera como punto ascendente no cuestionado de la continuidad de las comunicaciones nacionales.

Tercero, los operadores rodearán la autoridad del registro cuando sea posible. Si los registros se vuelven políticos, inseguros, no representativos o desconectados de la realidad de los activos, los operadores recurrirán a contratos privados, transferencias respaldadas por litigios, certificaciones alternativas, reconocimiento nacional o la realidad de enrutamiento de facto.

Cuarto, las capas de ICANN y la NRO se verán tentadas a centralizar. Eso produciría una versión más densa del mismo problema, a menos que el mandato en sí se reduzca.

Quinto, los gobiernos se verán tentados a nacionalizar. Eso sería predecible y peligroso. Si los registros privados reclaman autoridad cuasi-soberana sin responsabilidad pública, los Estados eventualmente reclamarán soberanía. El resultado podría ser fragmentación, represalias, registros en conflicto y presión política sobre el enrutamiento.

Internet no falla solo cuando dejan de moverse los paquetes.

También falla cuando las instituciones que describen quién puede usar los identificadores pierden la confianza de los operadores que hacen mover esos paquetes.

Un libro mayor distribuido no resuelve todos los problemas políticos. Pero hace algo más importante: elimina al registro permanente como fuente ordinaria de validez. Eso reduce la superficie de ataque. Reduce el poder de rehenes institucional. Convierte los desacuerdos futuros en selección de compatibilidad en lugar de guerra administrativa.

Apéndice: Especificación Inicial Mínima, Decisión Futura Localizada y Adopción Voluntaria para Sistemas de Coordinación de Internet

Nota 64

Resumen

Este documento describe un patrón de diseño para sistemas de coordinación de Internet cuyo propósito es proporcionar puntos de referencia técnicos compartidos sin crear una autoridad continua por encima de los participantes que ejecutan el sistema. Define tres principios vinculados: Especificación Inicial Mínima, Decisión Futura Localizada y Adopción Voluntaria.

Bajo este modelo, la Especificación Inicial define únicamente las reglas deterministas y verificables localmente necesarias para la unicidad, la interoperabilidad, la prueba de control, la seguridad compartida y la seguridad. Tras la Especificación Inicial, los cambios futuros no son aprobados por un organismo central. Son adoptados, ignorados, bifurcados o abandonados por los participantes que ejecutan código.

El patrón de diseño previsto es un libro mayor distribuido de estado válido, o un mecanismo equivalente de estado verificable distribuido, no una jerarquía de registros. No existe un registro permanente que decida la validez ordinaria. Los participantes validan el estado localmente, aceptan contrapartes de forma voluntaria y deciden qué conjuntos de compatibilidad ejecutan.

La no adopción no es una infracción. Un participante que no adopta un cambio posterior permanece en su conjunto de compatibilidad existente. Un participante que emite estados no válidos según las reglas deterministas aceptadas por otro participante puede ser ignorado localmente por ese participante. El efecto es selección de compatibilidad, bifurcación, aislamiento o interoperabilidad selectiva, no castigo institucional.

Este documento no define un protocolo de red (wire protocol). Especifica una Mejores Prácticas Actuales (BCP) para el diseño de protocolos, sistemas de identificadores, libros mayores distribuidos y mecanismos de coordinación que no deben convertirse en instituciones permanentes de gobernanza.

1. Introducción

Muchos sistemas de Internet comienzan con un propósito técnico limitado: permitir que actores independientes interoperen mediante un punto de referencia común, un espacio de identificadores, una regla de validación, un estado de libro mayor o un registro de prueba de control compartido. Con el tiempo, estos sistemas suelen acumular autoridad que no era necesaria para la interoperabilidad inicial.

Esto normalmente ocurre en tres pasos.

Primero, las preguntas futuras se incorporan a la capa fundacional antes de que sean técnicamente necesarias.

Segundo, decisiones que deberían ser tomadas por los participantes que ejecutan sus propios sistemas pasan a depender del reconocimiento, la interpretación o decisiones de estatus por parte de un organismo permanente.

Tercero, la publicación, el registro, la recomendación o la aprobación procedimental se tratan como suficientes para crear obligaciones operativas, incluso cuando los participantes no han adoptado el cambio en los sistemas en ejecución.

El resultado es un sistema frágil. Una capa de referencia técnica se convierte en una capa de gobernanza. Un registro se convierte en un punto de control. Un artefacto de coordinación se convierte en una fuente de control futuro.

Este documento propone una disciplina de diseño diferente:

Especificación Inicial Mínima: definir únicamente las reglas deterministas comunes necesarias para la interoperabilidad básica, la unicidad, la prueba de control, la seguridad compartida y la seguridad.

Decisión Futura Localizada: después de la Especificación Inicial, mantener las decisiones futuras en los participantes que ejecutan código. Un participante puede adoptar, rechazar, bifurcar, desconectarse o interoperar de forma selectiva. Ningún participante puede alterar la interoperabilidad de otros participantes que continúan ejecutando reglas mutuamente compatibles.

Adopción Voluntaria: hacer que los cambios posteriores sean reales únicamente mediante implementación, operación, validación y adopción por parte de los participantes que ejecutan código.

Estos principios están relacionados. Un sistema que especifica demasiado desde el inicio precarga el control futuro en la capa común. Un sistema que mantiene una capa de reconocimiento continuo permite que la autoridad reaparezca después del despliegue. Un sistema que trata la publicación como realidad convierte la documentación en mandato.

La intuición de diseño es simple: la validez debe ser determinada por reglas deterministas que los participantes puedan verificar localmente contra un estado compartido. Un participante puede adoptar un cambio posterior, rechazarlo, bifurcarse, desconectarse o interoperar de forma selectiva. A lo sumo puede retirarse de un conjunto de compatibilidad. No puede, al rechazar un cambio, romper la interoperabilidad de otros participantes que continúan ejecutando reglas mutuamente compatibles.

Esta es la lección general del diseño de libros mayores distribuidos: las reglas de consenso son aplicadas por participantes que ejecutan código de validación y deciden qué estado aceptan, no por una institución situada por encima de ellos.

2. Alcance

Este documento se aplica a sistemas de coordinación de Internet, incluidos, entre otros, sistemas de identificadores, marcos de nombres y numeración, mecanismos de extensión de protocolos, sistemas de prueba de control, sistemas de portabilidad, libros mayores distribuidos y otras arquitecturas en las que actores independientes dependen de un punto de referencia técnico común.

Este documento no argumenta contra las reglas comunes. Argumenta que las reglas comunes deben ser deterministas, mínimas, verificables localmente y limitadas a lo que el sistema realmente necesita para funcionar.

Este documento no requiere ninguna implementación específica de libro mayor distribuido. Requiere una propiedad de diseño: los participantes deben poder determinar la validez aplicando la Especificación Inicial localmente a un estado compartido o replicable, sin pedir permiso o estatus a una autoridad permanente.

Rechazo local (Local Rejection):
Decisión local de un participante de ignorar, rechazar o no interoperar con un estado, mensaje, registro o transición que sea inválido o incompatible según las reglas de validación que ejecuta.

Bifurcación (Fork):
Una divergencia en las reglas de validación o en la práctica operativa que crea dos o más conjuntos de compatibilidad.

Artefacto de coordinación (Coordination Artifact):
Un documento, recomendación, nota de implementación, perfil, implementación de referencia, explorador de libro mayor, réplica u otro artefacto que ayuda a los participantes a coordinarse. Un artefacto de coordinación no crea una realidad operativa vinculante a menos que los participantes lo adopten en sistemas en ejecución.

4. Planteamiento del problema

Los diseñadores suelen intentar reducir la incertidumbre futura escribiendo demasiado en la capa fundacional o dejando a un organismo permanente la interpretación de cuestiones futuras. Esto parece prudente. A menudo es peligroso.

La sobreespecificación en la capa fundacional tiene tres costos.

Primero, traslada decisiones futuras a una capa común donde el cambio es más difícil y donde la captura tiene mayor efecto.

Segundo, crea ambigüedad entre la validez técnica y el reconocimiento institucional.

Tercero, incentiva a un organismo que mantiene registros, publica documentos o convoca participantes a tratar esos actos como autoridad sobre la realidad futura.

El mismo problema aparece después del despliegue. Si un sistema requiere un organismo permanente para aprobar cambios, determinar estados o interpretar la operación ordinaria, el sistema ha creado una capa de control posterior a la fundación. Esa capa puede comenzar como administración. Puede convertirse en gobernanza. Y puede convertirse en un punto de estrangulamiento.

El objetivo de diseño de este documento no es una mejor discrecionalidad institucional. El objetivo es evitar la necesidad de esa discrecionalidad.

Un sistema de coordinación de Internet bien diseñado debería definir reglas de validez deterministas y verificables localmente desde el inicio; representar el estado válido en forma distribuida o replicable; mantener las decisiones no invariables fuera de la capa común; y permitir que los cambios posteriores se vuelvan reales solo cuando los participantes los adopten voluntariamente en sistemas en ejecución.

5. Principio 1: Especificación Inicial Mínima

5.1. Declaración

Una Especificación Inicial DEBERÍA definir únicamente las reglas comunes deterministas mínimas necesarias para la interoperabilidad básica, la unicidad, la prueba de control, la seguridad compartida y la seguridad.

5.2. Requisitos

Un diseño que utilice este principio:

• DEBE identificar explícitamente sus Invariantes Globales.
• DEBE definir reglas de validación deterministas para cada Invariante Global.
• DEBE definir cómo el estado válido se representa, se replica, se verifica y se actualiza.
• NO DEBE incluir una regla en la Especificación Inicial a menos que dicha regla sea necesaria para preservar un Invariante Global declarado o para permitir el despliegue inicial.
• DEBE separar las reglas de validación de las preferencias de política, acuerdos comerciales, roles institucionales, aspiraciones de gobernanza y juicio discrecional.
• DEBE permitir que los participantes verifiquen la validez ordinaria localmente sin solicitar información a ninguna institución, registro, comité, organismo de políticas u otra autoridad.
• DEBERÍA definir estructuras de datos, firmas, pruebas, reglas de transición de estado, reglas de conflicto u otros mecanismos necesarios para la verificación local.
• DEBERÍA definir señalización de extensiones, versionado, etiquetado de compatibilidad o identificación de bifurcaciones cuando la variación futura sea previsible.
• DEBE garantizar que los artefactos de coordinación requeridos sean portables, auditables, reproducibles y reemplazables.
• DEBERÍA preferir condiciones objetivas verificables por máquina en lugar de juicios subjetivos de mérito.
• NO DEBE hacer del reconocimiento institucional futuro la única vía por la cual un estado válido pueda ser conocido, registrado o utilizado.

5.3. Implicaciones de diseño

La Especificación Inicial Mínima no significa una especificación vaga. Significa una especificación estricta únicamente de lo que debe ser común.

Un sistema aún necesita suficiente estructura común para funcionar. La disciplina consiste en distinguir entre:

• lo que debe ser común para la unicidad, la interoperabilidad, la prueba de control, la seguridad compartida y la seguridad; y
• lo que puede permanecer fuera de la capa común porque pertenece a la preferencia del operador, la práctica comercial, la elección de contraparte, el momento de despliegue o decisiones posteriores de adopción.

Un diseño que no pueda expresar claramente sus Invariantes Globales y sus reglas de validación deterministas debería asumir que ha especificado demasiada discrecionalidad y muy poca sustancia verificable.

6. Principio 2: Decisión Futura Localizada

6.1. Declaración

Después de la Especificación Inicial, las Decisiones Futuras DEBERÍAN permanecer locales a los participantes que ejecutan código. Una Decisión Futura se vuelve efectiva únicamente para el conjunto de compatibilidad cuyos participantes la adoptan. No se requiere ninguna autoridad permanente para aprobarla, y la no adopción no crea un estado de invalidez.

6.2. Requisitos

Un diseño que utilice este principio:

• NO DEBE requerir que los participantes obtengan permiso de una institución incumbente, registro, comité, consejo, organismo de políticas u otra autoridad para decisiones que no alteren las reglas de validación deterministas del conjunto de compatibilidad al que pertenecen.
• NO DEBE crear un organismo permanente cuyo reconocimiento sea la única vía por la cual un cambio posterior pueda convertirse en realidad operativa.
• DEBE distinguir entre la validez bajo la Especificación Inicial y la compatibilidad con un cambio opcional posterior.
• NO DEBE tratar la no adopción de un cambio posterior como invalidez.
• DEBE permitir que los participantes permanezcan en un conjunto de compatibilidad existente cuando no adopten un cambio posterior.
• DEBE permitir que los participantes se unan a un nuevo conjunto de compatibilidad mediante la adopción de nuevas reglas de validación o perfiles operativos.
• DEBE permitir que los participantes rechacen localmente estados, registros, transiciones o mensajes que sean inválidos o incompatibles según las reglas de validación que ejecutan.
• DEBE permitir que los participantes elijan contrapartes de forma voluntaria según las reglas de validación y los conjuntos de compatibilidad que aceptan.
• NO DEBE autorizar a ninguna institución, registro, comité, organismo de políticas u otro actor a declarar inválido a un participante únicamente porque rechazó un cambio posterior.
• DEBERÍA hacer explícitos los forks, versiones, perfiles o conjuntos de compatibilidad, de modo que los participantes sepan qué reglas están ejecutando y con qué otros participantes pueden interoperar.
• DEBERÍA evitar cualquier diseño en el que un registro incumbente pueda impedir que participantes que siguen siendo válidos continúen interoperando.

6.3. Implicaciones de diseño

La Decisión Futura Localizada no significa que una autoridad central asigne decisiones futuras a actores locales. Significa que el sistema está diseñado de forma que, después de la Especificación Inicial, las decisiones futuras ordinarias no requieren dicha asignación.

La Especificación Inicial realiza por adelantado el trabajo de limitación. Define los invariantes mínimos necesarios para la unicidad, la interoperabilidad, la prueba de control, la seguridad compartida y la seguridad. Todo lo demás permanece fuera de la capa común.

El cambio futuro no se aprueba centralmente. Es adoptado, ignorado, bifurcado o abandonado por los participantes que ejecutan código.

Un participante que rechaza un cambio puede permanecer fuera del conjunto de compatibilidad creado por ese cambio. Puede desconectarse de otros. Puede continuar en un conjunto de compatibilidad anterior. Puede bifurcarse. Puede interoperar de forma selectiva. Pero no puede romper la interoperabilidad de otros participantes que continúan ejecutando reglas mutuamente compatibles.

El efecto de un estado inválido o incompatible es el rechazo local, no el castigo. No es necesario que nadie determine que un participante está en mala posición. Un participante que ejecuta reglas de validación compatibles simplemente no acepta el estado inválido o incompatible.

7. Principio 3: Adopción Voluntaria

7.1. Declaración

Los cambios en un sistema de coordinación de Internet DEBERÍAN convertirse en realidad operativa mediante implementación, validación, despliegue, aceptación por contrapartes y adopción por los participantes, y no únicamente mediante publicación o declaración.

7.2. Requisitos

Un diseño que utilice este principio:

• NO DEBE considerar la publicación, recomendación, aprobación en reuniones o aprobación procedimental como suficiente para crear una obligación operativa universal.
• DEBE permitir que nuevas reglas, extensiones, perfiles o procedimientos se desplieguen de forma incremental por los participantes que deciden ejecutarlos.
• DEBE permitir que los participantes rechacen un cambio posterior sin adquirir un estado de invalidez, siempre que sus propias transiciones de estado cumplan las reglas deterministas de su conjunto de compatibilidad.
• DEBE permitir que los participantes continúen usando un conjunto de compatibilidad anterior cuando la Especificación Inicial permita dicha continuidad.
• DEBE permitir que los participantes que operan en un conjunto de compatibilidad rechacen o ignoren localmente estados de otro conjunto de compatibilidad cuando las reglas sean incompatibles.
• DEBERÍA definir rutas de adopción para cambios importantes, incluyendo señalización de versiones, etiquetado de compatibilidad, guías de transición y vectores de prueba.
• DEBERÍA definir rutas de rechazo para cambios importantes, incluyendo cómo los participantes no adoptantes continúan operando, identifican su conjunto de compatibilidad y evitan interoperabilidad ambigua.
• DEBE garantizar que los artefactos de coordinación necesarios puedan abandonarse, replicarse, reimplementarse o sustituirse sin costos de transición imposibles.
• DEBERÍA hacer que los registros, recomendaciones y artefactos de coordinación describan la realidad adoptada, en lugar de intentar declarar como existente una realidad futura no adoptada.
• NO DEBE diseñar un sistema en el que la única forma de que un cambio se vuelva real sea el reconocimiento previo por un organismo incumbente.

9.2. Superficie de decisión del operador

Lo siguiente DEBERÍA permanecer fuera de la capa común, salvo que altere directamente un Invariante Global declarado:

• momento de despliegue;
• uso comercial;
• geografía de clientes;
• acuerdos de arrendamiento, financiación o transferencia;
• preferencia local de elegibilidad;
• secuenciación operativa;
• práctica de enrutamiento no requerida para la validez compartida;
• modelo de negocio;
• estructura organizativa;
• momento de migración voluntaria;
• perfiles o extensiones opcionales;
• elección de contrapartes.

Los participantes PUEDEN adoptar decisiones diferentes en estas áreas. Dichas decisiones pueden producir distintos conjuntos de compatibilidad, relaciones comerciales, acuerdos de peering o comunidades operativas. No generan invalidez, salvo que violen reglas de validación deterministas dentro de un conjunto de compatibilidad.

9.3. Ciclo de adopción

Cuando sea posible, el orden preferido para cambios sustanciales del sistema es:

• propuesta;
• implementación;
• vectores de prueba o método de verificación determinista;
• despliegue limitado por participantes que lo deseen;
• observación de efectos de interoperabilidad y seguridad;
• etiquetado de conjuntos de compatibilidad;
• documentación o recomendación que describa la realidad adoptada.

Un artefacto de coordinación DEBERÍA seguir a la adopción en lugar de intentar anticiparla.

10. Aplicabilidad y límites

Este patrón de diseño es particularmente aplicable cuando:

• el sistema es multi-actor y multi-jurisdiccional;
• el despliegue independiente es importante;
• la capa de coordinación está destinada a permanecer delgada;
• es probable que exista variación futura pero no pueda predecirse en detalle;
• el bloqueo o dependencia (lock-in) crearía riesgo de gobernanza;
• la validez puede hacerse determinista o verificable localmente;
• el estado distribuido puede reducir el riesgo de captura institucional.

Puede ser menos directamente aplicable cuando:

• se trata de un único dominio administrativo como arquitectura prevista;
• un acoplamiento fuerte en tiempo real requiere comportamiento uniforme en todo momento;
• consideraciones de seguridad vital exigen uniformidad global inmediata;
• la validez no puede verificarse localmente mediante ningún mecanismo práctico.

Incluso en estos casos, los diseñadores DEBERÍAN seguir minimizando la capa común y evitar, en la medida de lo posible, el control discrecional futuro.

11. No objetivos

Este documento no:

• prohíbe toda coordinación;
• requiere ninguna implementación específica de libro mayor distribuido;
• garantiza consenso;
• garantiza neutralidad política;
• exige que todos los participantes adopten cada cambio posterior;
• trata la negativa a adoptar como invalidez;
• legitima comportamiento local incompatible bajo la pretensión de compatibilidad;
• elimina la necesidad de reglas comunes críticas para la seguridad.

12. Consideraciones de seguridad

Una capa de coordinación más delgada puede reducir el riesgo de captura, disminuir el radio de impacto de errores institucionales y mejorar la capacidad de reemplazo. Sin embargo, una mayor discrecionalidad local y un estado distribuido también pueden generar posturas de seguridad inconsistentes, rutas de degradación, presión de fragmentación, afirmaciones ambiguas de compatibilidad, bifurcaciones inseguras, disputas sobre el estado del libro mayor e intentos de falsificación de pruebas.

Por lo tanto, los diseñadores que apliquen este documento DEBEN especificar explícitamente los invariantes de seguridad. En particular:

• los requisitos de autenticación y autorización necesarios para la validez compartida DEBEN ser deterministas y verificables localmente;
• los mecanismos de prueba de control DEBEN resistir la falsificación, la repetición y la transferencia no autorizada;
• la negociación de versiones y el manejo de extensiones DEBEN evitar degradaciones silenciosas cuando la seguridad se vea afectada;
• las rutas de rechazo, bifurcación y sustitución DEBEN analizarse respecto al riesgo de abuso y denegación de servicio;
• las etiquetas de compatibilidad DEBERÍAN ser lo suficientemente claras como para evitar la interoperación accidental entre conjuntos de reglas incompatibles;
• el estado distribuido DEBERÍA ser auditable y reproducible para detectar vistas inconsistentes;
• la variación local NO DEBE poder declarar falsamente compatibilidad con un conjunto de reglas que no cumple.

La existencia de excepciones de seguridad no justifica una capa general de permisos. Solo justifica reglas de seguridad deterministas necesarias para preservar los Invariantes Globales declarados.

Apéndice A. Lista de verificación de diseño

Un diseño que afirme conformidad con este documento DEBERÍA poder responder claramente a las siguientes preguntas:

• ¿Cuáles son los Invariantes Globales?
• ¿Qué reglas de validación deterministas preservan esos Invariantes Globales?
• ¿Qué reglas en la Especificación Inicial son estrictamente necesarias para el primer despliegue?
• ¿Cómo se representa y verifica el estado válido?
• ¿El estado es distribuido, replicado o de otro modo verificable de forma independiente?
• ¿Qué cuestiones futuras se dejan intencionalmente fuera de la capa común?
• ¿Qué decisiones futuras pueden tomar los participantes sin alterar el conjunto de compatibilidad en el que se encuentran?
• ¿Cómo adopta un participante un cambio posterior?
• ¿Cómo rechaza un participante un cambio posterior sin que se le asigne un estado de invalidez?
• ¿Cómo se etiquetan o descubren los conjuntos de compatibilidad?
• ¿Cómo funciona el rechazo local cuando un estado es inválido o incompatible según las reglas que ejecuta un participante?
• ¿Cuál es la ruta de bifurcación?
• ¿Cómo demuestra un titular el control sin un registro incumbente?
• ¿Cómo verifica una contraparte el estado sin un registro?
• ¿Pueden los participantes verificar la validez ordinaria sin depender de un registro incumbente?
• ¿Los registros y artefactos de coordinación describen la realidad adoptada o intentan declarar como existente una realidad futura no adoptada?
• ¿Ha minimizado el sistema el número de decisiones incorporadas en la capa común?
• ¿Ha evitado el sistema cualquier autoridad permanente que determine el estado ordinario de los participantes?
• ¿Pueden los participantes aceptar o rechazar contrapartes de forma voluntaria?
• ¿Puede el sistema continuar si todos los registros incumbentes desaparecen?

Dirección del autor

Lu
[TBD]