Resumen

  • La Resolución 200605.27 consta en el índice del consejo de AFRINIC como una ratificación del paso a ASN de cuatro octetos y una instrucción de implementación, pero el informe de AFRINIC-4, la convocatoria posterior, el último llamamiento de noviembre y la Resolución 200611.34 forman una cronología incompatible con la idea de una aprobación única y cerrada en mayo.
  • El calendario modificaba las preferencias de asignación: desde el 1 de enero de 2007, un ASN exclusivamente de cuatro octetos se obtenía previa petición; desde el 1 de enero de 2009 pasó a ser la opción predeterminada y el ASN exclusivamente de dos octetos requirió petición; desde el 1 de enero de 2010 se preveía una bolsa indiferenciada de cuatro octetos. Ninguna de esas fechas ordenaba a un operador poner en servicio equipos incompatibles.
  • La transición funcionaba por interoperabilidad gradual: señalización de capacidad, el valor de tránsito AS_TRANS y atributos adicionales para conservar la ruta permitían relacionar hablantes BGP antiguos y nuevos. Sin embargo, la agregación, los atributos incoherentes, los filtros, las comunidades, los campos de 16 bits y las notaciones asdot y asplain mantuvieron riesgos que una resolución no podía eliminar.
  • La prueba de implementación exige reconstruir cada paso, desde el texto de la política y el inventario recibido de IANA hasta la solicitud, la asignación, WHOIS, las estadísticas delegadas, la observación de rutas, las excepciones y los intercambios posteriores. Los registros de 2011, 2012 y 2014 documentan avance, pero también fricción persistente.
  • AFRINIC podía coordinar un libro único, cambiar opciones predeterminadas y publicar constancias. Seguía siendo un contable privado: la transición no le otorgó propiedad sobre los ASN o las redes, ni soberanía, potestad legislativa o regulatoria, policía, acusación, jurisdicción judicial, castigo o confiscación.

Una resolución que no cabe en una sola fecha

La primera dificultad de este episodio no es matemática. Es documental. El índice de reuniones del consejo de AFRINIC atribuye a la Resolución 200605.27 una formulación de aparente cierre: ratificar cuatro políticas, entre ellas el cambio de números de sistema autónomo de dos bytes a cuatro, y ordenar al personal que las aplicara. Leída de forma aislada, esa entrada permitiría contar una historia nítida: en mayo de 2006 el consejo aprobó la transición y la maquinaria administrativa se puso en marcha.

El resto del archivo impide esa simplificación. El informe de AFRINIC-4 sitúa la discusión de la propuesta el 17 de mayo. Describe un intercambio limitado, aunque favorable, y registra que se alcanzó consenso para seguir adelante. La expresión importa: avanzar no equivale necesariamente a haber terminado todos los actos posteriores que el propio proceso dejó registrados. El archivo de políticas coloca un periodo de último llamamiento entre el 13 y el 28 de noviembre de 2006.

El índice del consejo, en la misma página que conserva la resolución de mayo, registra además la Resolución 200611.34 como ratificación de la política de ASN de cuatro bytes. El informe de AFRINIC-5 refuerza la pista tardía al decir que el consejo había aprobado la política pocos días antes de aquella reunión de finales de noviembre y comienzos de diciembre, y que estaría disponible desde el 1 de enero de 2007.

No hay base en el conjunto documental para decidir que una de esas piezas es simplemente falsa, ni para inventar una teoría jurídica que convierta mayo en una aprobación provisional y noviembre en otra clase de acto con efectos definidos. La conclusión permitida es más modesta y más útil. La Resolución 200605.27 demuestra que el índice del consejo registró en mayo una aprobación y una instrucción de implementación. El expediente completo demuestra, a la vez, que el recorrido procedimental continuó y que en noviembre se documentaron un último llamamiento y una ratificación distinta.

Puede hablarse de inconsistencia documental o de una huella de aprobación en dos etapas; no puede asignarse a cada etapa un significado que las fuentes no explican.

Existe incluso una discrepancia anterior que aconseja el mismo cuidado. La cabecera del archivo de la política asigna a AAFPUB-2005-ASN-001 la fecha 22 de septiembre de 2005, mientras que su historial afirma que la propuesta se publicó por primera vez en la lista de políticas el 9 de diciembre de ese año. Las dos marcas son datos registrados. Fundirlas en una única fecha de creación, sin una constancia que explique la diferencia, produciría una certeza artificial.

