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:

1. Nota 52: Cuando el poder del registro se desvincula de la responsabilidad: por qué el modelo actual de coordinación de los RIR no puede sobrevivir en su forma presente
2. Nota 53: Los recursos numéricos de Internet no son propiedad política
3. Nota 56: Cómo la gobernanza densa de los Registros Regionales de Internet convierte la unicidad en una doble extracción
4. Nota 58: De la doble extracción a la inversión de la soberanía: cómo las naciones pierden el control soberano frente a los RIR por 100 dólares estadounidenses
5. Nota 59: La penalización de la pobreza: cómo el modelo de los RIR grava a los pobres mientras lo llama igualdad
6. Nota 61: La traición al código en funcionamiento: cómo el sistema de los RIR volvió el consenso contra la comunidad técnica
7. Nota 62: Blanqueo de mandato: de la fantasía de los RIR a una arquitectura de transición

Los siete ensayos anteriores no eran un programa de reforma para los Registros Regionales de Internet. Eran una autopsia. Rastrearon la misma patología institucional a través de distintas capas: la responsabilidad separada de las consecuencias; los recursos numéricos rebautizados como propiedad política; la unicidad convertida en doble extracción; la soberanía invertida; la pobreza gravada en nombre de la igualdad; el consenso vuelto contra las redes a las que debía servir; y, finalmente, el mandato blanqueado hasta que un escribiente empezó a sonar como un soberano. La secuencia importa porque el fallo no fue un mal consejo de administración, un mal registro, una demanda o un acontecimiento incómodo del mercado. Fue un defecto del sistema que aparecía con distintos disfraces. La página de autor de CircleID muestra ahora claramente esa secuencia, incluidos 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 consiste en añadir un complemento al diseño técnico original de Internet. Ese complemento es la Primacía del Código en Funcionamiento. La necesidad ya no es teórica. En un reciente intercambio en CircleID, John Curran presentó la versión más sólida del argumento de las instituciones establecidas. Su tesis es que la autoridad del sistema de los RIR no es simplemente un subproducto de una coordinación técnica limitada, sino el resultado de una cadena histórica: el Libro Blanco, ICANN, la ASO, ICP-2, la transición de la custodia de la IANA y la continuidad de la gobernanza multilateral del sector privado. Afirma que la autoridad del sistema de los RIR deriva de operar dentro del modelo multilateral del sector privado que impulsó el Gobierno de Estados Unidos. (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 delegada históricamente puede después ampliarse hasta convertirse en un mandato permanente de gobernanza mediante la misma maquinaria procedimental que controla. La respuesta institucional es afirmativa: la delegación, el reconocimiento, la continuidad institucional y el procedimiento comunitario se convierten en un mandato que se renueva a sí mismo. La respuesta exigida por el diseño técnico original de Internet es negativa. La tradición original de Internet era más limitada, más exigente y mejor. El RFC 3935 dice que el objetivo de la IETF es «hacer que Internet funcione mejor»; fundamenta el trabajo en la competencia técnica, la implementación en el mundo real y el «consenso aproximado y código en funcionamiento». También afirma que, cuando la IETF no es responsable de un protocolo o una función, no intenta ejercer control sobre ellos. (rfc-editor.org) El RFC 7282 repite la antigua frase de David Clark: «Rechazamos: reyes, presidentes y votaciones» y «Creemos en: consenso aproximado y código en funcionamiento». (rfc-editor.org) El RFC 9592 formula aún con mayor claridad el principio antisoberano: la 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 los sistemas a funcionar. Significaba que el proceso se toleraba porque servía al despliegue. Significaba que una sala era útil solo cuando se disciplinaba en torno a la realidad operativa. 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 Funcionamiento

La Primacía del Código en Funcionamiento significa que los sistemas de coordinación de Internet deben interpretarse de forma restrictiva, atendiendo a la función técnica mínima que justificó originalmente la existencia de las redes en funcionamiento. La capa de recursos numéricos existe para proteger los sistemas en funcionamiento: unicidad, interoperabilidad, continuidad vinculada al encaminamiento, afirmaciones de seguridad, prueba de control y la semántica común mínima necesaria para que redes independientes trabajen juntas. No existe para fabricar autoridad política. No existe para vigilar la moral comercial. No existe para convertir la geografía de servicio en un título de propiedad. No existe para transformar una lista de correo en una asamblea legislativa. No existe para permitir que un registro privado haga desaparecer activos de redes ya operativas porque cambie su teoría interna de política. Un registro no es un Estado. Un contacto de base de datos no es un poder notarial corporativo. Una región de servicio no es un pueblo. Una sala de elaboración de políticas no es una asamblea legislativa. Un registro puede describir la realidad operativa. No la crea. Esto no es conservadurismo. La Primacía del Código en Funcionamiento no afirma que los sistemas desplegados nunca puedan cambiar. Afirma que el poder institucional sobre el cambio no debe justificarse mediante una delegación histórica, un reconocimiento circular o un procedimiento ritual. Debe justificarse mediante reglas deterministas que los operadores puedan verificar localmente y mediante su adopción en sistemas en funcionamiento. El orden correcto es: especificación inicial, estado de libro mayor distribuido, validación local, implementación operativa, adopción voluntaria, conjunto de compatibilidad y, después, documentación. El orden incorrecto es: sala de políticas, declaración, obligación proclamada, etiqueta de cumplimiento y cumplimiento operativo forzado. El sistema de los 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 permanente a la que solicitar 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 niegue a aceptar un cambio posterior. Solo existen código, estado de libro mayor, validación, adopción, compatibilidad, rechazo local, bifurcación e interoperación selectiva. Un operador que rechaza un cambio posterior no rompe Internet. Puede permanecer en un conjunto de compatibilidad anterior. 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 los libros mayores distribuidos: no se necesita una institución permanente para decidir la validez ordinaria. Los participantes validan localmente las transiciones de estado con 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 los recursos numéricos.

El fallo de diseño estaba presente desde el principio

El primer diseño de los RIR suponía un mundo de bajo valor. Los recursos numéricos parecían técnicos, abundantes, administrativos y poco conflictivos. 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 inocuos. Un registro regional podía parecer una libreta de direcciones. La escasez de IPv4 destruyó esa premisa. Las direcciones IPv4 se volvieron escasas, transferibles, financiables, arrendables, capitalizables, litigiosas, sancionables e integradas en redes activas. La capa registral ya no se situaba sobre simples anotaciones administrativas. Se situaba sobre infraestructura productiva. Se situaba sobre valor patrimonial. Se situaba sobre continuidad de clientes, despliegues en la nube, operaciones de telecomunicaciones, conectividad nacional, resoluciones judiciales y asignación de capital. La forma institucional no se contrajo para adaptarse al nuevo riesgo. Se expandió. El resultado es un sistema que todavía habla el lenguaje de la coordinación técnica mientras produce los efectos de una gobernanza de infraestructuras. Pide a los operadores que traten el proceso registral como neutral, mientras las decisiones del registro afectan a su destino comercial. Llama «comunidad» a sus participantes, aunque muchas de las personas que soportan las consecuencias nunca otorgaron una representación jurídica clara a quienes están en la sala. NRS expone con claridad el problema estructural: los registros de recursos numéricos de Internet fueron diseñados como organismos de coordinación técnica, pero cuando la escasez de IPv4 convirtió las direcciones en activos valiosos, la discrecionalidad registral 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 ingeniería de sistemas, no ideología. NRS también plantea la dirección de diseño opuesta: una sola Internet, infraestructura abierta y autónoma y gobernanza descentralizada con una participación humana mínima en su núcleo. (nrs.help) Ese es el verdadero problema. La capa registral nunca se actualizó 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 Funcionamiento es ese parche. No es una doctrina para mejorar los RIR. Es una disciplina posterior a los RIR.

Las tres reglas del parche

La gramática constructiva es la versión revisada de la Nota 64: 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 no cambian. 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 protección compartida y la seguridad. No contiene preferencias sobre modelos de negocio, teorías de fijación de precios, sentimientos políticos regionales, poderes discrecionales de ejecución 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 por adelantado el trabajo de limitación. Después del despliegue, las decisiones futuras ordinarias permanecen en manos de los participantes que ejecutan código. Un participante puede adoptar, rechazar, bifurcarse, desconectarse o interoperar selectivamente. Ningún participante puede alterar la interoperabilidad de otros que sigan ejecutando reglas mutuamente compatibles. Adopción Voluntaria significa que un cambio posterior solo se vuelve real mediante su implementación, validación, despliegue y uso. La publicación no es la realidad. La recomendación no es la realidad. El reconocimiento institucional no es la 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 un estado inválido según las reglas deterministas de otro puede ser ignorado localmente. El efecto es una selección de compatibilidad, no un castigo institucional. Estas tres reglas no rehabilitan la soberanía registral. Impiden que reaparezca con otro nombre.

APNIC: la estructura jurídica era el riesgo

APNIC muestra el primer fallo: el mínimo nunca se definió con suficiente firmeza desde el principio. Esta no es una historia sobre códigos de conducta. No es una historia sobre etiqueta. No es una historia sobre si un crítico fue suficientemente educado con una institución establecida. Es una historia sobre estructura jurídica. En marzo de 2023, LARUS publicó un análisis jurídico que advertía de que la estructura de gobernanza de APNIC creaba un riesgo no solo para una empresa en Brisbane, sino para la gobernanza de Internet en toda la región de Asia-Pacífico. El análisis afirmaba que el director general de APNIC tenía la potestad jurídica última para cerrar APNIC y destituir al Consejo Ejecutivo elegido, y que se necesitaban modificaciones urgentes de la gobernanza. También indicaba que esa estructura planteaba dudas sobre la seguridad de la gobernanza de Internet para más de mil millones de usuarios de Internet de Asia-Pacífico. (larus.net) El primer documento adjunto, el extracto societario de ASIC, aporta la base corporativa. APNIC Pty Ltd figuraba como sociedad australiana privada limitada por acciones, registrada en Queensland. Paul Byron Wilson aparecía como administrador y secretario. La información accionarial mostraba una única acción ordinaria emitida y a Paul Byron Wilson como socio 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 documento adjunto, el dictamen jurídico del Dr. Peter Felter, extrajo la conclusión de gobernanza. Describía 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. Afirmaba que APNIC Pty Ltd había sido durante 25 años una sociedad privada controlada por un administrador, un accionista y un secretario, todos ellos la misma persona. (larus.net) Esa distinción importa. La institución pública orientada a la comunidad no era el contenedor jurídico final. Era una construcción levantada sobre una sociedad privada. El dictamen explicaba entonces por qué la distinción importaba. Afirmaba que los estatutos internos de APNIC estaban sujetos a los estatutos sociales y a las facultades de la sociedad y de sus administradores, directivos y socios. Según esa interpretación, la estructura pública de APNIC podía modificarse mediante una resolución del administrador de APNIC Pty Ltd; el dictamen describía APNIC, en la práctica, como un departamento de APNIC Pty Ltd. (larus.net) El punto más perjudicial del dictamen no era que APNIC fuera técnicamente ilegal. Era que legalidad y legitimidad no son lo mismo. El dictamen sostenía que el acuerdo fiduciario no resolvía el problema, porque las facultades del Consejo Ejecutivo seguían derivando de la resolución del administrador que había creado el comité especial. También observaba que APNIC Pty Ltd era una sociedad privada por acciones cuya estructura y objetivos no se parecían al modelo de entidad sin acciones y sin ánimo de lucro que la mayoría de las personas asociaría con un registro regional de interés público. (larus.net) Ese es el primer fallo de diseño en su forma más clara. Un sistema de coordinación de recursos numéricos a escala regional no debería depender de una estructura que requiera abogados para explicar cómo una sociedad privada con una sola acción, un comité especial, una escritura fiduciaria y un consejo elegido se combinan para constituir un control legítimo del registro numérico de Asia-Pacífico. Una capa crítica de coordinación debería ser comprensible desde fuera. No debería exigir confianza en documentos ocultos detrás de otros documentos. No debería obligar a los miembros a descubrir, después de años de dependencia institucional, que la capa elegida puede no ser la capa jurídica definitiva. No debería aparentar una gobernanza de los miembros mientras deja el poder formal 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 una mejor gobernanza, sino porque un sistema post-RIR debe evitar necesitar esa institución. La capa común no debería depender de la estructura de control oculta de una sociedad privada. Debería definir reglas deterministas de validación, un estado de prueba de control, reglas de transición de estado, reglas de conflicto, replicación del libro mayor, rutas de salida, rutas de bifurcación y conjuntos de compatibilidad. Si APNIC desaparece, se captura a sí misma, modifica su postura jurídica o se niega a reconocer un estado válido, la red operativa no debería depender del reconocimiento continuado 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 conforme a la especificación inicial.

ARIN: cuando la política se encontró con la realidad patrimonial

ARIN muestra el segundo fallo: la realidad jurídica y del mercado puede adelantarse a la teoría registral. El acontecimiento decisivo fue la operación Nortel/Microsoft. Cuando Nortel se declaró en quiebra, sus 666.624 direcciones IPv4 se convirtieron en activos valiosos dentro del procedimiento. Las direcciones se vendieron a Microsoft por 7,5 millones de dólares. ARIN intervino sosteniendo que las direcciones no eran propiedad y que no podían venderse libres de la política registral. Industry Canada respaldó esa postura. El tribunal concursal la rechazó; Microsoft firmó posteriormente un acuerdo sobre recursos heredados; y el resultado práctico fue claro: la política del registro ya no podía seguir siendo la única fuente de realidad una vez que tribunales y mercados trataban los recursos numéricos como activos. (btw.media) La lección importante no es que ARIN fuera excepcionalmente defectuoso. La lección es que la capa registral había entrado en una categoría nueva. Un asiento registral es valioso porque operadores, tribunales, compradores, vendedores, acreedores y redes confían en él. No se vuelve autoritativo negando esa confianza. Solo sigue siendo útil si refleja la realidad jurídica, comercial y operativa con suficiente fidelidad como para merecer confianza. Cuando IPv4 se volvió escaso, el proceso registral se convirtió en una interfaz de mercado. Las reglas de transferencia, las evaluaciones de necesidad, los retrasos de reconocimiento y las restricciones regionales dejaron de ser detalles administrativos. Se convirtieron en fricciones sobre los activos. Los análisis públicos describen ahora un marco fragmentado entre los RIR, en el que cinco sistemas regionales gobiernan un mercado que negocia aproximadamente entre 18 y 45 dólares por dirección, con normas incompatibles capaces de inmovilizar activos, retrasar fusiones y obligar a crear estructuras societarias separadas únicamente para mantener bloques numéricos. (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 registral solo sigue siendo creíble mientras describe lo que los actores implementan, intercambian, financian, litigan y utilizan realmente. Se vuelve peligrosa cuando se considera que la publicación basta para fabricar la realidad. Un registro que se niega a aceptar 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 Funcionamiento, la lección es aún más clara. Los tribunales y los mercados no necesitan que un registro establecido decida si existe valor. Los operadores no necesitan un comité para saber si un bloque se encamina. Los participantes necesitan reglas deterministas que permitan demostrar el control, resolver conflictos, realizar transiciones de estado visibles en el libro mayor y mantener la compatibilidad. El antiguo registro puede publicar una opinión. Un cliente de software puede mostrar una opinión. Un explorador del libro mayor puede mostrar una opinión. Ninguno es la fuente de validez. No existe un registro al que trasladarse. No existe un registro al que preguntar. Solo existe un estado distribuido que los participantes validan, aceptan, rechazan, del que se bifurcan o con el que interoperan.

AFRINIC: cuando la teoría registral amenazó activos en funcionamiento

AFRINIC es el caso central porque redujo el problema a sus elementos esenciales. La historia equivocada dice que un miembro problemático paralizó un registro regional. Ese es el relato moral de las instituciones establecidas. La historia estructural es distinta. AFRINIC intentó convertir el uso comercial, la geografía de los clientes, el arrendamiento, la relación de afiliación y su propia interpretación interna de las políticas en un supuesto poder para cancelar el registro de recursos numéricos ya operativos. Una vez formulada esa pretensión, el conflicto ya no podía seguir siendo un desacuerdo en una sala de políticas. Se convirtió en una prueba de si un registro privado podía utilizar retórica regional y silencios normativos para amenazar activos integrados en operaciones reales. Los hechos no requieren exageración teatral. La información pública describió la disputa de AFRINIC como un simple litigio comercial sobre direcciones IP que se convirtió en la mayor historia de gobernanza de Internet en África. También señaló que Cloud Innovation había sido presentada a menudo como la parte culpable, mientras que documentación posterior apuntaba a fuerzas destructivas dentro de la propia AFRINIC y a litigios retrasados, prolongados y continuados por representantes de AFRINIC a costa de AFRINIC. (btw.media) Eso importa porque invierte el relato habitual. El litigio no creó el fallo estructural. Lo expuso. El fallo relevante ya estaba presente cuando un registro privado trató la ausencia de autorización expresa como fundamento de control coercitivo. El arrendamiento no era una amenaza para la unicidad. La geografía de los clientes no era una asignación duplicada. El uso comercial no era un fallo de seguridad del encaminamiento. Un modelo de negocio que disgustara al registro no era un invariante global. Sin embargo, la pretensión registral colocó todas esas cuestiones dentro de un marco de revocación. Ese es el momento en que la coordinación se convierte en gobernanza. La información publicada indica que AFRINIC envió a Cloud Innovation una carta en marzo de 2021 alegando incumplimientos de políticas y amenazando con terminar su condición de miembro; que en julio de 2021 el Tribunal Supremo de Mauricio prohibió a AFRINIC poner fin a dicha condición; y que otro intento de AFRINIC de cancelar la afiliación fue bloqueado en diciembre de 2021. (btw.media) Esa secuencia no describe a un registro protegiendo serenamente Internet. Describe la autoridad registral encontrándose con el Derecho ordinario. Tampoco el deterioro institucional más amplio se debió a que el registro tuviera demasiado poco poder. El problema más profundo era el bloqueo. Si un registro monopoliza el reconocimiento de activos valiosos y operativos, cada fallo interno se convierte en un riesgo para la continuidad de Internet. Si los miembros no pueden abandonar el sistema de reconocimiento, el fallo del registro se convierte en poder de rehén. Un registro puede corregir un fraude demostrable en sus propios datos. Puede impedir una asignación duplicada mientras el modelo registral siga existiendo. Puede mantener afirmaciones de seguridad mientras los participantes continúen dependiendo de él. Pero esas son funciones transitorias de una arquitectura antigua. En una arquitectura post-RIR, esas funciones no las desempeña un registro. Se codifican en el estado de un libro mayor distribuido, en 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 los clientes en motivo de revocación. No debería tratar una discrepancia comercial como invalidez técnica. No debería convertir la continuidad de un activo en permiso. AFRINIC demuestra la necesidad de una Decisión Futura Localizada entendida correctamente. No hay un organismo central que decida que una futura decisión comercial «pertenece al ámbito local». La especificación inicial debe garantizar que esas decisiones nunca entren en la capa común. El arrendamiento, la geografía de los clientes, el uso comercial, el precio, la financiación, la combinación de clientes y la estrategia de despliegue quedan fuera de las reglas deterministas de validez, salvo 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 por arrendar direcciones. Un operador no puede romper la interoperabilidad de otros operadores por atender a clientes fuera de una región registral histórica. Un operador no puede romper la interoperabilidad de otros operadores por usar un modelo de negocio que desagrade a un registro. Como máximo, un operador puede incumplir reglas deterministas que ejecutan otros participantes. En ese caso, estos rechazan localmente el estado inválido. No existe una capa de castigo. No existe un tribunal de cumplimiento. No existe un soberano regional. Esa línea no es ideológica. Es operativa.

El problema de la representación no es un detalle

La controversia electoral de AFRINIC hizo visible un segundo defecto: la representación. NRS formula su base representativa en términos jurídicos directos. Afirma que los miembros enumerados encomendaron a NRS su representación en asuntos de gobernanza de los RIR y que cada miembro aportó un poder notarial. (nrs.help) Durante la disputa electoral de AFRINIC, NRS pidió a los miembros que informaran si sus nombres aparecían en los registros de votantes o si se habían contabilizado votos sin su participación, y afirmó que esas comunicaciones fácticas serían tratadas por cauces legales. (nrs.help) Eso importa porque muestra la diferencia entre representación jurídica y retórica comunitaria. El sistema de los RIR suele mezclar varias categorías: representante societario, contacto de base de datos, contacto técnico, empleado, consultor, apoderado, participante en políticas y habitual de una lista de correo. No son lo mismo. Un contacto de base de datos puede ayudar a administrar registros. Un poder notarial puede autorizar representación si es válido y se utiliza dentro de su ámbito. Un participante en políticas puede aportar experiencia. Una persona en una lista de correo puede expresar una opinión. Ninguno se convierte automáticamente en representante jurídico de todas las empresas, clientes, Estados, acreedores, prestamistas, compradores, arrendatarios o redes que soportan las consecuencias de una decisión registral. Esa distinción solo puede ignorarse mientras la capa común siga siendo limitada. Cuando el registro reclama poder sobre revocación, transferencia, arrendamiento, acceso al mercado, tratamiento de sanciones, continuidad patrimonial o riesgo para infraestructuras nacionales, la representación se vuelve constitucional. Una sala no es un mandato. Una lista de correo no es un pueblo. Un registro de contacto no es un poder notarial corporativo. Una región de servicio no es una circunscripción soberana. No es una cuestión de formalismo procedimental. Es la diferencia entre coordinación y gobierno. Un sistema de Primacía del Código en Funcionamiento evita esta trampa reduciendo el número de decisiones que requieren representación. Si la validez es determinista y local, hay menos asuntos sobre los que votar. Si el cambio futuro es voluntario, no hace falta decidir si quien no adopta está incumpliendo. Si el estado se representa en un libro mayor distribuido, no es necesario suplicar a un registro establecido que reconozca la continuidad de la propia existencia. Si los conjuntos de compatibilidad son explícitos, los participantes saben con quién pueden interoperar sin preguntar a una sala política. El mejor problema de gobernanza es el que elimina el diseño del sistema.

RIPE NCC y LACNIC: el club y el punto de estrangulamiento

RIPE NCC y LACNIC no demuestran que algunos RIR sean más civilizados que otros. Demuestran que el modelo RIR dispone de dos capas de ejecución adicionales a la función técnica: el club y el punto de estrangulamiento. El club decide quién es respetable. El punto de estrangulamiento decide qué estado registral puede moverse. El rechazo de RIPE NCC al patrocinio de LARUS para RIPE 90 mostró claramente la capa del club. Un miembro ofreció patrocinio. El ecosistema registral lo rechazó por una disputa no relacionada en otra región. No fue una decisión sobre seguridad de encaminamiento. No fue una decisión sobre unicidad. No fue una regla determinista de validación. Fue una inclusión privada en una lista negra mediante el control del acceso a conferencias. LACNIC también rechazó mi patrocinio. Región distinta, mismo instinto: el club registral se protege controlando salas, visibilidad, patrocinios, reputación y legitimidad social. Eso no es comunidad. Es control de acceso. La capa de sanciones es peor porque muestra el punto de estrangulamiento central en forma jurídica. RIPE NCC afirma que, por estar radicado en los Países Bajos, debe cumplir las sanciones de la Unión Europea; cuando se aplican sanciones, congela los registros en la base de datos de RIPE, bloquea adquisiciones y transferencias y puede considerar un expediente congelado cuando una parte no aporta documentación suficiente. También consulta las listas de OFAC porque sus relaciones bancarias afectan a los pagos. (Transparencia de RIPE NCC sobre sanciones) Esto no es una crítica a RIPE NCC por cumplir la ley. Una entidad neerlandesa debe cumplir el Derecho neerlandés y de la UE. El problema es arquitectónico: ¿por qué una única entidad privada neerlandesa debería ser el punto central de reconocimiento para la movilidad de recursos numéricos entre muchos países, operadores y sistemas jurídicos? Las sanciones pueden obligar a un banco. Pueden obligar a una entidad neerlandesa. Pueden obligar a una contraparte que decida no contratar. No deberían convertirse en una condición global de validez técnica para todos los demás. Ese es el fallo de diseño. La misma centralidad que permite a un club excluir a un crítico también permite a una jurisdicción congelar la movilidad registral. Uno es ejecución social. El otro, ejecución jurídica. Ambos funcionan únicamente porque el registro ocupa el lugar en el que no debería residir la validez. Esto conecta directamente con los tres principios. Especificación Inicial Mínima: la respetabilidad dentro del club, la elegibilidad para patrocinio, la política regional, la clasificación sancionadora y la reputación nunca deben entrar en la capa común. Esta solo debe contener reglas deterministas sobre unicidad, prueba de control, tratamiento de conflictos, transición de estado y seguridad. Decisión Futura Localizada: el riesgo jurídico, la elección de contraparte, el patrocinio, la confianza comercial y la exposición a sanciones pertenecen a los actores que los soportan. Una entidad neerlandesa puede rechazar una transacción. Un banco puede rechazar un pago. Una contraparte puede negarse a contratar. Nada de ello debería convertirse en verdad registral universal. Adopción Voluntaria: los participantes aceptan contrapartes ejecutando código, validando el estado y eligiendo con quién interoperar. La no adopción no es una conducta indebida. El rechazo local no es invalidez global. La negativa de un club no debería borrar un estado válido. Una obligación sancionadora debería limitar al actor sujeto a ella, no reescribir el libro mayor mundial de recursos numéricos. Por eso es necesario un diseño de libro mayor distribuido. En un sistema post-RIR, la validez ordinaria no la decide RIPE NCC, LACNIC, un departamento de sanciones, un comité de reunión o una oficina de patrocinios. Los participantes validan localmente el estado. Las contrapartes aceptan o rechazan voluntariamente. Las bifurcaciones son visibles. Los conjuntos de compatibilidad son explícitos. El registro central desaparece como fuente de verdad. La solución no es una mejor etiqueta. La solución no es una cola de sanciones más transparente. La solución es retirar la validez tanto del club como del punto de estrangulamiento. Estado distribuido. Validación local. Aceptación voluntaria de contrapartes. Ningún registro como fuente de validez.

La carta de la NRO: huida hacia arriba

La prueba más grave no es el intento de extralimitación 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 coordinador de los RIR del mundo y afirmaba que los RIR administraban recursos numéricos en sus respectivas regiones. Indicaba que los cinco registros desempeñaban esa función conforme a normas adoptadas regionalmente o políticas globales adoptadas por unanimidad. (nro.net) La misma carta criticaba los litigios de Cloud Innovation, afirmaba que se habían presentado más de 25 demandas, se quejaba de resoluciones judiciales que habían congelado las cuentas de AFRINIC y detenido elecciones, y señalaba que AFRINIC había pedido repetidamente a Mauricio que la reconociera como 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 chocó con tribunales ordinarios, el reflejo del sistema no fue limitar el mandato. No fue eliminar el bloqueo registral. No fue separar el mantenimiento de registros de la ejecución. No fue definir una validación distribuida. No fue preguntar si el poder unilateral de cancelar recursos operativos había sido ilegítimo desde el principio. El reflejo fue huir hacia arriba. Un organismo privado de coordinación no puede ser técnico cuando quiere discrecionalidad, comunitario cuando quiere legitimidad, contractual cuando quiere cobrar tasas, contrario a la propiedad cuando quiere evitar la responsabilidad propia de un propietario y cuasiinternacional cuando quiere aislarse de los tribunales. Ese paquete no es gobernanza. Es blanqueo de mandato a escala del sistema. Si los RIR quieren privilegios de Derecho público, deben aceptar responsabilidad de Derecho público. Si quieren flexibilidad de Derecho privado, deben aceptar litigios de Derecho privado. Lo que no pueden exigir racionalmente al mismo tiempo es discrecionalidad privada, importancia de infraestructura pública, baja responsabilidad, representación débil, condición monopolística y aislamiento cuasidiplomático. Ese es el camino al desastre. La Primacía del Código en Funcionamiento lo rechaza. Cuando un registro encuentra resistencia jurídica, no debe escapar hacia arriba buscando inmunidad. La arquitectura debe contraerse hacia abajo, hasta la limitada función de código en funcionamiento que lo justificaba. 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 sabe 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 afirma que la propuesta establecería reglas y criterios para reconocer nuevos RIR, obligaciones y requisitos operativos de los RIR y reglas de retirada del reconocimiento; si se adopta, sustituiría a ICP-2. La misma página señala que el proceso se inició después de que la NRO pidiera a la ASO que propusiera actualizaciones para dar al sistema de los RIR una 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 retirada del reconocimiento responden a una pregunta tardía: ¿cuándo ha fallado un registro de forma tan grave que debe ser retirado? La pregunta anterior es más importante: ¿por qué debería un registro tener suficiente poder como para poder fracasar catastróficamente? Un sucesor de ICP-2 que solo refuerce el reconocimiento, la auditoría, el relevo y la retirada del reconocimiento puede mejorar la higiene institucional manteniendo el error de categoría. Sigue suponiendo que el RIR es la forma soberana principal de coordinación de recursos numéricos. La Primacía del Código en Funcionamiento plantea preguntas distintas. ¿Cómo continúa Internet si un RIR colapsa? ¿Cómo siguen siendo verificables las reclamaciones sobre recursos numéricos sin permiso de la institución establecida? ¿Cómo sobrevive la unicidad sin discrecionalidad monopolística? ¿Cómo se impide que los registros se conviertan en armas de ejecución? ¿Cómo se mantienen las decisiones comerciales fuera de la validez determinista, salvo que esté en riesgo un verdadero invariante global? ¿Cómo puede seguir siendo utilizable la coordinación sin ningún registro autoritativo? ¿Cómo valida un operador un estado ordinario sin pedir su estatus a un organismo permanente? ¿Cómo se evita que el rechazo se convierta en una etiqueta de infracción? No son preguntas de reforma. Son preguntas post-RIR.

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

La cuestión no es si gustan o disgustan los registros establecidos. La cuestión es si la capa de recursos numéricos sigue respetando la disciplina de diseño que hizo funcionar Internet: reglas comunes mínimas, validación local, adopción voluntaria y código en funcionamiento. La Primacía del Código en Funcionamiento no es una estrategia de relaciones públicas ni un compromiso institucional. Es la reparación técnica que implica el diseño original. Si Internet se construyó para rechazar reyes, presidentes y votaciones como fuentes de verdad técnica, la capa de recursos numéricos no puede recrear esas formas mediante procedimientos registrales, delegación histórica o teatro comunitario. El consenso por sí solo puede ritualizarse. El código en funcionamiento también puede subordinarse si la capa registral se sitúa por encima del 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, prevalece el código en funcionamiento; y cuando se propone un cambio posterior, este solo se vuelve real mediante la adopción voluntaria de participantes que ejecutan reglas de validación. Así se conserva el diseño original, no se abandona. Internet importó porque se convirtió en el primer sistema mundial de comunicaciones que no exigía permiso previo de un único soberano, ministerio, iglesia, empresa o guardián. Si ese logro aún merece defensa, la capa registral no puede convertirse en la excepción que devora la regla. Un sistema construido para evitar reyes no puede permitir que un tenedor de libros se presente al puesto. El parche restaura la jerarquía original: primero el código, primero los operadores, primero la validación determinista, primero el estado distribuido; las instituciones, si alguna permanece 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 limitada, objetiva, determinista y distribuida que el monopolio actual de los RIR. No existe un registro al que trasladarse. No existe un nuevo registro al que coronar. No existe un sacerdocio sustituto. Existe un libro mayor distribuido del estado de los recursos numéricos, con reglas deterministas de validación, mecanismos de prueba de control, tratamiento de conflictos, conjuntos de compatibilidad, historial de transiciones de estado y verificación local por los participantes. La capa común debería preservar la unicidad de los identificadores, la prueba de control, el estado de las transferencias, el estado de las delegaciones, las afirmaciones de seguridad relacionadas con el encaminamiento, la auditabilidad, los metadatos de conflicto y la visibilidad de las bifurcaciones. La capa del operador debería controlar el uso comercial, el arrendamiento, la geografía de los clientes, las prácticas de encaminamiento, la financiación, la elección de contrapartes y las reglas empresariales que no sean invariantes. La capa de adopción debería decidir 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 comprenderla y se mantiene la interoperabilidad sin convertir el reconocimiento institucional 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 el estado. Puede validar transiciones. Puede mostrar conflictos. Puede hacer portátil la prueba. No debe convertirse a la vez 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, portabilidad no significa trasladarse de un registro a otro. Eso sigue siendo pensamiento registral. No hay ningún registro al que trasladarse. La prueba de control del titular, el historial de estado y la capacidad de transferencia no quedan atrapados en una base de datos institucional. Existen en un estado compartido y verificable que los participantes validan localmente y las contrapartes aceptan voluntariamente. Sin eso, cada registro es un punto de bloqueo. Con ello, el registro desaparece como fuente de validez. La coordinación post-RIR necesita, por tanto, cuatro propiedades de diseño. Primero, validez determinista. Un participante debería saber si una transición de estado, prueba, delegación, transferencia o afirmación es válida aplicando localmente la especificación. Segundo, conjuntos de compatibilidad. Si los participantes adoptan reglas futuras distintas, el sistema debería describir claramente el límite de compatibilidad en vez de tratar la discrepancia como una conducta indebida. Tercero, prueba de control distribuida. Un titular no debería «trasladar» sus recursos a otro registro; debería demostrar el control mediante un estado válido del libro mayor que cualquier contraparte pueda verificar sin la bendición del registro establecido. Cuarto, visibilidad de las bifurcaciones. Si divergen los conjuntos de reglas, la divergencia debe ser explícita. Los participantes deciden qué conjunto de compatibilidad ejecutar y qué contrapartes aceptar. Una bifurcación puede aislar participantes. No otorga a una parte poder institucional para borrar a la otra. No es un argumento a favor de cinco monopolios mejores. Es un argumento contra el monopolio como fuente de validez.

Por qué la vía del fracaso es previsible

Si nada cambia, la vía del fracaso está clara. Primero, más disputas pasarán de las salas de políticas a los tribunales. Los activos escasos atraen escrutinio jurídico. Se pedirá a los tribunales que congelen cuentas, conserven registros, bloqueen elecciones improcedentes, nombren administradores, reconozcan transferencias o determinen quién puede actuar por un registro. Segundo, los Estados dejarán de tratar a los RIR como asociaciones técnicas inocuas. La continuidad de la numeración afecta a la conectividad nacional, las sanciones, la aplicación de la ley, la resiliencia de las telecomunicaciones, la infraestructura en la nube y la seguridad económica. Ningún Estado aceptará para siempre que una estructura registral privada extranjera sea el punto superior no examinado de la continuidad nacional de las comunicaciones. Tercero, los operadores evitarán la autoridad registral cuando puedan. Si los registros se vuelven políticos, inseguros, no representativos o desconectados de la realidad patrimonial, los operadores recurrirán a contratos privados, transferencias respaldadas por litigios, acreditaciones alternativas, reconocimiento nacional o la realidad de hecho del encaminamiento. Cuarto, ICANN y la capa de la NRO sentirán la tentación de centralizar. Eso produciría una versión más densa del mismo problema, salvo que también se reduzca el mandato. Quinto, los gobiernos sentirán la tentación de nacionalizar. Sería previsible y peligroso. Si registros privados reclaman autoridad cuasisoberana sin responsabilidad pública, los Estados acabarán recuperando soberanía. El resultado podría ser fragmentación, represalias, registros contradictorios y presión política sobre el encaminamiento. Internet no fracasa únicamente cuando dejan de circular paquetes. También fracasa cuando las instituciones que describen quién puede usar identificadores pierden la confianza de los operadores que mueven los paquetes. Un libro mayor distribuido no resuelve todos los problemas políticos. Hace algo más importante: elimina al registro permanente como fuente ordinaria de validez. Reduce la superficie de ataque. Reduce el poder institucional de rehén. Convierte los desacuerdos futuros en selección de compatibilidad en vez de guerra administrativa.

La pregunta cambia

El antiguo sistema pregunta: ¿quién tiene el mandato? Esa es la pregunta equivocada. La mejor pregunta es: ¿qué necesita realmente el código en funcionamiento? ¿Esta regla protege la unicidad? ¿Preserva la interoperabilidad? ¿Corrige un fraude registral demostrable mediante pruebas deterministas? ¿Protege la seguridad vinculada al encaminamiento? ¿Mantiene la exactitud de la prueba de control? ¿Permite la validación local? ¿Elimina la dependencia de una única institución establecida? ¿Describe una realidad adoptada o declara una obligación no adoptada? ¿Puede un participante rechazarla sin recibir un estado de invalidez? ¿Puede un participante verificar la validez ordinaria sin preguntar a un registro por su estado? ¿Puede una contraparte aceptar o rechazar voluntariamente el estado? ¿Puede producirse una bifurcación sin que una institución borre a una de las partes? Si la respuesta no está vinculada a una necesidad determinista del código en funcionamiento, el poder no debería residir en la capa común. Eso es la Primacía del Código en Funcionamiento.

Para debate

Esta propuesta se presenta para debate. No es una solución definitiva. El siguiente paso debería ser un Internet-Draft serio o un documento de tipo BCP que defina la Primacía del Código en Funcionamiento para sistemas de coordinación de Internet, empezando por los recursos numéricos. El borrador no debería preguntar cómo rehabilitar el monopolio de los RIR. Debería preguntar cómo construir una coordinación post-RIR mediante un estado de libro mayor distribuido, validación determinista, adopción voluntaria, aceptación de contrapartes y conjuntos de compatibilidad explícitos. Debería ser sometido a prueba por operadores, juristas, economistas, ingenieros de protocolos, expertos en seguridad de encaminamiento, participantes del mercado, gobiernos y críticos. El borrador debería plantear preguntas difíciles. ¿Cuáles son los invariantes globales? ¿Qué reglas de validación son deterministas? ¿Qué transiciones de estado deben ser visibles globalmente? ¿Qué antiguos poderes registrales son residuos históricos? ¿Qué decisiones pertenecen a los operadores? ¿Qué decisiones no requieren representación porque nunca deberían entrar en la capa común? ¿Cuál es la vía de rechazo? ¿Cuál es la vía de bifurcación? ¿Cuál es la vía de rechazo local? ¿Cómo demuestra un titular el control sin un registro establecido? ¿Cómo verifica una contraparte el estado sin un registro? ¿Puede continuar Internet si colapsa un RIR? ¿Pueden los recursos numéricos seguir siendo únicos sin permiso institucional? ¿Puede un participante validar el estado ordinario sin una institución permanente? ¿Puede un proceso de políticas distinguir un invariante de código en funcionamiento del apetito institucional? ¿Puede desaparecer la antigua capa registral sin perder el estado verificable? ¿Puede un registro describir la realidad sin convertirse en soberano sobre ella? Cualquier persona interesada puede ponerse en contacto conmigo a través de LinkedIn. Los investigadores serios, autores técnicos, instituciones o expertos en políticas que quieran ayudar a convertir esta idea en un primer Internet-Draft y, finalmente, en un debate sobre un RFC o una BCP, si la comunidad lo considera útil, deberían ponerse en contacto conmigo. La LARUS Foundation y yo estamos dispuestos a apoyar y financiar investigaciones serias en esta dirección. El primer diseño del sistema de los RIR fracasó porque nunca preguntó qué necesitaba realmente el código en funcionamiento. Preguntó quién podía hablar en la sala. El siguiente sistema debe invertir ese orden. No al blanqueo de mandato. No a la traición al código en funcionamiento. Primacía del Código en Funcionamiento.

Apéndice: Especificación Inicial Mínima, Decisión Futura Localizada y Adopción Voluntaria para los 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 permanente 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. Conforme a 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 protección compartida y la seguridad. Después de la Especificación Inicial, los cambios futuros no son aprobados por un organismo central. Son adoptados, ignorados, bifurcados o abandonados por participantes que ejecutan código. El patrón de diseño previsto es un libro mayor distribuido de estado válido, o un mecanismo distribuido equivalente de estado verificable, no una jerarquía registral. No existe un registro permanente que decida la validez ordinaria. Los participantes validan el estado localmente, aceptan voluntariamente contrapartes 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 un estado que no es válido conforme a las reglas deterministas aceptadas por otro participante puede ser ignorado localmente por este. El efecto es selección de compatibilidad, bifurcación, aislamiento o interoperación selectiva, no castigo institucional. Este documento no define un protocolo de red. Especifica una Mejor Práctica Actual 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 compartiendo 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. Con el tiempo, estos sistemas suelen acumular una autoridad que no era necesaria para la interoperabilidad inicial. Esto suele ocurrir en tres pasos. Primero, se introducen cuestiones futuras en la capa fundacional antes de que sean técnicamente necesarias. Segundo, decisiones que deberían tomar los participantes que ejecutan sus propios sistemas pasan a depender del reconocimiento, la interpretación o las decisiones de estado de un organismo permanente. Tercero, la publicación, el registro, la recomendación o la aprobación procedimental se tratan como suficientes para crear una obligación operativa, incluso cuando los participantes no han adoptado el cambio en sistemas en funcionamiento. El resultado es un sistema frágil. Una capa de referencia técnica se convierte en una capa de gobernanza. Un encargado de registros se convierte en un guardián. 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: especificar únicamente las reglas comunes deterministas necesarias para la interoperabilidad básica, la unicidad, la prueba de control, la protección compartida y la seguridad.
• Decisión Futura Localizada: después de la Especificación Inicial, mantener las decisiones futuras en manos de los participantes que ejecutan código. Un participante puede adoptar, rechazar, bifurcarse, desconectarse o interoperar selectivamente. Ningún participante puede alterar la interoperabilidad de otros que continúan ejecutando reglas mutuamente compatibles.
• Adopción Voluntaria: hacer que un cambio posterior solo se vuelva real mediante la implementación, la operación, la validación y la adopción por participantes que ejecutan código.

Estos principios están relacionados. Un sistema que especifica demasiado al principio precarga el control futuro en la capa común. Un sistema que mantiene una capa permanente de reconocimiento 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 sencilla: la validez debe determinarse mediante reglas deterministas que los participantes puedan verificar localmente frente a un estado compartido. Un participante puede adoptar un cambio posterior, rechazarlo, bifurcarse, desconectarse o interoperar selectivamente. Como máximo, puede excluirse a sí mismo de un conjunto de compatibilidad. Al rechazar un cambio, no puede romper la interoperabilidad de otros participantes que continúan ejecutando código mutuamente compatible. Esta es la lección general del diseño de libros mayores distribuidos: las reglas de consenso son aplicadas por los participantes que ejecutan código de validación y deciden qué estado aceptan, no por una institución situada por encima de ellos.

2. Ámbito de aplicación

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 se opone a las reglas comunes. Sostiene que las reglas comunes deben ser deterministas, mínimas, verificables localmente y limitadas a lo que el sistema necesita realmente para funcionar. Este documento no exige ninguna implementación específica de libro mayor distribuido. Exige una propiedad de diseño: los participantes deben poder determinar la validez aplicando localmente la Especificación Inicial a un estado compartido o replicable, sin pedir permiso o estatus a una autoridad permanente.

3.Convenciones y definiciones

3.1. Lenguaje de requisitos Los términos de requisitos escritos en mayúsculas en este documento deben interpretarse en el sentido definido por BCP 14, concretamente por los RFC 2119 y RFC 8174. 3.2. Terminología Especificación Inicial: El conjunto de reglas, estructuras de datos, formatos, invariantes, procedimientos de validación, reglas de transición de estado y reglas de conflicto necesarios para el primer despliegue de un sistema. Capa Común: El conjunto mínimo compartido de reglas o estructura de referencia necesario para que participantes independientes interoperen. La capa común no es una institución. Es la sustancia técnica que los participantes implementan y verifican. Libro Mayor Distribuido: Un registro replicado o distribuido de otro modo de transiciones de estado que permite a los participantes verificar la validez ordinaria sin depender de un registro permanente, un comité u otra autoridad. El término no exige ningún algoritmo de consenso o implementación concreta. Regla de Validación Determinista: Una regla que permite a un participante decidir, mediante computación o verificación local, si un estado, registro, transición, afirmación o mensaje es válido conforme a un conjunto de reglas especificado. Invariante Global: Una propiedad que debe permanecer común dentro de un conjunto de compatibilidad para preservar la unicidad, la interoperabilidad básica, la integridad de la prueba de control, la protección compartida o la seguridad. Participante: Un operador, implementación, nodo, red, organización u otro actor que ejecuta, verifica, despliega o depende del sistema. Conjunto de Compatibilidad: Un grupo de participantes cuyas reglas de validación implementadas les permiten interoperar. Un cambio posterior puede crear un nuevo conjunto de compatibilidad si algunos participantes lo adoptan y otros no. Adopción: La implementación, el despliegue, la validación y el uso efectivos por participantes que ejecutan el sistema. Aceptación de Contraparte: La decisión voluntaria de un participante de aceptar, contratar, interoperar o confiar en el estado de otro participante conforme a las reglas de validación que ejecuta. No Adopción: La decisión de un participante de no implementar o utilizar un cambio propuesto. La no adopción no crea un estado de invalidez. Solo significa que el participante no se ha unido al conjunto de compatibilidad creado por ese cambio. Rechazo Local: La 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 conforme a las reglas de validación que ejecuta. Bifurcación: 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: Un documento, recomendación, nota de implementación, perfil, implementación de referencia, explorador de libro mayor, espejo u otro artefacto que ayuda a los participantes a coordinarse. Un artefacto de coordinación no crea realidad operativa vinculante salvo que los participantes lo adopten en sistemas en funcionamiento.

4. Planteamiento del problema

Los diseñadores suelen intentar reducir la incertidumbre futura escribiendo demasiado en la capa fundacional o dejando que un organismo permanente interprete cuestiones futuras. Parece prudente. A menudo es peligroso. La sobreespecificación de la capa fundacional tiene tres costes. Primero, traslada decisiones futuras a una capa común en la que el cambio es más difícil y la captura produce mayores efectos. Segundo, crea ambigüedad entre validez técnica y reconocimiento institucional. Tercero, anima 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 necesita un organismo permanente para aprobar cambios, determinar estados o interpretar la operación ordinaria, ha creado una capa de control posterior a la fundación. Esa capa puede empezar como administración. Puede convertirse en gobernanza. Después puede transformarse 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 debe definir al inicio reglas deterministas y verificables localmente; representar el estado válido de forma distribuida o replicable; mantener fuera de la capa común las decisiones que no sean invariantes; y permitir que los cambios posteriores solo se vuelvan reales cuando los participantes los adopten voluntariamente en sistemas en funcionamiento.

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 protección compartida y la seguridad. 5.2. Requisitos Un diseño que utilice este principio:

1. DEBE identificar explícitamente sus Invariantes Globales.
2. DEBE definir reglas de validación deterministas para cada Invariante Global.
3. DEBE definir cómo se representa, replica, verifica y actualiza el estado válido.
4. NO DEBE incluir una regla en la Especificación Inicial salvo que sea necesaria para preservar un Invariante Global declarado o permitir el primer despliegue.
5. DEBE separar las reglas de validación de las preferencias de política, acuerdos empresariales, funciones institucionales, aspiraciones de gobernanza y juicios discrecionales.
6. DEBE permitir a los participantes verificar localmente la validez ordinaria sin consultar a ninguna institución, registro, comité, organismo de políticas u otra autoridad.
7. 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.
8. DEBERÍA definir señalización de extensiones, control de versiones, etiquetado de compatibilidad o identificación de bifurcaciones cuando sea previsible una variación futura.
9. DEBE garantizar que los artefactos de coordinación necesarios sean portátiles, auditables, reproducibles y reemplazables.
10. DEBERÍA preferir condiciones objetivas verificables por máquina frente a juicios subjetivos de mérito.
11. NO DEBE convertir el reconocimiento institucional futuro en la única vía para conocer, registrar o utilizar un estado válido.

5.3. Implicaciones de diseño Especificación Inicial Mínima no significa especificación vaga. Significa especificar rigurosamente solo lo que debe ser común. Un sistema 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 protección compartida y la seguridad; y
• lo que puede permanecer fuera de la capa común porque concierne a preferencias del operador, prácticas empresariales, elección de contrapartes, calendario de despliegue o decisiones posteriores de adopción.

Un diseño que no pueda formular claramente sus Invariantes Globales y sus reglas deterministas de validación debería presumir 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 en manos de los participantes que ejecutan código. Una Decisión Futura solo se vuelve efectiva 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:

1. NO DEBE exigir que los participantes obtengan permiso de una institución establecida, registro, comité, consejo, organismo de políticas u otra autoridad para decisiones que no alteren las reglas deterministas de validación del conjunto de compatibilidad en el que participan.
2. NO DEBE crear un organismo permanente cuyo reconocimiento sea la única vía para que un cambio posterior se vuelva operativamente real.
3. DEBE distinguir la validez conforme a la Especificación Inicial de la compatibilidad con un cambio opcional posterior.
4. NO DEBE tratar la no adopción de un cambio posterior como invalidez.
5. DEBE permitir que los participantes permanezcan en un conjunto de compatibilidad existente cuando no adopten un cambio posterior.
6. DEBE permitir que los participantes se unan a un nuevo conjunto de compatibilidad adoptando nuevas reglas de validación o perfiles operativos.
7. DEBE permitir a los participantes rechazar localmente estados, registros, transiciones o mensajes que sean inválidos o incompatibles conforme a las reglas de validación que ejecutan.
8. DEBE permitir a los participantes elegir voluntariamente contrapartes conforme a las reglas de validación y los conjuntos de compatibilidad que aceptan.
9. 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 haya rechazado un cambio posterior.
10. DEBERÍA hacer explícitas las bifurcaciones, versiones, perfiles o conjuntos de compatibilidad para que los participantes sepan qué reglas ejecutan y con qué otros participantes pueden interoperar.
11. DEBERÍA evitar cualquier diseño en el que un encargado de registros establecido pueda impedir que participantes válidos continúen interoperando.

6.3. Implicaciones de diseño Decisión Futura Localizada no significa que una autoridad central asigne decisiones futuras a actores locales. Significa que el sistema se diseña de manera que, después de la Especificación Inicial, las decisiones futuras ordinarias no necesiten esa 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 protección 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 selectivamente. 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. Nadie necesita decidir que un participante está en situación irregular. Un participante que ejecuta reglas 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 volverse operativamente reales mediante implementación, validación, despliegue, aceptación de contrapartes y adopción por los participantes, no mediante publicación o declaración por sí solas. 7.2. Requisitos Un diseño que utilice este principio:

1. NO DEBE tratar la publicación, recomendación, aprobación en una reunión o aprobación procedimental como suficientes para crear una obligación operativa universal.
2. DEBE permitir que los participantes que lo deseen desplieguen gradualmente nuevas reglas, extensiones, perfiles o procedimientos.
3. DEBE permitir que los participantes rechacen un cambio posterior sin adquirir un estado de invalidez, siempre que sus propias transiciones de estado satisfagan las reglas deterministas de validación de su conjunto de compatibilidad.
4. DEBE permitir que los participantes continúen utilizando un conjunto de compatibilidad anterior cuando la Especificación Inicial permita esa continuidad.
5. DEBE permitir que los participantes que ejecutan un conjunto de compatibilidad rechacen o ignoren localmente el estado de otro conjunto cuando las reglas sean incompatibles.
6. DEBERÍA definir vías de adopción para cambios importantes, incluidas señalización de versiones, etiquetas de compatibilidad, orientación para la transición y vectores de prueba.
7. DEBERÍA definir vías de rechazo para cambios importantes, incluida la forma en que los participantes no adoptantes continúan operando, identifican su conjunto de compatibilidad y evitan una interoperación ambigua.
8. DEBE garantizar que los artefactos de coordinación necesarios puedan abandonarse, duplicarse, reimplementarse o sustituirse sin un coste de transición imposible.
9. DEBERÍA hacer que los registros, recomendaciones y artefactos de coordinación describan la realidad adoptada en lugar de declarar la existencia de una realidad futura no adoptada.
10. DEBE evitar diseñar un sistema en el que la única forma de que un cambio se vuelva real sea el reconocimiento previo por parte de un organismo establecido.

7.3. Implicaciones de diseño La Adopción Voluntaria es la prueba operativa de si un cambio es útil, tolerable y compatible con un despliegue real. Una propuesta no es la realidad. Una recomendación no es la realidad. Un documento no es la realidad. La realidad aparece cuando los participantes implementan, validan, despliegan, aceptan contrapartes y dependen del cambio. La no adopción no crea un estado de infracción. Solo crea un hecho: el participante no se ha unido al conjunto de compatibilidad creado por el cambio. Esto no elimina los procesos de normalización, la documentación, las notas de implementación, los exploradores, los espejos o la revisión. Limita su pretensión. Pueden ayudar a los participantes a coordinarse. Pueden publicar material de referencia. Pueden describir la adopción. Pueden recomendar. No pueden, mediante una mera declaración, hacer vinculante una realidad futura no adoptada para participantes que no la ejecutan.

8.Relación entre los tres principios

Los tres principios se refuerzan mutuamente y no son eficaces de forma aislada. Especificación Inicial Mínima garantiza que la capa común contenga reglas deterministas de validación en lugar de autoridad discrecional. Decisión Futura Localizada garantiza que las decisiones futuras permanezcan en manos de los participantes que ejecutan código, en lugar de ser recapturadas por una capa central de aprobación. Adopción Voluntaria garantiza que el cambio posterior deba superar el contacto con la implementación, la verificación, la aceptación de contrapartes y el uso. Un sistema que adopte solo uno o dos de estos principios puede reproducir la misma centralización por otros medios.

• Especificación Inicial Mínima sin Decisión Futura Localizada todavía puede permitir que la autoridad se acumule después del despliegue.
• Decisión Futura Localizada sin Especificación Inicial Mínima puede producir ambigüedad, porque los participantes no pueden determinar localmente la validez.
• Adopción Voluntaria sin validación determinista puede producir confusión, porque los participantes no pueden distinguir una variación compatible de un estado inválido.
• Validación determinista sin estado distribuido todavía puede dejar a los participantes dependientes de un encargado de registros privilegiado.
• Estado distribuido sin visibilidad de las bifurcaciones puede ocultar el desacuerdo hasta que se produzca un fallo operativo.
• Estado distribuido sin aceptación voluntaria de contrapartes puede recrear la coerción mediante otra interfaz.

En conjunto, los principios producen un sistema en el que la capa común es limitada, la validez se verifica localmente, el cambio futuro es voluntario, el estado está distribuido y no se necesita una institución permanente para decidir la operación ordinaria.

9. Patrón de diseño recomendado

9.1. Capa común distribuida y determinista La capa común DEBERÍA limitarse a:

• semántica estable de identificadores;
• reglas deterministas de validez;
• reglas de resolución de conflictos necesarias para preservar la unicidad;
• mecanismos de prueba de control;
• reglas de transición de estado;
• requisitos de interoperabilidad a nivel de red o de protocolo;
• invariantes de seguridad compartidos;
• formatos de estado portátiles y auditables;
• visibilidad distribuida o replicada del estado;
• señalización de extensiones e identificación de conjuntos de compatibilidad.

La capa común NO DEBERÍA contener:

• reglas sobre modelos de negocio;
• reglas de fijación de precios;
• preferencias políticas regionales;
• ideologías de elegibilidad sin relación con invariantes técnicos;
• poderes discrecionales de ejecución;
• evaluaciones subjetivas de mérito;
• expansión de la misión institucional;
• ninguna regla cuya función principal sea preservar la autoridad de un organismo establecido.

9.2. Superficie de decisión del operador Los siguientes elementos DEBERÍAN permanecer fuera de la capa común, salvo que alteren directamente un Invariante Global declarado:

• calendario de despliegue;
• uso comercial;
• geografía de los clientes;
• acuerdos de arrendamiento, financiación o transferencia;
• preferencias locales de elegibilidad;
• secuencia operativa;
• prácticas de encaminamiento no necesarias para la validez compartida;
• modelo de negocio;
• estructura organizativa;
• calendario de migración voluntaria;
• perfiles o extensiones opcionales;
• elección de contraparte.

Los participantes PUEDEN adoptar decisiones distintas en estas áreas. Esas decisiones pueden producir conjuntos de compatibilidad, relaciones comerciales, acuerdos de interconexión o comunidades operativas diferentes. No crean invalidez salvo que infrinjan las reglas deterministas de validación de un conjunto de compatibilidad. 9.3. Ciclo de adopción Cuando sea posible, el orden preferido para un cambio material del sistema es:

1. propuesta;
2. implementación;
3. vectores de prueba o método de verificación determinista;
4. despliegue limitado por participantes voluntarios;
5. observación de los efectos sobre la interoperabilidad y la seguridad;
6. etiquetado del conjunto de compatibilidad;
7. 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 adelantarse a ella. 9.4. Bifurcación, rechazo local y aceptación de contrapartes Un diseño conforme DEBERÍA tratar la bifurcación, el rechazo local y la aceptación de contrapartes como requisitos normales de diseño, no como fallos. El sistema DEBERÍA definir cómo puede un participante:

• continuar en un conjunto de compatibilidad anterior;
• adoptar un conjunto de compatibilidad más reciente;
• bifurcarse hacia un conjunto de compatibilidad diferente;
• verificar el estado sin depender de un encargado de registros establecido;
• aceptar voluntariamente contrapartes;
• rechazar localmente un estado inválido o incompatible;
• interoperar selectivamente cuando lo permita la compatibilidad.

Un sistema que no pueda bifurcarse, verificarse localmente o aceptarse selectivamente sin destruir una operación válida probablemente haya ocultado poder de gobernanza dentro de su función de mantenimiento de registros.

10.Aplicabilidad y límites

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

• el sistema incluye múltiples actores y jurisdicciones;
• importa el despliegue independiente;
• la capa de coordinación pretende seguir siendo limitada;
• es probable una variación futura que no puede predecirse en detalle;
• el bloqueo generarí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:

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

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

11.Objetivos excluidos

Este documento no:

• prohíbe toda coordinación;
• exige una implementación específica de libro mayor distribuido;
• garantiza el consenso;
• garantiza neutralidad política;
• exige que todos los participantes adopten cada cambio posterior;
• trata el rechazo a adoptar como invalidez;
• legitima un comportamiento local incompatible mientras afirma ser compatible;
• elimina la necesidad de reglas comunes críticas para la seguridad.

12. Consideraciones de seguridad

Una capa de coordinación más limitada puede reducir el riesgo de captura, disminuir el radio de impacto de un error institucional y mejorar la capacidad de sustitución. Sin embargo, una mayor discrecionalidad local y un estado distribuido también pueden crear posturas de seguridad incoherentes, vías 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 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 reproducción y la transferencia no autorizada;
• la negociación de versiones y la gestión de extensiones DEBEN evitar degradaciones silenciosas cuando la seguridad se vea afectada;
• las vías de rechazo, bifurcación y sustitución DEBEN analizarse frente a riesgos de abuso y denegación de servicio;
• las etiquetas de compatibilidad DEBERÍAN ser suficientemente claras para evitar una interoperación accidental entre conjuntos de reglas incompatibles;
• el estado distribuido DEBERÍA ser suficientemente auditable y reproducible para detectar visiones incoherentes;
• la variación local NO DEBE poder afirmar falsamente compatibilidad con un conjunto de reglas que no satisface.

La existencia de excepciones de seguridad no justifica una capa general de permisos. Solo justifica las reglas deterministas de seguridad necesarias para preservar los Invariantes Globales declarados. 13. Consideraciones de la IANA Este documento no requiere ninguna actuación de la IANA. 14. Referencias 14.1. Referencias normativas

• RFC 2119 — Bradner, S., Palabras clave para indicar niveles de exigencia en los RFC, BCP 14, RFC 2119.
• RFC 8174 — Leiba, B., Ambigüedad entre mayúsculas y minúsculas en las palabras clave del RFC 2119, BCP 14, RFC 8174.

14.2. Referencias informativas

• RFC 6709 — Carpenter, B. y B. Aboba, Consideraciones de diseño para extensiones de protocolos, RFC 6709.
• RFC 7282 — Resnick, P., Sobre el consenso y el murmullo en la IETF, RFC 7282.

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

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

1. ¿Cuáles son los Invariantes Globales?
2. ¿Qué reglas deterministas de validación preservan esos Invariantes Globales?
3. ¿Qué reglas de la Especificación Inicial son estrictamente necesarias para el primer despliegue?
4. ¿Cómo se representa y verifica el estado válido?
5. ¿Está el estado distribuido, replicado o es verificable de otra forma independiente?
6. ¿Qué cuestiones futuras se dejan intencionadamente fuera de la capa común?
7. ¿Qué decisiones futuras pueden tomar los participantes sin alterar el conjunto de compatibilidad en el que se encuentran?
8. ¿Cómo adopta un participante un cambio posterior?
9. ¿Cómo rechaza un participante un cambio posterior sin recibir un estado de invalidez?
10. ¿Cómo se etiquetan o descubren los conjuntos de compatibilidad?
11. ¿Cómo funciona el rechazo local cuando un estado es inválido o incompatible conforme a las reglas que ejecuta un participante?
12. ¿Cuál es la vía de bifurcación?
13. ¿Cómo demuestra un titular el control sin un encargado de registros establecido?
14. ¿Cómo verifica una contraparte el estado sin un registro?
15. ¿Pueden los participantes verificar la validez ordinaria sin depender de un encargado de registros establecido?
16. ¿Los registros y artefactos de coordinación describen la realidad adoptada o intentan declarar la existencia de una realidad futura no adoptada?
17. ¿Ha minimizado el sistema el número de decisiones incorporadas en la capa común?
18. ¿Ha evitado el sistema toda autoridad permanente que determine el estado ordinario de los participantes?
19. ¿Pueden los participantes aceptar o rechazar voluntariamente contrapartes?
20. ¿Puede continuar el sistema si desaparecen todos los registros establecidos?

Dirección del autor

1. Lu [Por determinar]