¿Qué es la traición al código en funcionamiento en la gobernanza de los RIR?
El argumento de Lu Heng sobre la traición al código en funcionamiento, explicado a través de una red operativa: por qué los procedimientos deben servir a la continuidad y qué debe preservar una alternativa.
La crítica de Lu Heng comienza cuando un procedimiento concebido para apoyar a las redes en funcionamiento se convierte en una fuente de poder sobre ellas.
Imagina una red que presta servicio a sus clientes con normalidad. Sus equipos funcionan, sus conexiones funcionan y otras redes pueden llegar a ella. Entonces, la organización que mantiene sus datos de direcciones cambia las condiciones en las que reconocerá esa red. Los cables no se han movido, pero el operador tiene ahora que defender el fundamento administrativo del que dependen otros.
Este es el conflicto que Lu Heng llama traición al código en funcionamiento: las instituciones invocan una tradición creada para ayudar a que las redes funcionen y luego la utilizan para justificar su poder sobre las propias redes. En la Nota 61, su crítica va más allá de si una reunión fue justa. Pregunta por qué esa reunión debería tener tal poder para empezar.
¿Qué significa aquí «código en funcionamiento»?
Código en funcionamiento significa software y sistemas que realmente se han implementado y utilizado. En un servicio de Internet, eso incluye el trabajo real de conectar redes y mantener accesibles a los clientes. Un diseño propuesto se pone a prueba frente a esa realidad operativa.
La declaración de misión del IETF vincula el criterio de ingeniería con la experiencia de implementar y desplegar especificaciones. Su análisis del consenso aproximado explica por qué contar partidarios no sustituye a abordar las objeciones técnicas. Son métodos para producir soluciones de ingeniería útiles, no un mandato general para gobernar a todos los afectados por Internet.
Lu Heng aplica esa distinción a los Registros Regionales de Internet, o RIR. Un registro ayuda a coordinar los recursos numéricos para que las redes puedan distinguir un recurso de otro. Su utilidad procede de apoyar esa función compartida. Su argumento es que esa función no otorga a la institución una autoridad ilimitada sobre quienes la utilizan.
La inversión: la red empieza a servir al procedimiento
Pensemos en una regla destinada a impedir que dos redes sin relación entre sí reclamen el mismo número. Esa regla aborda un problema técnico compartido. Ahora pensemos en una regla que decide a qué clientes puede atender un operador, qué acuerdos comerciales puede utilizar o si sus recursos deben seguir vinculados a un administrador concreto.
Esas decisiones tienen un alcance mucho mayor. Decir que los participantes las aprobaron no demuestra que cada operador o cliente afectado autorizara a esos participantes a tomarlas.
La inversión se produce cuando el operador debe reorganizar un servicio que funciona para adaptarlo a la preferencia de una institución, mientras esta considera que haber completado su procedimiento es una respuesta suficiente a las consecuencias. El proceso sigue funcionando. Lo que cambia es a qué intereses sirve.
Por qué una decisión en una base de datos puede importar fuera de ella
Un registro no transporta todos los paquetes. Cambiar un dato no equivale a apagar todos los enrutadores. La influencia surge de la dependencia: proveedores, clientes y otros sistemas consultan datos registrales y pruebas relacionadas al reconocer un recurso y decidir cómo tratarlo.
Eso crea una cadena entre una decisión administrativa y un servicio que la gente utiliza. Las consecuencias dependen del dato concreto, de los sistemas técnicos implicados y de las decisiones de las organizaciones que se apoyan en ellos.
Para ver esa cadena, sigue un bloque de direcciones a través de una empresa. ¿Quién mantiene sus contactos registrales? ¿Quién publica sus autorizaciones de enrutamiento? ¿Qué redes transportan su tráfico? ¿Qué clientes han incorporado sus direcciones a sus propias configuraciones? Un desacuerdo en la capa de mantenimiento de registros puede exigir trabajo en todas esas relaciones.
Qué aporta el debate sobre AFRINIC
La Nota 61 utiliza la controversia de AFRINIC para desarrollar una crítica concreta: Lu Heng sostiene que una función limitada de coordinación se amplió mediante interpretaciones del uso regional, el reconocimiento institucional y las condiciones de transferencia. También cuestiona la defensa de esa ampliación por parte del sistema más amplio de registros.
Su exposición distingue entre dónde circula el tráfico y si un titular puede trasladar su relación administrativa. Una restricción a la salida puede crear dependencia aunque el enrutamiento habitual continúe. Por eso trata la portabilidad como una cuestión estructural y no como una comodidad menor.
La Nota contiene su lectura detallada del historial de políticas, las declaraciones institucionales y los litigios. La pregunta más amplia de esta introducción puede entenderse sin aceptar todas las afirmaciones institucionales: cuando la autoridad del coordinador está en disputa o este no está disponible, ¿pueden quienes operan la red preservar su servicio sin seguir necesitando su permiso?
Por qué no basta con mejorar la participación
Unas reuniones más accesibles, explicaciones más claras y mejores vías para objetar pueden mejorar un proceso. Por sí solas, no responden a qué está facultada para decidir la institución.
Por tanto, la crítica de Lu Heng no consiste simplemente en que el consenso deba reflejar a más participantes. Consiste en que la coordinación debe seguir limitada por el trabajo al que está destinada a servir. Un procedimiento no puede otorgarse un mandato ilimitado declarando que sus participantes están de acuerdo.
Por eso también, sustituir un comité por otro dejaría intacto el problema central si el nuevo comité siguiera siendo la fuente indispensable de reconocimiento.
La alternativa propuesta: hacer que la validez pueda comprobarse de forma independiente
La Nota 65 desarrolla la respuesta constructiva: la Primacía del código en funcionamiento. La capa común que propone contiene las reglas mínimas necesarias para la unicidad, la prueba de control, la seguridad y la interoperabilidad. Los participantes deberían poder comprobar esas reglas localmente frente a un estado distribuido.
Los cambios posteriores se vuelven operativos mediante su implementación y adopción voluntaria. Los participantes que mantengan reglas anteriores compatibles no necesitan pedir permiso a una institución permanente para continuar. Un participante puede rechazar un estado que incumpla las reglas que ejecuta; ese rechazo técnico es distinto de que una institución castigue a alguien por no aceptar una política posterior.
Se trata de una arquitectura propuesta. Hacerla funcionar requiere gestión de conflictos, pruebas seguras, compatibilidad visible y vías prácticas de transición. Publicar un documento o copiar un archivo del registro no basta, por sí solo, para que otras redes acepten a un sucesor.
¿Por qué prepararse mientras la red sigue funcionando?
La continuidad no puede improvisarse cambiando una etiqueta durante una crisis. Los operadores y las partes con las que se relacionan necesitan datos utilizables, formas de verificarlos y un conocimiento probado de qué se preserva durante una transición.
La prueba para el lector es sencilla: ¿una regla protege algo que las redes necesitan realmente en común o preserva la capacidad del administrador de decidir por ellas? Después, pregunta si la coordinación útil puede continuar si ese administrador desaparece.
Lee la Nota 61 para conocer la crítica, la Nota 65 para conocer el diseño propuesto y la Nota 72 para conocer su declaración de derechos. Juntas, pasan de lo que ha salido mal a lo que la capa compartida debería hacer realmente.