Esta tensión no es una nota erudita al margen. Determina cómo debe auditarse la transición. Un sistema que conserva un único campo llamado “fecha de aprobación” obligaría a escoger mayo o noviembre y borraría la diferencia entre discusión, consenso para avanzar, instrucción del consejo, último llamamiento y ratificación posterior. La reparación correcta no consiste en elegir la fecha que mejor convenga a una narrativa institucional. Consiste en almacenar cada acto con su fuente, su fecha y la condición exacta que el documento le atribuye.

Si después aparece una conciliación autorizada y comprobable, se añade como un nuevo registro; no se sobrescribe el desacuerdo original.

También es una lección sobre la fuerza probatoria. Una página de política prueba lo que dice esa página. Un informe de reunión prueba lo que sus redactores dejaron asentado. Una resolución prueba que existe un acto institucional registrado con determinada redacción. Ninguna de esas piezas, por sí sola, prueba que todos los formularios cambiaron, que el inventario fue cargado correctamente, que WHOIS aceptó cada valor, que los encaminadores estaban preparados o que las rutas se propagaron sin pérdida. Tampoco prueba que el proceso confiriera legitimidad de derecho público.

Antes de preguntar si la transición “se aprobó”, por tanto, hay que separar cuatro preguntas: qué se discutió, qué se registró como decisión, qué se implementó en los sistemas del registro y qué llegó a funcionar en las redes de los operadores.

El calendario coordinaba preferencias, no obediencia técnica

La sustancia de la política era un cambio escalonado en la forma de entregar números, no una orden general sobre cómo debía operar cada red. El espacio representable con dos octetos abarca los valores de 0 a 65.535. El campo de cuatro octetos representa de 0 a 4.294.967.295, y la propuesta trataba como exclusivamente de cuatro octetos el tramo de 65.536 a 4.294.967.295. Son límites numéricos de representación, no una afirmación de que todos los valores estén libres o sean asignables. Existen reservas de protocolo y de registro.

Ampliar el ancho de un campo tampoco convierte el número resultante en una propiedad, un título, una licencia o una concesión soberana.

El 1 de enero de 2007 debía comenzar la primera fase. AFRINIC seguiría asignando por defecto un ASN que pudiera expresarse en dos octetos, mientras que una organización que quisiera un valor exclusivamente de cuatro octetos tendría que pedirlo de manera específica. Era una puerta de entrada deliberada: permitía que quienes dispusieran de equipos, software y relaciones de interconexión preparados adquirieran experiencia, sin convertir a los demás en participantes involuntarios de una migración abrupta.

El 1 de enero de 2009 se invertía la preferencia. El ASN de cuatro octetos pasaba a ser la opción predeterminada, y el número exclusivamente de dos octetos quedaba disponible mediante petición expresa. La inversión tenía un efecto coordinador concreto. Comunicaba a proveedores y operadores que la compatibilidad con el campo más amplio ya no debía tratarse como una capacidad excepcional, y conservaba el espacio más estrecho para casos que pudieran documentar una necesidad de compatibilidad.

El informe de AFRINIC-9, preparado en 2008, sirve como testimonio de cómo AFRINIC describía entonces la distribución de las bolsas y recordaba la llegada de esa segunda fase. Es una constancia de preparación y comunicación institucional, no una prueba universal sobre equipos ajenos.

El 1 de enero de 2010 terminaba la distinción de asignación y se preveía una bolsa indiferenciada de cuatro octetos. En ese contexto, “indiferenciada” no significaba que cada ASN asignado fuese necesariamente superior a 65.535. Significaba que el motor de asignación ya no debía mantener dos modalidades políticas separadas según el ancho histórico. Tampoco significaba que el cambio de calendario hubiese actualizado, por arte de declaración, los encaminadores, sistemas de gestión, bases de datos comerciales, filtros o herramientas de todos los usuarios.

La política especificaba además que no implicaba ningún otro cambio en la política de asignación de ASN. Ese límite evita desviar el análisis hacia las condiciones que podían hacer apta a una organización para recibir un número. La transición trataba del ancho, de la preferencia y de la secuencia de entrega. No reescribía criterios de necesidad, multihoming u otras condiciones de calificación. Tampoco era una historia general de los sistemas autónomos. Su pregunta era más estrecha: cómo introducir valores que ya no cabían en el formato de dos octetos sin provocar una jornada de ruptura simultánea.

