Primacía del código en funcionamiento: el parche necesario para preservar el diseño original de Internet

Cada participante puede comprobarlo por sí mismo. La propuesta de Lu Heng hace depender la validez de reglas verificables localmente y del uso efectivo, en lugar del permiso de una entidad registradora permanente.

Las siete notas de Heng.lu que preceden a esta en la serie son:

1. Nota 52: Cuando el poder de los registros se desvincula de la responsabilidad jurídica: por qué el actual modelo de coordinación de los RIR no puede sobrevivir en su forma presente
2. Nota 53: Los recursos de numeración de Internet no son propiedad política
3. Nota 56: La gobernanza sobredimensionada de los registros regionales de Internet convierte la unicidad en 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 y lo llama igualdad
6. Nota 61: 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 del mandato: de la fantasía de los RIR a una arquitectura de transición

Los siete ensayos anteriores no eran un programa de reforma de los registros regionales de Internet.

Eran una autopsia.

Rastreaban una misma patología institucional en distintas capas: responsabilidad jurídica desvinculada de las consecuencias; recursos de numeración 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 a las que debía servir; y, por último, un mandato blanqueado hasta que un administrativo empezó a expresarse como un soberano. La secuencia importa porque el fallo no consistía en una mala junta directiva, un mal registro, un litigio o un episodio de mercado incómodo. Era un defecto del sistema que aparecía con distintos ropajes. La página del autor en CircleID muestra ahora con claridad esa secuencia, incluidos Traición al código en funcionamiento y Blanqueo del mandato. (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 de llegada y por qué la reparación menos disruptiva consiste en un complemento al diseño técnico original de Internet.

Ese complemento es la Primacía del código en funcionamiento.

Su necesidad ya no es teórica. En un intercambio reciente en CircleID, John Curran presentó la versión más sólida del argumento de las instituciones establecidas. Sostiene que la autoridad del sistema de los RIR no es un mero subproducto de una coordinación técnica acotada, sino el resultado de una cadena histórica: el Libro Blanco, ICANN, la ASO, ICP-2, la transición de la custodia de las funciones de IANA y la continuidad de una gobernanza del sector privado con múltiples partes interesadas. Afirma que la autoridad del sistema de los RIR procede de actuar dentro del modelo del sector privado con múltiples partes interesadas que dispuso el Gobierno de Estados Unidos. (circleid.com)

Ese argumento es útil porque deja a la vista la controversia.

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 ampliarse después hasta convertirse en un mandato permanente de gobernanza mediante la misma maquinaria procedimental que controla. La respuesta de las instituciones establecidas es afirmativa: la delegación, el reconocimiento, la continuidad institucional y los procedimientos de la comunidad se convierten en un mandato que se renueva a sí mismo.

La respuesta que exige el diseño técnico original de Internet es negativa.

La tradición original de Internet era más acotada, más exigente y mejor. El RFC 3935 dice que el objetivo de la IETF es «hacer que Internet funcione mejor»; fundamenta su trabajo en la competencia técnica, la implementación en condiciones reales y el «consenso aproximado y código en funcionamiento». También establece 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 expresa con aún más claridad el rechazo de la soberanía: la IETF no opera, controla ni patrulla Internet y no es «la policía de los protocolos». (rfc-editor.org)

Esa tradición nunca significó que los documentos tuvieran poderes mágicos. Significaba que los documentos importaban cuando ayudaban a que los sistemas funcionaran. Significaba que se toleraban los procedimientos porque servían al despliegue. Significaba que una sala de debate solo era útil cuando se sometía a la disciplina de 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 manera restrictiva, tomando como referencia la función técnica mínima que justificaban originalmente las redes en funcionamiento.

La capa de recursos de numeración existe para proteger los sistemas en funcionamiento: unicidad, interoperabilidad, continuidad vinculada al enrutamiento, declaraciones de seguridad, pruebas 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 moral comercial.

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

No existe para convertir una lista de correo en un órgano legislativo.

No existe para permitir que una entidad registradora privada haga desaparecer activos de red que ya están en funcionamiento porque cambie su interpretación interna de las políticas.

Una entidad registradora no es un Estado.

Un contacto en una base de datos no es un poder de representación de una empresa.

Una región de servicio no es un pueblo.

Una sala de debate sobre políticas no es un órgano legislativo.

Un asiento registral puede describir la realidad operativa. No la crea.

Esto no es conservadurismo. La Primacía del código en funcionamiento no dice que los sistemas desplegados nunca puedan cambiar. Dice que el poder institucional sobre el cambio no debe justificarse mediante una delegación histórica, un reconocimiento circular o un ritual procedimental. 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 del registro distribuido, validación local, implementación en funcionamiento, adopción voluntaria, conjunto de compatibilidad y, después, documentación.

El orden incorrecto es: sala de debate sobre políticas, declaración, obligación que se pretende imponer, etiqueta de cumplimiento y cumplimiento operativo forzoso.

El sistema de los RIR fracasó porque optó cada vez más por el segundo orden.

La corrección fundamental es esta: después de la especificación inicial, no hay ninguna institución permanente a la que acudir. Ningún comité decide si la no adopción constituye una infracción. Ninguna entidad registradora declara inválido a un participante por el mero hecho de que rechace un cambio posterior. Solo hay código, estado del registro distribuido, 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 los participantes que hayan adoptado reglas incompatibles. Pero no puede romper la interoperabilidad de quienes sigan ejecutando código mutuamente compatible.

La idea de diseño es la misma que hace útiles los registros distribuidos: no hace falta una institución permanente que decida la validez ordinaria. Los participantes validan localmente las transiciones de estado conforme a reglas deterministas. Ninguna institución castiga el estado inválido. Los participantes que no lo aceptan lo ignoran.

Ese es el parche esencial que falta en la coordinación de los recursos de numeración.

El fallo de diseño estaba presente desde el principio

El primer diseño de los RIR daba por sentado un mundo de recursos de escaso valor.

Los recursos de numeración 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 adecuada. Los contratos con responsabilidad limitada parecían inofensivos. Un registro regional podía parecer una libreta de direcciones.

La escasez de IPv4 destruyó esa premisa.

Las direcciones IPv4 pasaron a ser escasas, transferibles, susceptibles de financiación, arrendadas, capitalizadas, objeto de litigios y sanciones, e integradas en redes activas. La capa registral ya no se situaba sobre meras anotaciones administrativas. Se situaba sobre infraestructura productiva. Sobre el valor de los activos. Sobre la continuidad del servicio a los clientes, los despliegues en la nube, las operaciones de telecomunicaciones, la conectividad nacional, las órdenes judiciales y la asignación de capital.

La estructura institucional no se redujo para ajustarse a ese nuevo riesgo.

Se expandió.

El resultado es un sistema que sigue hablando el lenguaje de la coordinación técnica mientras produce los efectos de una gobernanza de la infraestructura. Pide a los operadores que consideren neutrales los procedimientos registrales mientras las decisiones de las entidades registradoras afectan a su destino comercial. Llama «comunidad» a sus participantes, aunque muchas de las personas y entidades que soportan las consecuencias nunca otorgaron una representación jurídica inequívoca a quienes están en la sala.

NRS expone con claridad el problema estructural: los registros de numeración de Internet se diseñaron como organismos de coordinación técnica, pero, una vez que 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, en lugar 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 la mínima participación humana en su núcleo. (nrs.help)

Esa es la verdadera cuestión. La capa registral nunca recibió el parche necesario para el momento en que una tabla de coordinación se convirtió en una barrera de acceso a los activos.

La Primacía del código en funcionamiento es ese parche.

No es una doctrina para mejorar los RIR.

Es una disciplina para una etapa posterior a los RIR.

Las tres reglas del parche

El marco constructivo es la versión revisada de la Nota 64: Especificación inicial mínima, Decisión futura de ámbito local y Adopción voluntaria para los sistemas de coordinación de Internet: Especificación inicial mínima, Decisión futura de ámbito local 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 las reglas deterministas y verificables localmente que se necesitan para la unicidad, la interoperabilidad, las pruebas de control, la seguridad operativa compartida y la seguridad informática. No contiene preferencias sobre modelos de negocio, teorías de precios, sensibilidades políticas regionales, potestades discrecionales para hacer cumplir normas ni ampliaciones de la misión institucional.

Decisión futura de ámbito local 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 establece los límites de antemano. Después del despliegue, las decisiones futuras ordinarias siguen en manos de los participantes que ejecutan código. Un participante puede adoptar, rechazar, bifurcarse, desconectarse o interoperar de forma selectiva. Ningún participante puede alterar la interoperabilidad de quienes sigan ejecutando reglas mutuamente compatibles.

Adopción voluntaria significa que un cambio posterior solo se hace realidad 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 de las instituciones establecidas no es la realidad. La no adopción no confiere la condición de inválido. 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 participante puede ser ignorado localmente. El efecto es la selección de compatibilidad, no el 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 especificó con suficiente rigor al principio.

Esta no es una historia sobre un código de conducta. No es una historia sobre buenos modales. No es una historia sobre si un crítico fue lo bastante cortés con una institución establecida.

Es una historia sobre la 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 generaba riesgos no solo para una empresa de 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, en última instancia, el poder jurídico de cerrar APNIC y destituir al Consejo Ejecutivo electo, y que hacían falta modificaciones urgentes de la 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 de Internet de Asia-Pacífico. (larus.net)

El primer documento adjunto, el extracto de datos societarios de ASIC, aporta la base corporativa. APNIC Pty Ltd figuraba como una sociedad australiana de carácter privado, con responsabilidad limitada por acciones, registrada en Queensland. Paul Byron Wilson figuraba como administrador y secretario. La información sobre el capital mostraba una única acción ordinaria emitida, y Paul Byron Wilson figuraba como el socio titular de esa acción. (larus.net)

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

El segundo documento adjunto, el dictamen jurídico del doctor Peter Felter, extraía la conclusión sobre la gobernanza. Describía la estructura de APNIC visible para el público —miembros, elecciones, Consejo Ejecutivo, director general y Secretaría— como un comité especial sustentado 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 de carácter privado controlada mediante un único administrador, un único accionista y un único secretario, todos ellos la misma persona. (larus.net)

Esa distinción importa.

La institución que se presentaba públicamente ante la comunidad no era la estructura jurídica última. Era un edificio levantado sobre la estructura de una sociedad privada.

El dictamen jurídico explicaba después por qué importaba esa distinción. Señalaba que las normas internas de APNIC estaban subordinadas a los estatutos y a las facultades de la sociedad y de sus administradores, cargos y socios. Según esa interpretación, la estructura pública de APNIC podía modificarse por 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 demoledor del dictamen no era que APNIC fuera técnicamente ilegal. Era que la legalidad y la idoneidad 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 constituido el comité especial. También señalaba que APNIC Pty Ltd era una sociedad privada con capital dividido en acciones cuya estructura y objeto no se parecían al modelo sin acciones y sin fines de lucro que la mayoría de la gente 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 nítida.

Un sistema de coordinación de recursos de numeración a escala regional no debería depender de una estructura que necesite abogados para explicar por qué una sociedad privada con una sola acción, un comité especial, un instrumento constitutivo de un fideicomiso y un consejo electo se combinan de algún modo para ejercer un control legítimo sobre el registro de numeración de Asia-Pacífico.

Una capa crítica de coordinación debería poder entenderse desde fuera.

No debería exigir confianza en documentos que remiten a otros documentos.

No debería obligar a los miembros a descubrir, después de años de dependencia institucional, que la capa electa quizá no sea la capa jurídica última.

No debería dar la apariencia de 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 futuro posterior a los RIR debe evitar la necesidad misma de esa institución.

La capa común no debería depender de la estructura oculta de control de una sociedad privada. Debería definir reglas deterministas de validación, un estado que acredite el control, reglas de transición de estado, reglas para los conflictos, replicación del registro distribuido, vías de salida, vías de bifurcación y conjuntos de compatibilidad. Si APNIC desaparece, cae bajo captura institucional, cambia de posición jurídica o se niega a reconocer un estado válido, la red en funcionamiento no debería depender de que APNIC siga reconociéndolo para saber quién controla qué recursos de numeración.

La entidad registradora no debería ser la fuente de validez.

Debería serlo el estado del registro distribuido, validado conforme a la especificación inicial.

ARIN: las políticas se encontraron con la realidad de los activos

ARIN muestra el segundo fallo: la realidad jurídica y del mercado puede ir por delante de 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 sobre la base de que las direcciones no eran propiedad y no podían venderse libres de cargas y al margen de las políticas registrales. Industry Canada apoyó esa postura. El tribunal de quiebras la rechazó; Microsoft firmó después un acuerdo para recursos heredados; y el resultado práctico fue claro: las políticas registrales no podían seguir siendo la única fuente de realidad una vez que los tribunales y los mercados trataban los recursos de numeración como activos. (btw.media)

La lección importante no es que ARIN tuviera un defecto exclusivo.

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

Un asiento registral es valioso porque los operadores, los tribunales, los compradores, los vendedores, los acreedores y las redes confían en él. No adquiere autoridad por negar esa confianza. Solo sigue siendo útil si refleja la realidad jurídica, comercial y operativa con suficiente fidelidad como para resultar digno de confianza.

Una vez que IPv4 se volvió escaso, los procedimientos registrales se convirtieron en una interfaz del mercado. Las reglas de transferencia, las evaluaciones de necesidad, las demoras en el reconocimiento y las restricciones regionales dejaron de ser detalles administrativos. Se convirtieron en trabas para los activos. Los análisis públicos describen ahora un conjunto fragmentado de reglas de los RIR, en el que cinco sistemas regionales rigen un mercado con precios de aproximadamente 18 a 45 dólares por dirección, y cuyas reglas contradictorias pueden inmovilizar activos, retrasar fusiones y obligar a crear estructuras societarias separadas simplemente para mantener bloques de recursos de numeración. (btw.media)

Eso no es coordinación neutral.

Es un efecto regulatorio sin rendición de cuentas regulatoria.

ARIN demuestra por qué importa la Adopción voluntaria. Las políticas registrales solo conservan su credibilidad mientras describen lo que los actores realmente implementan, negocian, financian, llevan a juicio y utilizan como base de sus actividades. Se vuelven peligrosas cuando se considera que publicarlas basta para fabricar la realidad.

Una entidad registradora que rechaza la realidad no se convierte en soberana.

Se convierte en una base de datos desactualizada.

En un diseño basado en la Primacía del código en funcionamiento, la lección es aún más contundente. Los tribunales y los mercados no necesitan que una entidad registradora establecida decida si existe valor. Los operadores no necesitan un comité para saber si un bloque se enruta. Los participantes necesitan reglas deterministas que permitan acreditar el control, resolver conflictos, hacer visibles las transiciones de estado en el registro distribuido y mantener la compatibilidad. La antigua entidad registradora puede publicar una versión del estado. Un cliente de software puede mostrar una versión. Un explorador del registro distribuido puede mostrar una versión. Ninguno es la fuente de validez.

No hay ninguna entidad registradora a la que trasladarse.

No hay ninguna entidad registradora a la que preguntar.

Solo hay 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 es que un miembro problemático paralizó un registro regional.

Esa es la fábula moral de las instituciones establecidas.

La historia estructural es distinta. AFRINIC intentó convertir el uso comercial, la ubicación de los clientes, el arrendamiento, la relación con el miembro y la interpretación interna de las políticas en una pretendida facultad para dar de baja recursos de numeración que ya estaban en funcionamiento. Una vez planteada esa pretensión, el conflicto ya no podía seguir siendo un desacuerdo en una sala de debate sobre políticas. Se convirtió en una prueba de si una entidad registradora privada podía utilizar la retórica regional y el silencio de las políticas para amenazar activos integrados en operaciones reales.

Los hechos no necesitan exageraciones teatrales. La información pública describió la disputa de AFRINIC como un simple conflicto comercial por direcciones IP que acabó convirtiéndose en la mayor historia de gobernanza de Internet en África. También informó de que a menudo se había presentado a Cloud Innovation como el villano, mientras que documentación posterior apuntaba a fuerzas destructivas dentro de la propia AFRINIC y a que representantes de AFRINIC retrasaban, prolongaban y mantenían los litigios a costa de AFRINIC. (btw.media)

Esto importa porque invierte el relato habitual.

Los litigios no crearon el fallo estructural.

Lo dejaron al descubierto.

El fallo en cuestión ya existía cuando una entidad registradora privada trató la ausencia de permiso expreso como fundamento de un control coercitivo. El arrendamiento no era una amenaza para la unicidad. La ubicación de los clientes no era una asignación duplicada. El uso comercial no era un fallo de seguridad del enrutamiento. Un modelo de negocio que no gustara a una entidad registradora no era un invariante global.

Sin embargo, la pretensión registral situó estas cuestiones en un marco de revocación.

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

La información publicada recoge que AFRINIC envió a Cloud Innovation una carta en marzo de 2021 en la que alegaba incumplimientos de las políticas y amenazaba con poner fin a su condición de miembro; que en julio de 2021 el Tribunal Supremo de Mauricio prohibió a AFRINIC poner fin a esa condición; y que un nuevo intento de AFRINIC de cancelarla fue bloqueado en diciembre de 2021. (btw.media) Esa secuencia no es la historia de una entidad registradora que protege serenamente Internet. Es la historia de una autoridad registral que se encuentra con el derecho ordinario.

Tampoco el colapso institucional más amplio fue causado por una falta de poder registral. El problema de fondo era la dependencia sin salida. Si una sola entidad registradora monopoliza el reconocimiento de activos valiosos en funcionamiento, 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 registral se convierte en poder para mantenerlos como rehenes.

Una entidad registradora puede corregir fraudes de registro demostrables en sus propios datos.

Puede evitar asignaciones duplicadas mientras siga existiendo el modelo registral.

Puede mantener declaraciones de seguridad mientras los participantes sigan dependiendo de ella.

Pero esas son funciones transitorias de una arquitectura antigua.

En una arquitectura posterior a los RIR, esas funciones no las desempeña una entidad registradora. Se codifican en el estado del registro distribuido, en reglas de prueba de control, en reglas para los conflictos y en transiciones verificables localmente.

Un organismo privado no debería convertir el arrendamiento en una traición a la región.

No debería convertir la ubicación de los clientes en un motivo de revocación.

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

No debería hacer depender la continuidad de los activos de un permiso.

AFRINIC demuestra la necesidad de una Decisión futura de ámbito local correctamente entendida. No hay un organismo central que decida que una futura decisión comercial «corresponde al ámbito local». Lo que debe hacer la especificación inicial es garantizar que esas decisiones nunca entren en la capa común. El arrendamiento, la ubicación de los clientes, el uso comercial, los precios, la financiación, la composición de la clientela y la estrategia de despliegue permanecen fuera de las reglas deterministas de validez, salvo que afecten directamente a la unicidad, la seguridad, las pruebas 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 utilizar un modelo de negocio que no guste a una entidad registradora.

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

Esa línea divisoria no es ideológica.

Es operativa.

El problema de la representación por poderes no es un detalle

La controversia electoral de AFRINIC dejó a la vista un segundo defecto: la representación.

NRS expresa la base de su representación en términos jurídicos directos. Afirma que los miembros incluidos en su lista confiaron a NRS su representación en asuntos de gobernanza de los RIR y que cada miembro de la lista otorgó un poder de representación. (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 registrado votos sin su participación, y señaló que esas comunicaciones de hechos se tramitarían por cauces legales. (nrs.help)

Esto importa porque muestra la diferencia entre la representación jurídica y la retórica comunitaria.

El sistema de los RIR suele fundir varias categorías en una sola: representante de una empresa, contacto en una base de datos, contacto técnico, empleado, consultor, apoderado, participante en políticas, asiduo de una lista de correo. No son lo mismo.

Un contacto en una base de datos puede ayudar a administrar los registros.

Un poder de representación puede autorizar la representación si es válido y dentro de su alcance.

Un participante en políticas puede aportar conocimientos especializados.

Quien interviene en una lista de correo puede expresar una opinión.

Ninguna de estas condiciones convierte automáticamente a alguien en el sujeto jurídico por cuya cuenta se actúa para toda empresa, cliente, Estado, acreedor, prestamista, comprador, arrendatario o red que soporte las consecuencias de una decisión registral.

Esta distinción solo puede ignorarse mientras la capa común siga siendo reducida. En cuanto la entidad registradora reclama poder sobre la revocación, las transferencias, el arrendamiento, el acceso al mercado, el tratamiento de las sanciones, la continuidad de los activos o el riesgo para la infraestructura nacional, la representación adquiere dimensión constitucional.

Una sala no es un mandato.

Una lista de correo no es un pueblo.

Un registro de contacto no es un poder de representación de una empresa.

Una región de servicio no es una comunidad política soberana.

Esto no es escrupulosidad procedimental.

Es la diferencia entre coordinar y gobernar.

Un sistema basado en la Primacía del código en funcionamiento evita esta trampa al reducir el número de decisiones que requieren representación. Si la validez es determinista y local, hay menos asuntos que someter a votación. Si el cambio futuro es voluntario, no hace falta decidir si quien no lo adopta está en situación irregular. Si el estado se representa en un registro distribuido, no hace falta suplicar a una entidad registradora establecida 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 el diseño del sistema elimina.

RIPE NCC y LACNIC: el club y el cuello de botella

RIPE NCC y LACNIC no demuestran que algunos RIR sean más civilizados que otros. Demuestran que el modelo de los RIR tiene dos capas de imposición más allá de la función técnica: el club y el cuello de botella.

El club decide quién es respetable. El cuello de botella decide qué situación registral puede modificarse y cuál no.

La negativa de RIPE NCC a aceptar el patrocinio de LARUS para RIPE 90 mostró con claridad la capa del club. Un miembro ofreció un patrocinio. El ecosistema del entorno registral lo rechazó por una disputa ajena al evento en otra región. No fue una decisión sobre la seguridad del enrutamiento. No fue una decisión sobre la unicidad. No fue una regla determinista de validación. Fue una inclusión en una lista negra privada mediante el acceso a una conferencia. LACNIC también rechazó mi patrocinio. Otra región, el mismo instinto: el club registral se protege controlando las salas, la visibilidad, el patrocinio, la reputación y la legitimidad social.

Eso no es comunidad. Es controlar quién puede entrar.

La capa de sanciones es peor porque muestra el cuello de botella central en su forma jurídica. RIPE NCC afirma que, al estar radicada en los Países Bajos, debe cumplir las sanciones de la UE; cuando se aplican sanciones, congela la inscripción en la base de datos RIPE, bloquea la adquisición y las transferencias, y puede tratar un caso como congelado cuando una parte no puede aportar documentación suficiente. También comprueba las listas de OFAC porque las relaciones bancarias afectan a los pagos. (Transparencia de RIPE NCC sobre las sanciones)

Esto no es una crítica a RIPE NCC por obedecer la ley. Una entidad neerlandesa debe obedecer el derecho neerlandés y de la UE. El problema es la arquitectura: ¿por qué debería una sola entidad privada neerlandesa ser el punto central de reconocimiento de la movilidad de los recursos de numeración entre numerosos países, operadores y sistemas jurídicos?

Las sanciones pueden obligar a un banco. Las sanciones pueden obligar a una entidad neerlandesa. Las sanciones pueden obligar a una contraparte que opta por no realizar una operación. No deberían convertirse en una condición de validez técnica global para todos los demás.

Ese es el fallo de diseño.

La misma posición central que permite a un club excluir a un crítico permite también a una jurisdicción congelar la movilidad registral. Una es imposición social. La otra es imposición jurídica. Ambas funcionan únicamente porque la entidad registradora ocupa el lugar donde no debería residir la validez.

Esto enlaza directamente con los tres principios.

Especificación inicial mínima: la respetabilidad ante el club, los requisitos para patrocinar, la política regional, la clasificación a efectos de sanciones y la reputación nunca deben entrar en la capa común. La capa común debería contener únicamente reglas deterministas de unicidad, prueba de control, tratamiento de conflictos, transición de estado y seguridad.

Decisión futura de ámbito local: el riesgo jurídico, la elección de contraparte, el patrocinio, la confianza comercial y la exposición a sanciones corresponden a los actores que los soportan. Una entidad neerlandesa puede rechazar una operación. Un banco puede rechazar un pago. Una contraparte puede negarse a tratar con otra. Nada de eso debería convertirse en una 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 derivada de sanciones debería limitar al actor sujeto a ella, no reescribir el registro de recursos de numeración de todo el mundo.

Por eso es necesario un diseño basado en un registro distribuido. En un sistema posterior a los RIR, la validez ordinaria no la deciden RIPE NCC, LACNIC, una oficina de sanciones, un comité de reuniones o una oficina de patrocinio. Los participantes validan el estado localmente. Las contrapartes aceptan o rechazan voluntariamente. Las bifurcaciones son visibles. Los conjuntos de compatibilidad son explícitos. La entidad registradora central desaparece como fuente de verdad.

La solución no son mejores modales.

La solución no es una cola de tramitación de sanciones más transparente.

La solución es retirar la validez tanto del club como del cuello de botella.

Estado distribuido. Validación local. Aceptación voluntaria de contrapartes. Ninguna entidad registradora 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 de coordinación de los RIR del mundo y decía que los RIR gestionan los recursos de numeración en sus respectivas regiones. Afirmaba que los cinco registros desempeñan la función de administrar los recursos de numeración conforme a reglas adoptadas regionalmente o a políticas globales adoptadas por unanimidad. (nro.net)

La misma carta criticaba los litigios de Cloud Innovation, decía que se habían presentado más de 25 demandas, se quejaba de órdenes judiciales que habían congelado las cuentas de AFRINIC y detenido las elecciones, y afirmaba que AFRINIC había pedido reiteradamente 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 una entidad registradora privada chocó con los tribunales ordinarios, el reflejo del sistema no fue acotar el mandato.

No fue eliminar la dependencia sin salida de la entidad registradora.

No fue separar el mantenimiento de registros de la imposición de normas.

No fue definir una validación distribuida.

No fue preguntarse si la facultad unilateral de dar de baja activos en funcionamiento había sido ilegítima 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 cuotas, contrario a considerar los recursos como propiedad cuando quiere eludir la responsabilidad jurídica asociada a la propiedad, y casi internacional cuando quiere quedar a resguardo de los tribunales.

Ese conjunto no es gobernanza.

Es blanqueo del mandato a escala de todo el sistema.

Si los RIR quieren privilegios de derecho público, deben aceptar la rendición de cuentas del derecho público. Si quieren flexibilidad de derecho privado, deben aceptar los litigios del derecho privado. Lo que no pueden exigir racionalmente es discrecionalidad privada, importancia de infraestructura pública, responsabilidad jurídica reducida, representación débil, posición de monopolio y protección cuasidiplomática, todo al mismo tiempo.

Ese es el camino hacia el desastre.

La Primacía del código en funcionamiento lo rechaza.

Cuando una entidad registradora se encuentra con resistencia jurídica, no debe huir hacia arriba en busca de inmunidad. La arquitectura debe reducirse hacia abajo, hasta la función acotada del código en funcionamiento que la justificaba.

Menos soberanía.

Ninguna entidad registradora como fuente de validez.

Menos imposición.

Más validación distribuida.

Revisar ICP-2 no basta

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 dice que la propuesta establecería reglas y criterios para reconocer nuevos RIR, obligaciones y requisitos de funcionamiento de los RIR, y reglas para retirar el reconocimiento; si se adoptara, sustituiría a ICP-2. La misma página dice que el proceso se inició después de que la NRO pidiera a la ASO que propusiera actualizaciones para que el sistema de los RIR rindiera más cuentas ante la comunidad de Internet. (icann.org)

Eso puede ser necesario como medida de continuidad.

No basta 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 lo bastante como para que deba ser apartado?

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

Un sucesor de ICP-2 que se limite a endurecer el reconocimiento, la auditoría, el traspaso y la retirada del reconocimiento puede mejorar la higiene institucional y, al mismo tiempo, conservar el error de categoría. Sigue dando por sentado que el RIR es la forma soberana primordial de coordinación de los recursos de numeración.

La Primacía del código en funcionamiento plantea otro conjunto de preguntas.

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

¿Cómo siguen siendo verificables las pretensiones sobre recursos de numeración sin el permiso de la entidad establecida?

¿Cómo sobrevive la unicidad sin discrecionalidad monopolística?

¿Cómo se impide que los registros de datos se conviertan en armas de imposición?

¿Cómo se mantienen las decisiones comerciales fuera de la validez determinista, salvo que esté en riesgo un auténtico invariante global?

¿Cómo sigue siendo utilizable la coordinación sin ninguna entidad registradora con autoridad?

¿Cómo valida un operador el estado ordinario sin pedir a un organismo permanente que determine su condición?

¿Cómo se evita que el rechazo se convierta en una etiqueta de infracción?

Estas no son preguntas de reforma.

Son preguntas para una etapa posterior a los RIR.

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

La cuestión no es si a uno le gustan o le disgustan los registros establecidos.

La cuestión es si la capa de recursos de numeración 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 se desprende del diseño original. Si Internet se construyó para rechazar a reyes, presidentes y votaciones como fuentes de verdad técnica, entonces la capa de recursos de numeración 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 por sí solo puede quedar subordinado si la capa registral se sitúa antes del reconocimiento y lo condiciona. La regla que falta es interpretativa y arquitectónica: cuando el procedimiento institucional entra en conflicto con la función técnica mínima que requieren los sistemas en funcionamiento, el código en funcionamiento tiene prioridad; y, cuando se propone un cambio posterior, este solo se hace realidad mediante la adopción voluntaria de los participantes que ejecutan reglas de validación.

Así se preserva el diseño original, en lugar de abandonarlo.

Internet fue importante porque se convirtió en el primer sistema mundial de comunicaciones que no exigía el permiso previo de un único soberano, ministerio, iglesia, empresa o guardián de acceso. Si ese logro sigue mereciendo defensa, la capa registral no puede convertirse en la excepción que se traga la regla.

Un sistema construido para prescindir de reyes no puede permitir que un contable se postule para serlo.

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 elementos sin autoridad, nunca como fuentes de validez.

Qué requiere la coordinación posterior a los RIR

La coordinación posterior a los RIR no significa caos.

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

No hay ninguna entidad registradora a la que trasladarse.

No hay ninguna nueva entidad registradora a la que coronar.

No hay un sacerdocio de reemplazo.

Hay un registro distribuido del estado de los recursos de numeración, 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, las pruebas de control, el estado de las transferencias, el estado de las delegaciones, las declaraciones de seguridad vinculadas al enrutamiento, la auditabilidad, los metadatos de los conflictos y la visibilidad de las bifurcaciones.

La capa de los operadores debería controlar el uso comercial, el arrendamiento, la ubicación de los clientes, las prácticas de enrutamiento, la financiación, la selección de contrapartes y las reglas comerciales que no constituyen invariantes.

La capa de adopción debería determinar qué se hace realidad. 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 se preserva la interoperabilidad sin convertir el reconocimiento de la entidad establecida en la única fuente de realidad.

La capa de imposición no debe fusionarse con la capa de estado. Un registro distribuido puede recoger el estado. Puede validar transiciones. Puede mostrar conflictos. Puede hacer portátiles las pruebas. No debe convertirse a la vez en fiscal, juez, autoridad sancionadora, regulador del mercado, moralista comercial y custodio de activos.

Por encima de todo, la portabilidad debe entenderse correctamente.

En un mundo de registros distribuidos, la portabilidad no significa trasladarse de una entidad registradora a otra. Eso sigue siendo pensamiento registral. No hay ninguna entidad registradora a la que trasladarse. La prueba de control del titular, el historial del estado y su capacidad de transferencia no quedan atrapados en una base de datos de la entidad establecida. Existen en un estado compartido y verificable que los participantes validan localmente y las contrapartes aceptan voluntariamente.

Sin eso, toda entidad registradora es un punto de dependencia sin salida.

Con ello, la entidad registradora desaparece como fuente de validez.

Por tanto, la coordinación posterior a los RIR necesita cuatro propiedades de diseño.

Primera: validez determinista. Un participante debería saber si una transición de estado, una prueba, una delegación, una transferencia o una declaración es válida aplicando localmente la especificación.

Segunda: conjuntos de compatibilidad. Si los participantes adoptan distintas reglas futuras, el sistema debería describir con claridad la frontera de compatibilidad, en lugar de tratar la discrepancia como una conducta indebida.

Tercera: prueba de control distribuida. Un titular no debería «trasladar» sus recursos a otra entidad registradora; debería demostrar el control mediante un estado válido conforme al registro distribuido que cualquier contraparte pueda verificar sin la bendición de la entidad establecida.

Cuarta: visibilidad de las bifurcaciones. Si los conjuntos de reglas divergen, la divergencia debería ser explícita. Los participantes deciden qué conjunto de compatibilidad ejecutar y qué contrapartes aceptar. Una bifurcación puede aislar a los participantes. No otorga a un lado poder institucional para borrar al otro.

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 hacia el fracaso es previsible

Si nada cambia, el camino hacia el fracaso está claro.

Primero, más disputas pasarán de las salas de debate sobre políticas a los tribunales. Los activos escasos atraen el escrutinio jurídico. Se pedirá a los tribunales que congelen cuentas, preserven registros de datos, bloqueen elecciones improcedentes, nombren administradores judiciales, reconozcan transferencias o determinen quién puede actuar en nombre de una entidad registradora.

Segundo, los Estados dejarán de tratar a los RIR como asociaciones técnicas inofensivas. 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á indefinidamente, sin examinarla, que una estructura registral privada extranjera sea el punto del que depende la continuidad de sus comunicaciones nacionales.

Tercero, los operadores buscarán vías para eludir la autoridad registral cuando sea posible. Si los datos registrales se vuelven políticos, inseguros, poco representativos o ajenos a la realidad de los activos, los operadores recurrirán a contratos privados, transferencias respaldadas por litigios, acreditaciones alternativas, reconocimiento nacional o la realidad de facto del enrutamiento.

Cuarto, ICANN y la capa de la NRO sentirán la tentación de centralizar. Eso produciría una versión más sobredimensionada del mismo problema, salvo que se acote el propio mandato.

Quinto, los gobiernos sentirán la tentación de nacionalizar. Eso sería previsible y peligroso. Si las entidades registradoras privadas reclaman una autoridad cuasisoberana sin rendición de cuentas pública, los Estados acabarán recuperando la soberanía. El resultado podría ser fragmentación, represalias, registros contradictorios y presión política sobre el enrutamiento.

Internet no falla únicamente cuando los paquetes dejan de circular.

También falla cuando las instituciones que describen quién puede utilizar los identificadores pierden la confianza de los operadores que mueven los paquetes.

Un registro distribuido no resuelve todos los problemas políticos. Hace algo más importante: elimina la entidad registradora permanente como fuente ordinaria de validez. Eso reduce la superficie de ataque. Reduce el poder institucional de mantener a otros como rehenes. Convierte el desacuerdo futuro en selección de compatibilidad, en lugar de guerra administrativa.

La pregunta cambia

El sistema antiguo 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 el fraude de registro demostrable mediante pruebas deterministas?

¿Protege la seguridad vinculada al enrutamiento?

¿Mantiene la exactitud de las pruebas de control?

¿Permite la validación local?

¿Elimina la dependencia de una única entidad establecida?

¿Describe una realidad adoptada o declara una obligación no adoptada?

¿Puede un participante rechazarla sin que se le atribuya la condición de inválido?

¿Puede un participante verificar la validez ordinaria sin pedir a una entidad registradora que determine su condición?

¿Puede una contraparte aceptar o rechazar el estado voluntariamente?

¿Puede haber una bifurcación sin que una institución borre a uno de los lados?

Si la respuesta no está vinculada a una necesidad determinista del código en funcionamiento, ese poder no debería residir en la capa común.

Eso es la Primacía del código en funcionamiento.

Para debatir

Esta propuesta se presenta para su discusión. No es una solución definitiva.

El siguiente paso debería ser un Internet-Draft riguroso o un documento de estilo BCP que defina la Primacía del código en funcionamiento para los sistemas de coordinación de Internet, empezando por los recursos de numeración. El borrador no debería preguntarse cómo rehabilitar el monopolio de los RIR. Debería preguntarse cómo construir una coordinación posterior a los RIR mediante el estado de un registro distribuido, la validación determinista, la adopción voluntaria, la aceptación de contrapartes y conjuntos de compatibilidad explícitos.

Deberían ponerlo a prueba operadores, juristas, economistas, ingenieros de protocolos, expertos en seguridad del enrutamiento, 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é poderes de los antiguos registros son residuos históricos?

¿Qué decisiones corresponden 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 para rechazar un cambio?

¿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 una entidad registradora establecida?

¿Cómo verifica una contraparte el estado sin una entidad registradora?

¿Puede Internet continuar si un RIR colapsa?

¿Pueden los recursos de numeración seguir siendo únicos sin el permiso de la entidad establecida?

¿Puede un participante validar el estado ordinario sin una institución permanente?

¿Puede un procedimiento de elaboración de políticas distinguir un invariante del código en funcionamiento del apetito institucional?

¿Puede desaparecer la antigua capa registral sin perder el estado verificable?

¿Puede un registro de datos describir la realidad sin convertirse en soberano sobre ella?

Cualquier persona interesada puede ponerse en contacto conmigo a través de LinkedIn. Los investigadores rigurosos, autores técnicos, instituciones o expertos en políticas que quieran ayudar a convertir esta propuesta en un primer Internet-Draft y, con el tiempo, en una discusión sobre un RFC o una BCP, si la comunidad la considera útil, deberían ponerse en contacto conmigo. LARUS Foundation y yo estamos dispuestos a apoyar y financiar investigaciones rigurosas 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.

Sin blanqueo del mandato.

Sin traición al código en funcionamiento.

Primacía del código en funcionamiento.

Apéndice: Especificación inicial mínima, Decisión futura de ámbito local 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 hacen funcionar el sistema. Define tres principios vinculados: Especificación inicial mínima, Decisión futura de ámbito local y Adopción voluntaria.

Según este modelo, la Especificación inicial define únicamente las reglas deterministas y verificables localmente que se requieren para la unicidad, la interoperabilidad, las pruebas de control, la seguridad operativa compartida y la seguridad informática. Después de la Especificación inicial, los cambios futuros no son aprobados por un organismo central. Los participantes que ejecutan código los adoptan, los ignoran, crean bifurcaciones o los abandonan.

El patrón de diseño previsto es un registro distribuido de estado válido, o un mecanismo distribuido equivalente de estado verificable, no una jerarquía registral. No hay ninguna entidad registradora permanente que decida la validez ordinaria. Los participantes validan el estado localmente, aceptan contrapartes voluntariamente 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 no válido según las reglas deterministas aceptadas por otro participante puede ser ignorado localmente por este. El efecto es la selección de compatibilidad, la bifurcación, el aislamiento o la interoperación selectiva, no el castigo institucional.

Este documento no define un protocolo de comunicación. Especifica una mejor práctica actual, o BCP, para el diseño de protocolos, sistemas de identificadores, registros 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 acotado: permitir que actores independientes interoperen compartiendo un punto de referencia común, un espacio de identificadores, una regla de validación, el estado de un registro distribuido o un registro de pruebas de control. Con el tiempo, esos sistemas suelen acumular una autoridad que no era necesaria para la interoperabilidad inicial.

Esto suele ocurrir en tres pasos.

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

Segundo, decisiones que deberían tomar los participantes que operan sus propios sistemas pasan a depender de decisiones de reconocimiento, interpretación o condición dictadas por un organismo permanente.

Tercero, se considera que la publicación, la inscripción, la recomendación o la aprobación procedimental bastan 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. Quien lleva los registros se convierte en quien controla el acceso. Un elemento 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 que se requieren para la interoperabilidad básica, la unicidad, las pruebas de control, la seguridad operativa compartida y la seguridad informática.
• Decisión futura de ámbito local: 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 de forma selectiva. Ningún participante puede alterar la interoperabilidad de otros participantes que sigan ejecutando reglas mutuamente compatibles.
• Adopción voluntaria: hacer que un cambio posterior se haga realidad únicamente mediante su implementación, operación, validación y adopción por los participantes que ejecutan código.

Estos principios están relacionados. Un sistema que especifica demasiado al principio incorpora de antemano el control futuro a 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 una orden.

La idea de diseño es sencilla: la validez debe determinarse mediante reglas deterministas que los participantes puedan verificar localmente frente al estado compartido. Un participante puede adoptar un cambio posterior, rechazarlo, bifurcarse, desconectarse o interoperar de forma selectiva. Como mucho, puede excluirse a sí mismo de un conjunto de compatibilidad. No puede, por rechazar un cambio, romper la interoperabilidad de otros participantes que sigan ejecutando código mutuamente compatible.

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

2. Alcance

Este documento se aplica a los sistemas de coordinación de Internet, incluidos, entre otros, los sistemas de identificadores, los marcos de nombres y numeración, los mecanismos de extensión de protocolos, los sistemas de prueba de control, los sistemas de portabilidad, los registros 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 deberían 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 registro distribuido. Exige una propiedad de diseño: los participantes deberían poder determinar la validez aplicando localmente la Especificación inicial a un estado compartido o replicable, sin pedir permiso ni una determinación de su condición 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 para los conflictos que se requieren para el primer despliegue de un sistema.

Capa común:
El conjunto mínimo de reglas compartidas o la estructura de referencia mínima que se requiere para que participantes independientes interoperen. La capa común no es una institución. Es el contenido técnico que los participantes implementan y verifican.

Registro distribuido:
Un registro de transiciones de estado replicado o distribuido de otra forma que permite a los participantes verificar la validez ordinaria sin depender de una entidad registradora, un comité u otra autoridad permanente. El término no exige ningún algoritmo de consenso ni implementación en particular.

Regla determinista de validación:
Una regla que permite a un participante decidir, mediante cálculo local o verificación local, si un estado, un registro de datos, una transición, una declaración o un mensaje es válido según un conjunto de reglas especificado.

Invariante global:
Una propiedad que debe mantenerse común dentro de un conjunto de compatibilidad para preservar la unicidad, la interoperabilidad básica, la integridad de las pruebas de control, la seguridad operativa compartida o la seguridad informática.

Participante:
Un operador, una implementación, un nodo, una red, una organización u otro actor que ejecuta, verifica o despliega el sistema, o depende de él.

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:
Implementación, despliegue, validación y uso efectivos por parte de los participantes que hacen funcionar el sistema.

Aceptación de contrapartes:
La decisión voluntaria de un participante de aceptar el estado de otro participante, realizar operaciones o interoperar con él, o confiar en dicho estado, 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 confiere la condición de inválido. Solo significa que el participante no se ha incorporado al conjunto de compatibilidad creado por ese cambio.

Rechazo local:
La decisión local de un participante de ignorar o rechazar un estado, un mensaje, un registro de datos o una transición, o de no interoperar con ellos, por ser inválidos o incompatibles según 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.

Elemento de coordinación:
Un documento, una recomendación, una nota de implementación, un perfil, una implementación de referencia, un explorador del registro distribuido, una réplica u otro elemento que ayuda a los participantes a coordinarse. Un elemento de coordinación no crea una realidad operativa vinculante a menos que los participantes lo adopten en sistemas en funcionamiento.

4. Planteamiento del problema

Los diseñadores suelen intentar reducir la incertidumbre futura incorporando demasiadas disposiciones a la capa fundacional o manteniendo un organismo permanente que interprete las cuestiones futuras. Esto parece prudente. A menudo es peligroso.

El exceso de especificación en la capa fundacional tiene tres costes.

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, genera ambigüedad entre la validez técnica y el reconocimiento institucional.

Tercero, anima a un organismo que mantiene registros de datos, publica documentos o convoca a los 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 que apruebe cambios, determine condiciones o interprete el funcionamiento ordinario, el sistema ha creado una capa de control posterior a su fundación. Esa capa puede empezar como administración. Puede convertirse en gobernanza. Y después puede convertirse en un cuello de botella.

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

Un sistema de coordinación de Internet bien diseñado debería definir desde el principio reglas de validez deterministas y verificables localmente; representar el estado válido de forma distribuida o replicable por otros medios; dejar fuera de la capa común las decisiones que no afectan a invariantes; y permitir que los cambios posteriores solo se hagan realidad cuando los participantes los adopten voluntariamente en sistemas en funcionamiento.

5. Principio 1: Especificación inicial mínima

5.1. Enunciado

Una Especificación inicial DEBERÍA definir únicamente las reglas comunes deterministas mínimas que se requieren para la interoperabilidad básica, la unicidad, las pruebas de control, la seguridad operativa compartida y la seguridad informática.

5.2. Requisitos

Un diseño que utilice este principio:

1. DEBE identificar explícitamente sus invariantes globales.
2. DEBE definir reglas deterministas de validación 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 a menos que dicha regla sea necesaria para preservar un invariante global declarado o para permitir el primer despliegue.
5. DEBE separar las reglas de validación de las preferencias de políticas, los acuerdos comerciales, los papeles institucionales, las aspiraciones de gobernanza y el criterio discrecional.
6. DEBE permitir a los participantes verificar localmente la validez ordinaria sin consultar a ninguna institución, entidad registradora, comité, organismo de políticas u otra autoridad.
7. DEBERÍA definir las estructuras de datos, firmas, pruebas, reglas de transición de estado, reglas para los conflictos u otros mecanismos necesarios para la verificación local.
8. DEBERÍA definir la señalización de extensiones, el control de versiones, el etiquetado de compatibilidad o la identificación de bifurcaciones cuando sea previsible una variación futura.
9. DEBE garantizar que los elementos de coordinación necesarios sean portátiles, auditables, reproducibles y reemplazables.
10. DEBERÍA dar preferencia a las condiciones objetivas verificables por máquina frente a los juicios subjetivos de mérito.
11. NO DEBE convertir el reconocimiento institucional futuro en la única vía por la que pueda conocerse, registrarse o utilizarse un estado válido.

5.3. Implicaciones de diseño

Especificación inicial mínima no significa especificación vaga. Significa especificar con rigor únicamente lo que debe ser común.

Un sistema sigue necesitando una estructura común suficiente para funcionar. La disciplina consiste en distinguir entre:

• lo que debe ser común para la unicidad, la interoperabilidad, las pruebas de control, la seguridad operativa compartida y la seguridad informática; y
• lo que puede permanecer fuera de la capa común porque se refiere a las preferencias de los operadores, las prácticas comerciales, la elección de contrapartes, el momento del despliegue o las decisiones de adopción posterior.

Un diseño que no pueda exponer con claridad sus invariantes globales y sus reglas deterministas de validación debería dar por sentado que ha especificado demasiada discrecionalidad y demasiado poco contenido verificable.

6. Principio 2: Decisión futura de ámbito local

6.1. Enunciado

Después de la Especificación inicial, las decisiones futuras DEBERÍAN permanecer en el ámbito local de los participantes que ejecutan código. Una decisión futura solo surte efecto para el conjunto de compatibilidad cuyos participantes la adoptan. No hace falta ninguna autoridad permanente que la apruebe, y la no adopción no confiere la condición de inválido.

6.2. Requisitos

Un diseño que utilice este principio:

1. NO DEBE exigir a los participantes que obtengan permiso de una institución establecida, entidad registradora, comité, junta directiva, organismo de políticas u otra autoridad para tomar 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 por la que un cambio posterior pueda hacerse realidad operativa.
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 a los participantes permanecer en un conjunto de compatibilidad existente cuando no adopten un cambio posterior.
6. DEBE permitir a los participantes incorporarse a un nuevo conjunto de compatibilidad mediante la adopción de nuevas reglas de validación o perfiles operativos.
7. DEBE permitir a los participantes rechazar localmente estados, registros de datos, transiciones o mensajes que sean inválidos o incompatibles según las reglas de validación que ejecutan.
8. DEBE permitir a los participantes elegir contrapartes voluntariamente conforme a las reglas de validación y los conjuntos de compatibilidad que aceptan.
9. NO DEBE autorizar a ninguna institución, entidad registradora, comité, organismo de políticas u otro actor a declarar inválido a un participante por el mero hecho de que haya rechazado un cambio posterior.
10. DEBERÍA hacer explícitos las bifurcaciones, las versiones, los perfiles o los 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 la entidad que actualmente mantiene los registros pueda impedir que participantes por lo demás válidos sigan interoperando.

6.3. Implicaciones de diseño

Decisión futura de ámbito local no significa que una autoridad central asigne las decisiones futuras a actores locales. Significa que el sistema se diseña de modo que, después de la Especificación inicial, las decisiones futuras ordinarias no necesiten esa asignación.

La Especificación inicial establece los límites de antemano. Define los invariantes mínimos necesarios para la unicidad, la interoperabilidad, las pruebas de control, la seguridad operativa compartida y la seguridad informática. Todo lo demás permanece fuera de la capa común.

El cambio futuro no se aprueba de forma centralizada. Los participantes que ejecutan código lo adoptan, lo ignoran, crean bifurcaciones o lo abandonan.

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 sigan ejecutando reglas mutuamente compatibles.

El efecto del 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 de validación compatibles simplemente no acepta el estado inválido o incompatible.

7. Principio 3: Adopción voluntaria

7.1. Enunciado

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

7.2. Requisitos

Un diseño que utilice este principio:

1. NO DEBE considerar que la publicación, la recomendación, la aprobación en una reunión o la aprobación procedimental bastan para crear una obligación operativa universal.
2. DEBE permitir que las nuevas reglas, extensiones, perfiles o procedimientos sean desplegados de forma gradual por los participantes que decidan ejecutarlos.
3. DEBE permitir a los participantes rechazar un cambio posterior sin adquirir la condición de inválidos, siempre que sus propias transiciones de estado satisfagan las reglas deterministas de validación de su conjunto de compatibilidad.
4. DEBE permitir a los participantes seguir utilizando un conjunto de compatibilidad anterior cuando la Especificación inicial permita esa continuidad.
5. DEBE permitir a los participantes que ejecutan un conjunto de compatibilidad rechazar o ignorar localmente el estado procedente de otro conjunto de compatibilidad cuando las reglas sean incompatibles.
6. DEBERÍA definir vías de adopción para los cambios importantes, incluidas la señalización de versiones, el etiquetado de compatibilidad, las orientaciones para la transición y los vectores de prueba.
7. DEBERÍA definir vías para rechazar los cambios importantes, incluido cómo los participantes que no los adopten continúan operando, identifican su conjunto de compatibilidad y evitan una interoperación ambigua.
8. DEBE garantizar que sea posible dejar de utilizar, replicar, reimplementar o reemplazar los elementos de coordinación necesarios sin un coste de transición inasumible.
9. DEBERÍA hacer que los registros de datos, las recomendaciones y los elementos de coordinación describan la realidad adoptada, en lugar de pretender dar existencia por declaración a una realidad futura no adoptada.
10. DEBE evitar el diseño de un sistema en el que la única forma de que un cambio se haga realidad sea el reconocimiento previo 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 basan su actividad en el cambio.

La no adopción no crea una condición de infractor. Solo crea un hecho: el participante no se ha incorporado 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, las réplicas ni la revisión. Limita sus pretensiones. 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 que una realidad futura no adoptada sea vinculante para los 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.

La Especificación inicial mínima garantiza que la capa común contenga reglas deterministas de validación en lugar de autoridad discrecional.

La Decisión futura de ámbito local garantiza que las decisiones futuras permanezcan en manos de los participantes que ejecutan código, en lugar de ser recuperadas por una capa central de aprobación.

La Adopción voluntaria garantiza que un cambio posterior tenga que 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.

• La Especificación inicial mínima sin la Decisión futura de ámbito local puede seguir permitiendo que la autoridad se acumule después del despliegue.
• La Decisión futura de ámbito local sin la Especificación inicial mínima puede generar ambigüedad, porque los participantes no pueden determinar la validez localmente.
• La Adopción voluntaria sin validación determinista puede generar confusión, porque los participantes no pueden distinguir una variación compatible de un estado inválido.
• La validación determinista sin estado distribuido puede seguir dejando a los participantes dependientes de un encargado privilegiado de mantener los registros.
• El estado distribuido sin visibilidad de las bifurcaciones puede ocultar el desacuerdo hasta que se produzca un fallo operativo.
• El estado distribuido sin aceptación voluntaria de contrapartes puede recrear la coerción a través de otra interfaz.

Juntos, los principios producen un sistema en el que la capa común es reducida, la validez es verificable localmente, el cambio futuro es voluntario, el estado es distribuido y no hace falta ninguna institución permanente que decida el funcionamiento ordinario.

9. Patrón de diseño recomendado

9.1. Capa común determinista y distribuida

La capa común DEBERÍA limitarse a:

• semántica estable de los 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 en el nivel de transmisión 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 precios;
• preferencias políticas regionales;
• criterios ideológicos de admisibilidad ajenos a los invariantes técnicos;
• potestades discrecionales para hacer cumplir normas;
• evaluaciones subjetivas de mérito;
• ampliaciones de la misión institucional;
• cualquier regla cuya función principal sea preservar la autoridad de un organismo establecido.

9.2. Ámbito de decisión de los operadores

Los siguientes asuntos DEBERÍAN permanecer fuera de la capa común, salvo que alteren directamente un invariante global declarado:

• momento del despliegue;
• uso comercial;
• ubicación de los clientes;
• acuerdos de arrendamiento, financiación o transferencia;
• preferencias locales de admisibilidad;
• secuencia de las operaciones;
• prácticas de enrutamiento no necesarias para la validez compartida;
• modelo de negocio;
• estructura organizativa;
• momento de la migración voluntaria;
• perfiles o extensiones opcionales;
• elección de contrapartes.

Los participantes PUEDEN tomar decisiones diferentes en estos ámbitos. Esas decisiones pueden producir distintos conjuntos de compatibilidad, relaciones comerciales, acuerdos de interconexión entre pares o comunidades operativas. No crean invalidez a menos que infrinjan las reglas deterministas de validación de un conjunto de compatibilidad.

9.3. Ciclo de adopción

Cuando sea viable, el orden preferido para un cambio sustancial del sistema es:

1. propuesta;
2. implementación;
3. vectores de prueba o método determinista de verificación;
4. despliegue limitado por participantes dispuestos a adoptarlo;
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 elemento de coordinación DEBERÍA seguir a la adopción, en lugar de intentar anticiparse a ella y condicionarla.

9.4. Bifurcación, rechazo local y aceptación de contrapartes

Un diseño conforme con este documento DEBERÍA tratar la bifurcación, el rechazo local y la aceptación de contrapartes como requisitos normales de diseño, en lugar de 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 la entidad que actualmente mantiene los registros;
• aceptar contrapartes voluntariamente;
• rechazar localmente el estado inválido o incompatible;
• interoperar de forma selectiva cuando la compatibilidad lo permita.

Un sistema que no pueda bifurcarse, verificarse localmente o aceptarse de forma selectiva sin destruir el funcionamiento válido probablemente ha 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 tiene múltiples actores y abarca múltiples jurisdicciones;
• el despliegue independiente importa;
• se pretende que la capa de coordinación siga siendo reducida;
• es probable que haya variaciones futuras, pero no pueden preverse en detalle;
• la dependencia sin salida generaría un 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 acoplamiento fuerte en tiempo real exige un comportamiento uniforme en todo momento;
• la protección de la vida humana exige uniformidad global inmediata;
• la validez no puede verificarse localmente mediante ningún mecanismo viable.

Incluso en esos casos, los diseñadores DEBERÍAN seguir minimizando la capa común y evitando el control discrecional futuro siempre que sea posible.

11. Objetivos excluidos

Este documento no:

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

12. Consideraciones de seguridad

Una capa de coordinación más reducida puede disminuir el riesgo de captura, limitar el alcance de los errores institucionales y facilitar su reemplazo. Sin embargo, una mayor discrecionalidad local y el estado distribuido también pueden crear niveles de protección incoherentes, vías de degradación a versiones menos seguras, presiones hacia la fragmentación, declaraciones ambiguas de compatibilidad, bifurcaciones inseguras, disputas sobre el estado del registro distribuido 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 de mensajes y las transferencias no autorizadas;
• la negociación de versiones y el tratamiento de extensiones DEBEN evitar la degradación silenciosa a versiones menos seguras cuando la seguridad se vea afectada;
• las vías de rechazo, bifurcación y reemplazo DEBEN analizarse para detectar riesgos de abuso y denegación de servicio;
• las etiquetas de compatibilidad DEBERÍAN ser lo bastante claras como para impedir la interoperación accidental entre conjuntos de reglas incompatibles;
• el estado distribuido DEBERÍA ser lo bastante auditable y reproducible como para detectar visiones incoherentes;
• NO DEBE permitirse que una variación local afirme falsamente ser compatible 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 IANA

Este documento no requiere ninguna actuación de 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 las extensiones de protocolos, RFC 6709.
• RFC 7282 — Resnick, P., Sobre el consenso y los tarareos en la IETF, RFC 7282.

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

Un diseño que afirme ser conforme con este documento DEBERÍA poder responder con claridad 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. ¿El estado es distribuido, replicado o verificable de forma independiente por otros medios?
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 que se le atribuya la condición de inválido?
10. ¿Cómo se etiquetan o descubren los conjuntos de compatibilidad?
11. ¿Cómo funciona el rechazo local cuando el estado es inválido o incompatible según 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 depender de la entidad que actualmente mantiene los registros?
14. ¿Cómo verifica una contraparte el estado sin una entidad registradora?
15. ¿Pueden los participantes verificar la validez ordinaria sin depender de la entidad que actualmente mantiene los registros?
16. ¿Los registros de datos y los elementos de coordinación describen la realidad adoptada, o intentan dar existencia por declaración a una realidad futura no adoptada?
17. ¿Ha minimizado el sistema el número de decisiones incorporadas a la capa común?
18. ¿Ha evitado el sistema toda autoridad permanente que determine la condición ordinaria de los participantes?
19. ¿Pueden los participantes aceptar o rechazar contrapartes voluntariamente?
20. ¿Puede el sistema continuar si desaparecen todas las entidades registradoras establecidas?

Autor: Lu Heng