El valor económico del calendario estaba precisamente en evitar ese “día de bandera”. Sin una secuencia anunciada, los operadores y fabricantes habrían recibido menos aviso y la bolsa más estrecha se habría acercado a su límite con un camino de continuidad menos previsible. Una obligación inmediata de usar cuatro octetos en 2006, en cambio, habría hecho recaer el riesgo sobre redes con equipos antiguos, herramientas rígidas o pares incapaces de interpretar la transición.

Las tres fases repartían la adaptación en el tiempo: primero una elección voluntaria, después una inversión de la opción predeterminada y, al final, la retirada de la distinción administrativa.

Pero una opción predeterminada sigue siendo una decisión del registro sobre su propia interfaz. Puede afectar mucho a un operador —por ejemplo, obligándole a justificar una excepción, probar un equipo o coordinar una ventana de mantenimiento— sin adquirir por ello el carácter de una norma estatal. El registro puede decir qué valor ofrece primero dentro de su inventario. No puede conseguir que un procesador antiguo acepte un entero más ancho, ni hacer que un proveedor entregue una actualización, ni transformar una interconexión insegura en segura por simple mandato.

Cuatro superficies de compatibilidad

La transición solo puede evaluarse si se observan, como mínimo, cuatro superficies distintas: el protocolo entre hablantes BGP, los sistemas administrativos del registro, la identidad textual del número y el entorno operativo del receptor. La conformidad en una de ellas no demuestra conformidad en las otras.

El protocolo permitía avanzar por relaciones entre pares

El diseño técnico disponible durante la discusión de 2006 era todavía un Internet-Draft del grupo IDR, fechado en noviembre de 2005. Describía una transición incremental. Un hablante BGP podía anunciar mediante una capacidad que entendía números de sistema autónomo de cuatro octetos. Dos pares capaces podían entonces utilizar la codificación más amplia. Si uno de los extremos solo entendía dos octetos, la relación podía recurrir a una representación compatible con el formato heredado. No hacía falta esperar a que toda Internet se actualizara al mismo tiempo; la decisión ocurría en cada sesión entre pares, según sus capacidades reales.

Cuando un ASN de cuatro octetos no podía mapearse directamente en el campo antiguo, el trayecto heredado podía mostrar AS_TRANS, cuyo valor numérico es 23456. Ese sustituto permitía atravesar el segmento antiguo sin pretender que 23456 fuese la identidad real del sistema nuevo. Para preservar la información más rica, el diseño añadía un atributo opcional y transitivo. Un hablante posterior con capacidad para cuatro octetos podía combinar los datos y reconstruir una parte mayor del camino original.

La terminología debe seguir su cronología. El borrador de noviembre de 2005 denominaba NEW_AS_PATH y NEW_AGGREGATOR a los atributos de preservación. RFC 4893, publicado en mayo de 2007, estandarizó el mecanismo con los nombres AS4_PATH y AS4_AGGREGATOR, junto con la capacidad para cuatro octetos y AS_TRANS. No es correcto describir la deliberación de 2006 como si ya hubiese citado una RFC que aún no existía, ni sustituir retrospectivamente todos los nombres del borrador por los que adoptó la especificación posterior. La continuidad de la idea técnica no borra la evolución documental.

El mecanismo resolvía una parte del problema, no todas. RFC 4893 asumía que los hablantes BGP dentro de un mismo sistema autónomo serían actualizados antes de que ese sistema utilizara un ASN de cuatro octetos. El registro podía entregar el número, pero no realizar esa actualización interna. Además, la agregación practicada por un hablante antiguo podía descartar información necesaria para una reconstrucción perfecta. Una combinación incoherente de AS_PATH y AS4_PATH podía introducir ambigüedad, ocultar un bucle o crear un riesgo de seguridad.

El atributo adicional no era una máquina del tiempo capaz de recuperar datos que ya se habían perdido.

Las convenciones operativas también podían contener supuestos de 16 bits. Los filtros y ciertas formas de comunidades que incorporaban el ASN dentro de un campo más estrecho exigían revisión. La especificación señalaba comunidades extendidas específicas de AS de cuatro octetos para usos comparables, pero la existencia de una alternativa no demostraba que cada configuración, herramienta o política de filtrado hubiera sido migrada.

Por eso AS_TRANS debía monitorizarse: su aparición podía ser una señal esperada de tránsito por un tramo antiguo, pero su persistencia inesperada, una ruta mal reconstruida o atributos contradictorios podían indicar incompatibilidad.

El registro tenía que cambiar más que una política

La segunda superficie era administrativa. Para aplicar la secuencia, AFRINIC necesitaba inventario utilizable, un motor de asignación que comprendiera los valores más amplios, formularios capaces de expresar la preferencia correspondiente a cada fase, campos de base de datos sin truncamiento, procedimientos de soporte, documentación pública y un servicio WHOIS que publicara el número correcto. Cada componente requería un cambio verificable.

La constancia de IANA de que el bloque 327680–328703 fue asignado a AFRINIC el 29 de noviembre de 2006 es un punto de control decisivo. Demuestra que el registro superior anotó ese bloque y esa fecha antes del inicio de la primera fase. No demuestra cuándo se realizó la primera asignación a un receptor, cuándo apareció por primera vez una ruta o si el inventario local coincidía en todo momento con la constancia superior. Para eso se necesita reconciliar el bloque recibido con los totales locales disponibles, asignados, reservados y tratados como excepción.

El retraso entre una fecha política y ciertos cambios visibles importa. El informe anual de AFRINIC de 2012 dice que en 2011 se retiró del formulario la opción de elegir entre ASN de 16 y 32 bits, y que a partir de entonces la asignación se efectuó desde una bolsa común de 32 bits. Esa afirmación ayuda a reconstruir la implementación, pero también demuestra por qué el hito del 1 de enero de 2010 no debe tomarse como prueba automática de que cada interfaz administrativa había adoptado ese estado exactamente ese día.

Puede haber una diferencia entre la norma de asignación, la presentación del formulario y el momento en que la institución afirma haber completado un cambio de sistema.

El 11 de mayo de 2012, un anuncio en la lista pública de políticas declaró que los sistemas de AFRINIC permitían asignar desde una bolsa indiferenciada, que WHOIS admitía el intervalo completo y que la representación textual seguía asplain. Es evidencia de una afirmación de implementación publicada y fechada. No prueba que fuese el primer momento de soporte, que todos los componentes internos se comportaran igual o que cada sistema de un operador externo hubiese sido probado.

Un mismo número no debía convertirse en dos identidades

La tercera superficie era semántica. La propuesta inicial utilizaba ejemplos en notación asdot. En esa forma, el valor decimal 65.546 podía representarse como 1.10. RFC 5396 adoptó después la representación decimal asplain para todos los ASN porque la coexistencia de formatos generaba confusión operativa. Un lector humano puede aprender que 1.10 y 65546 designan el mismo entero; una búsqueda literal, una tabla de facturación o una regla construida sobre cadenas de texto puede tratarlos como objetos distintos.

La defensa contra esa división consiste en guardar una identidad canónica numérica independiente de su forma visual. Los sistemas deben conservar también la representación histórica como evidencia, porque borrar el “1.10” de un ticket antiguo impediría comprender por qué una configuración o un filtro lo menciona. Las búsquedas, WHOIS, colectores de rutas, herramientas de soporte, inventarios, contratos y CRM deben resolver ambas escrituras al mismo número. La normalización debe probarse en ambos sentidos y en los límites relevantes; no basta con cambiar la etiqueta que ve el usuario.

Los campos de 16 bits plantean un riesgo aún más silencioso. Una base de datos antigua puede rechazar 65.536, truncarlo, desbordarlo o aceptar una escritura que luego otra interfaz no pueda leer. Una API puede validar la cadena pero almacenarla en un tipo insuficiente. Un sistema de monitorización puede mostrar un valor envuelto sin generar una alarma. El control adecuado inventaría cada esquema e interfaz, ensayaría valores fronterizos, rechazaría escrituras con pérdida y conservaría los registros de migración.

La frase “nuestro WHOIS admite cuatro octetos” solo es una hipótesis comprobable hasta que se observa el recorrido completo de entrada, almacenamiento, exportación, consulta y comparación.

La preparación pertenecía finalmente al operador

La cuarta superficie era el entorno que usaría el ASN. Un receptor debía conocer las versiones de sus encaminadores y software, las capacidades de cada par, el comportamiento de sus filtros y comunidades, la compatibilidad de sus sistemas de aprovisionamiento y monitorización, y su plan de retorno. Podía ser razonable probar primero en laboratorio, limitar el despliegue y observar rutas antes de integrar el valor en todas las relaciones comerciales y técnicas.

Los costes no eran abstractos. Incluían licencias o sustitución de equipos, horas de ingeniería, ventanas de mantenimiento, pruebas con pares, cambios en filtros, monitorización, informes y sistemas de tickets. Un fallo podía causar pérdida de alcance, rutas mal interpretadas o una coordinación costosa para devolver o cambiar el número. Para una red pequeña con hardware antiguo, el coste relativo podía ser mayor que para un operador con un laboratorio amplio y ciclos frecuentes de renovación. El calendario aportaba aviso, pero también podía trasladar desde el registro hacia el operador el coste de demostrar por qué necesitaba una excepción.

Esa distribución explica por qué la preparación medible y un camino documentado de excepción son parte de una transición técnica justa. No porque AFRINIC actuara como regulador que debiera conceder un derecho administrativo, sino porque un coordinador privado no debería usar su opción predeterminada para empujar a una red hacia una configuración que las pruebas muestran insegura. La decisión final de poner en producción una capacidad pertenece a quien opera el equipo y soporta el riesgo de interconexión, dentro de las restricciones reales que imponen sus pares.

Del papel al encaminamiento: la pista de auditoría

Una auditoría convincente no pregunta solo si “AFRINIC implementó la política”. Pregunta si una persona independiente puede reconstruir el trayecto entero sin depender de la conclusión de AFRINIC. El expediente debe empezar por la propuesta exacta, su referencia, versión y metadatos de publicación, con una copia fechada o huella que impida que un cambio posterior borre lo que se evaluó. Debe incorporar el informe de AFRINIC-4, el resultado de consenso, el último llamamiento, las dos resoluciones y una nota expresa sobre la cronología conflictiva.

Después vienen los cambios de implementación: órdenes de trabajo o constancias equivalentes para el formulario, el motor de asignación, el esquema WHOIS, las estadísticas delegadas, la documentación y el soporte. El bloque recibido de IANA debe cuadrar con el inventario local. Para cada asignación, la solicitud debe mostrar qué preferencia pidió el receptor, qué fase estaba vigente, qué valor decimal canónico se asignó, cómo se mostraba entonces, cuándo se tomó la decisión y qué función operativa fue responsable.

La parte del operador añade versiones de equipos y software, ensayos de capacidad, pruebas de laboratorio o despliegues limitados, revisión de filtros y comunidades, compatibilidad de pares y retorno seguro. Después debe reconciliarse la solicitud con la base de asignaciones, el objeto público en WHOIS o aut-num, la entrada de estadísticas delegadas y la evidencia de encaminamiento observada. Que un ASN no aparezca en una ruta en un momento dado no lo convierte automáticamente en inválido; puede no estar en uso visible, estar reservado para una transición o aparecer en un conjunto de observación incompleto.

La discrepancia debe explicarse, no transformarse mecánicamente en culpabilidad.

Las excepciones completan la historia. El informe anual de 2012 dice que AFRINIC asignó 145 ASN ese año, seis de ellos de 32 bits, y que incompatibilidades de equipos llevaron a intercambios caso por caso de ASN de 32 bits de la parte alta por ASN de 32 bits de la parte baja. La precisión es importante: no toda excepción consistió en volver a un ASN de dos octetos. Un cambio desde una cifra de la parte alta hacia otra de la parte baja dentro del rango de cuatro octetos podía responder a la manera concreta en que cierto equipo trataba el valor.

El informe prueba lo que AFRINIC comunicó; no proporciona por sí solo verificación independiente de cada caso.

En 2014, la NRO informó de una fricción más amplia: encaminadores incompatibles habían provocado que algunos clientes devolvieran o intercambiaran ASN de cuatro bytes por ASN de dos bytes. Es una señal comparativa de que el problema no terminaba en la fecha política y no era solo una posibilidad teórica. No identifica cada intercambio de AFRINIC y no autoriza a atribuirle todos los casos regionales. Sí fortalece una inferencia prudente: el calendario común convivió durante años con equipos y prácticas que no podían seguirlo sin excepciones.

Un intercambio bien controlado debe enlazar de manera inmutable el número anterior con el nuevo, conservar el motivo, identificar los sistemas afectados y registrar quién autorizó cada paso. Hay que actualizar el registro público, migrar las rutas, comprobar filtros y cerrar el incidente con evidencia. Si el número antiguo desaparece sin esa relación, la continuidad se rompe en varios planos a la vez. Un ticket puede parecer referido a otra entidad, un contrato puede conservar el identificador retirado, una ruta histórica puede perder su explicación y un auditor puede confundir el reemplazo con una asignación sin relación.

La metodología de continuidad propuesta por NRS aporta aquí una disciplina útil: verificar los datos actuales del registro, guardar copias fechadas, comparar organización, fechas y contactos, y expresar las conclusiones como válidas para un momento determinado. Es una metodología de verificación y continuidad, no una operación sustitutiva del registro. NRS investiga, aboga, convoca y representa a miembros que lo autoricen expresamente; no opera un registro, RPKI, WHOIS o RDAP, ni administra apelaciones, acuerdos, elecciones, custodia o continuidad. Atribuirle esas funciones convertiría una técnica de evidencia en una competencia que no posee.

El método editorial de los expedientes de asignación añade otra exigencia: seguir la cadena solicitud, evaluación, decisión, inventario y registro público. Aplicado a este caso, obliga a no aceptar un resultado final sin las transiciones que lo produjeron. El análisis operativo de Larus, por su parte, recuerda que una decisión de coordinación puede alterar silenciosamente la continuidad de infraestructura cuando afecta filtros, herramientas o acceso a recursos. Esa repercusión práctica es real, pero no es equivalente a poder regulatorio.

El mejor argumento a favor y el límite que no debe cruzar

El argumento más sólido a favor de la decisión parte de una restricción previsible: el campo de dos octetos era finito. Esperar hasta el último momento habría comprimido las actualizaciones, reducido el tiempo de prueba y elevado el riesgo de una carrera por conservar valores estrechos. El calendario de tres fases ofrecía años de aviso. Empezaba con solicitudes voluntarias, invertía la preferencia después de dos años y retiraba la distinción un año más tarde. El protocolo permitía que pares nuevos y antiguos se entendieran de forma incremental.

Vista así, la resolución es un ejemplo valioso de una capa común y delgada que coordina unicidad y compatibilidad sin exigir una actualización simultánea de toda la red.

El mejor argumento contrario no niega la necesidad de ampliar el espacio. Advierte contra la confianza excesiva en el calendario y en la propia institución. En AFRINIC-4 hubo participantes que consideraban que el asunto aún no era pertinente. La cronología de aprobación se extiende hasta noviembre y no se explica limpiamente. Los informes posteriores documentan formularios que cambiaron después del hito de 2010, equipos incompatibles e intercambios. Una fecha puede organizar el trabajo, pero no sustituye la capacidad desplegada.

Si una organización privada convierte la fecha interna en razón suficiente para negar una excepción técnicamente justificada o forzar una configuración insegura, deja de coordinar el mínimo necesario e intenta mandar sobre una red que no opera.

La respuesta no es abandonar la secuencia ni absolutizarla. Es mantener las preferencias escalonadas y someter cada fase a evidencia abierta: preparación por componente, pruebas publicables, recuentos de excepciones, reconciliación de inventario y notación, procedimientos de intercambio y retorno, y adopción reversible por parte del operador. El registro publica hechos sobre compatibilidad y mantiene la unicidad. El operador decide el despliegue efectivo con conocimiento de sus pares, equipos y riesgos.

Este reparto responde a una doctrina de contable privado. AFRINIC puede llevar un libro único de ASN, recibir inventario, registrar asignaciones, modificar la opción predeterminada de sus formularios y publicar evidencia fechada. No es dueña de los números, de las rutas, de los encaminadores ni de las organizaciones que los utilizan. Una fila de base de datos no crea título de propiedad, jurisdicción o condición de derecho público. El empleo de la palabra “consenso” en un proceso interno tampoco genera soberanía comunitaria.

Por la misma razón, ni AFRINIC ni IANA, IETF, NRO, ICANN u otra organización técnica adquieren mediante estos documentos poder soberano, legislativo, regulatorio, policial, acusador, judicial, punitivo o confiscatorio. Sus archivos tienen fuerza probatoria limitada al acto, especificación o asiento que contienen. Pueden coordinar semántica estable, unicidad, resolución de conflictos, compatibilidad del protocolo y prueba portable. No pueden convertir un desacuerdo técnico en delito, un identificador en propiedad creada por ellos o una incompatibilidad en fundamento para excluir coercitivamente a un operador.

La transición real, en última instancia, ocurrió allí donde el código compatible, las pruebas y el despliegue consentido produjeron encaminamiento interoperable. Una resolución podía iniciar trabajo y fijar preferencias. No podía enseñar a un encaminador antiguo a leer cuatro octetos. Esa diferencia entre declarar y hacer funcionar no debilita la coordinación; la mantiene dentro del terreno en el que puede ser legítimamente útil.