Resumen

  • Las restricciones de cobertura de RFC 8008 se acumulan y estrechan el conjunto de fuentes admisibles. Añadir objetos IPv4 e IPv6 uno junto al otro puede dejarlo vacío.
  • RFC 9388 permite expresar alternativas mediante footprintunion, sin eliminar las condiciones externas ni extender cada capacidad a todas las zonas del mapa.
  • La compatibilidad de una solicitud, la aplicación de sus políticas y los consejos de capacidad son decisiones distintas. Conservar sus límites evita que una simplificación de datos se convierta en una autoridad de encaminamiento no reconocida.

Un proveedor completo sobre el papel

Una comparación de proveedores puede reunir tres datos convincentes: cobertura amplia, entrega mediante HTTPS y capacidad para obtener contenido del origen. Cada afirmación puede ser cierta. Lo que la comparación quizá no demuestra es que las tres se cumplan para la misma solicitud, en el mismo ámbito.

Supongamos que una función está disponible para unas fuentes y otra para fuentes diferentes. Al unir ambas áreas y presentar las funciones como atributos generales del proveedor, el resumen parece describir una oferta común. En realidad, ha borrado la relación que permitía saber dónde estaba disponible cada función. No se trata de un caso documentado de mala conducta empresarial, sino de un riesgo de interpretación.

El modelo elegido en RFC 8008 es el de capacidades con restricciones de cobertura. El anuncio no debería leerse como una lista independiente de territorios y otra de funciones. Una capacidad puede faltar en una parte de la cobertura, aunque el mismo CDN la ofrezca en otras.

Esto importa al elegir el CDN descendente al que delegar tráfico. Una casilla global que diga «HTTPS» no prueba que esa entrega sea posible para la fuente que se está evaluando. Y obtener contenido desde un origen no es la misma función que entregarlo al usuario mediante el protocolo necesario.

No todas las solicitudes requieren las mismas capacidades. La conclusión no es imponer una lista universal de controles. Es conservar el alcance de las funciones que necesita el servicio elegido. Las verdades separadas no bastan para demostrar su compatibilidad conjunta.

El planteamiento del problema CDNI y sus casos de uso explican la cooperación entre redes, por ejemplo para extender su alcance. Esa cooperación no convierte a todos los participantes en propietarios de una infraestructura única ni hace intercambiables todas sus ofertas.

Dos familias de direcciones, ningún cliente admisible

Hay una forma especialmente clara de ver el problema. Un anuncio contiene un objeto de cobertura para un prefijo IPv4. Su autor añade otro para un prefijo IPv6 y espera cubrir clientes procedentes de cualquiera de las dos familias. El mapa parece haber crecido.

La semántica de la lista puede producir el efecto contrario. El anexo B de RFC 8008 establece un estrechamiento acumulativo al combinar diferentes restricciones de cobertura. La dirección de origen utilizada para decidir debe cumplirlas conjuntamente, no elegir una de ellas.

Una dirección examinada no puede ser a la vez IPv4 e IPv6. Por tanto, la combinación excluye a todas las fuentes. La figura 2 de RFC 9388 muestra precisamente ese conjunto vacío. Es un ejemplo de la especificación, no la noticia de una interrupción real.

No significa que un dispositivo no pueda funcionar con ambas familias. La decisión se refiere a una dirección de origen concreta. Tener varias posibilidades de conectividad no hace que una misma dirección satisfaga dos condiciones incompatibles.

El error no aparece al contar objetos. Hay más objetos y más rangos descritos. Aparece al preguntar cómo se combinan. Un «y» estrecha; un «o» permite alternativas. La familiaridad visual de una lista no determina cuál de esos operadores le corresponde.

Si el consumidor interpreta todas las listas como uniones, puede evitar por accidente el conjunto vacío, pero cometer el error opuesto en otras restricciones: aceptar fuentes que el anunciante quería excluir. Una lectura conveniente en un ejemplo no es una lectura correcta del contrato.

El lugar preciso de la unión

La ficha actual de RFC 8008 señala que RFC 9388 lo actualiza. La semántica de 2016 debe leerse junto a esa ampliación, no como una limitación eterna de la interfaz.

RFC 9388, publicado en julio de 2023, incorpora footprintunion. Su valor contiene objetos de cobertura que representan alternativas. Los objetos IPv4 e IPv6 incluidos dentro de esa unión sí pueden expresar la intención de aceptar fuentes de una familia o de la otra.

La ampliación no convierte en alternativas todas las restricciones del anuncio. Las condiciones situadas fuera de la unión mantienen su efecto de estrechamiento. El ejemplo geográfico de la especificación combina una condición de ASN con una unión de país y subdivisión: cualquiera de las alternativas geográficas sigue sometida a la condición exterior.

Esta separación permite ampliar una parte del enunciado sin borrar el resto. Es la diferencia entre «este grupo de fuentes, en una de estas zonas» y «este grupo o cualquiera de estas zonas». La segunda fórmula puede admitir solicitudes que la primera no contempla.

RFC 9388 prohíbe incluir una footprintunion dentro de otra. Una unión de uniones puede aplanarse conservando las mismas alternativas. Pero una condición conjunta que rodea una unión no puede desaparecer sin cambiar el sentido.

La simplificación debe evaluarse por equivalencia, no por longitud. Una representación más breve que da los mismos resultados para las mismas fuentes es útil. Una representación más breve que cambia quién es admisible es una declaración de servicio distinta.

La cobertura no certifica la geografía

La palabra «cobertura» suele sugerir un mapa de instalaciones. Sin embargo, RFC 8008 describe las fuentes de solicitudes a las que el CDN está dispuesto a servir. No se limita a localizar los servidores de ese CDN.

Un proveedor de acceso puede situar recursos cerca de sus abonados y construir un servicio para ellos. Que los recursos sean alcanzables desde otras redes no demuestra que el operador quiera aceptar todas las solicitudes externas. La disponibilidad de una ruta pública y la voluntad de prestar servicio son cuestiones diferentes.

Los descriptores también requieren interpretación. Un anuncio basado en ASN necesita una asociación entre el sistema autónomo y sus rangos de direcciones. CDNI no define una fuente universal que resuelva esa asociación para todos los participantes. Tampoco fija un procedimiento único para atribuir un país al origen de una solicitud.

RFC 9388 añade subdivisioncode, basado en ISO 3166-2, para expresar zonas más pequeñas que un país. El vocabulario se vuelve más detallado; la medición no se vuelve automáticamente más exacta. Un código de subdivisión no prueba que la solicitud haya sido ubicada correctamente.

Tampoco certifica la ubicación legal de todo el tratamiento o de todas las copias de contenido. La zona de origen aceptada para una delegación no equivale a la residencia física de cada recurso que interviene en ella.

El registro de parámetros CDNI proporciona nombres y definiciones compartidos. No decide si una dirección concreta está bien situada en el mapa. Esa valoración depende de los acuerdos y la evidencia de quienes realizan la decisión.

La incertidumbre no desaparece porque el formato sea común. Un anuncio puede ser legible y estar autenticado, mientras la atribución de una fuente a una zona sigue siendo discutible. La buena interoperabilidad permite distinguir esos niveles en vez de ocultarlos bajo un color.

Una capacidad heredada de la cadena

Un CDN descendente puede anunciar cobertura que depende de otro CDN más abajo en una cadena de delegación. El interlocutor de primer nivel no tiene por qué servir toda su oferta exclusivamente con recursos propios.

El marco CDNI permite entender esas relaciones entre interfaces y participantes. El anexo A de RFC 8008 plantea qué ocurre cuando un CDN transitivo pierde una capacidad de entrega que sostenía una parte de la cobertura del primer descendente.

La unidad relevante es la combinación afectada de capacidad y ámbito. La pérdida puede corresponder a un protocolo en una subzona. No implica necesariamente que desaparezcan todas las funciones del primer CDN en todos los lugares.

Sin embargo, un mapa agregado puede dejar intacto el nombre del proveedor y borrar la dependencia que justificaba la elección. El CDN ascendente continúa viendo un socio conocido, aunque ya no tenga una base válida para delegar cierto tipo de solicitudes procedentes de determinadas fuentes.

La respuesta no exige divulgar toda la topología interna. RFC 8008 reconoce que las descripciones basadas en recursos pueden exponer esa estructura y no las hace universalmente obligatorias. El dato necesario para elegir puede ser mucho más acotado.

Una actualización precisa permite retirar una capacidad de la parte donde ya no se ofrece y conservar los demás servicios. Tratar cada pérdida local como caída de toda la organización sería tan impreciso como mantener una cobertura universal que ya no existe.

La política del contenido sigue en vigor

Un origen admisible no hace admisible cualquier contenido. RFC 8006 separa las capacidades de lectura y transmisión de metadatos de la posibilidad de aplicar las reglas que esos metadatos exigen.

Cuando una propiedad obligatoria de aplicar no se entiende o no puede ejecutarse, el CDN descendente no debe servir el contenido correspondiente. Una coincidencia favorable en el anuncio FCI no elimina esa obligación.

La comprobación importa incluso si los socios habían intercambiado antes información de capacidades. El soporte puede fluctuar o haber sido mal interpretado. El descendente debe evaluar los metadatos asociados y rechazar las solicitudes cuyas condiciones obligatorias no puede cumplir.

En determinados casos puede ser seguro retransmitir metadatos a otro CDN sin poder servir localmente el contenido. Esa retransmisión depende de las reglas previstas para los metadatos. Poder actuar como tránsito no atribuye automáticamente el poder de entregar.

RFC 8008 permite ignorar tipos opcionales que no se entienden conforme al manejo definido por el protocolo concreto. Dicho protocolo debe tratar la negociación y los casos no soportados. La tolerancia a una ampliación desconocida no prueba que una condición necesaria para una solicitud ya esté satisfecha.

El documento de requisitos CDNI sitúa esas funciones en su contexto. No las convierte en una garantía general de servicio. El anuncio orienta la elección; las obligaciones del contenido permanecen en el punto donde deben aplicarse.

El consejo de capacidad tiene otro alcance

Sería incorrecto afirmar que FCI nunca informa de la carga actual. El registro vigente incluye FCI.Telemetry y FCI.CapacityLimits, definidos por RFC 9808 en julio de 2025.

La extensión aporta utilización y límites para orientar cuánto tráfico delegar. Es información consultiva: la especificación no la presenta como garantía, compromiso o reserva de capacidad. Los límites conservan el ámbito de cobertura del anuncio que los contiene.

Además, se deben considerar todos los límites aplicables conjuntamente, no seleccionar solamente el que parezca más específico. El consejo amplía la información disponible, pero no convierte una fuente excluida en fuente admisible ni proporciona una función de seguridad ausente.

Las medidas de uso necesitan corresponder a los límites examinados. Otra fuente de telemetría, otro ámbito o una ventana de agregación diferente pueden dar un número convincente que responda a otra pregunta. El retraso de la observación también condiciona qué se puede inferir de un ajuste.

Hay, por tanto, dos decisiones distintas. La elegibilidad determina si la solicitud encaja en la capacidad anunciada. El consejo de capacidad ayuda a decidir cuánto tráfico enviar. Ninguna de ellas certifica por sí sola que una solicitud futura tendrá éxito.

Ese límite favorece una responsabilidad clara. El descendente informa; el ascendente decide. El consejo no convierte al anunciante en quien aprueba cada solicitud, ni hace del consumidor el dueño de recursos que solo ha visto descritos.

Un nombre estable puede señalar otro conjunto

RFC 9241 especifica el transporte de anuncios FCI mediante ALTO; su registro en RFC Editor permite distinguir ese documento de la semántica base. El protocolo proporciona una forma concreta de recuperar capacidades con restricciones, no redefine todas sus promesas.

Cuando una cobertura se expresa mediante un PID ALTO, puede depender de un mapa de red. El protocolo ALTO ofrece el marco de esos recursos. El anuncio identifica la dependencia y la etiqueta de versión correspondiente.

Mantener el mismo nombre de área no demuestra que el conjunto de direcciones que representa sea el mismo. Asociar un anuncio a una versión distinta de su mapa puede alterar silenciosamente a qué fuentes se aplica una capacidad.

La cuestión es la coherencia del significado, no sincronizar todos los relojes del mundo. Una etiqueta de versión no mide latencia, calidad de entrega ni voluntad futura de aceptar cualquier volumen.

El formato también contiene un contraste que no debe reducirse a una regla genérica sobre listas vacías. En RFC 9241, una lista vacía de capacidades anunciadas significa que no hay capacidades obligatorias de implementar para ninguna cobertura. Dentro de un objeto de capacidad, una cobertura ausente, nula o vacía significa cobertura global para sus capacidades.

Filtrar información no elimina ese contexto. La etiqueta de versión de un anuncio filtrado corresponde al anuncio completo del que procede. La respuesta parcial facilita la consulta de lo solicitado; no da automáticamente un inventario de incompatibilidades en todo lo que no se consultó.

Los mapas de propiedades de entidades ALTO establecen la jerarquía y la herencia según el dominio. El dominio de subdivisiones geográficas de RFC 9388 no tiene jerarquía ni herencia de propiedades. No corresponde trasladarle las reglas de los prefijos de direcciones.

Las actualizaciones incrementales ALTO ayudan a comunicar cambios con eficiencia. Un mecanismo de actualización puede mejorar la oportunidad de la información, pero no corrige un operador interpretado al revés. Una equivocación más reciente sigue siendo una equivocación.

Acuerdos comprensibles sin permiso central

RFC 8008 exige autenticación e integridad en los protocolos que transportan anuncios. Una falsificación que declare ausencia de cobertura podría impedir la delegación. Saber de quién procede la declaración resulta esencial.

No obstante, ese origen autenticado no certifica la precisión geográfica ni el rendimiento. La confianza comercial, los acuerdos y las verificaciones posteriores siguen teniendo un papel fuera de la semántica común.

La propuesta de Lu Heng sobre una especificación inicial mínima ofrece una lectura útil: los participantes necesitan un significado compartido suficiente para iniciar la relación, mientras sus decisiones futuras permanecen locales. Las nuevas expresiones pueden adoptarse voluntariamente cuando se entienden y sirven a un acuerdo concreto.

La adopción voluntaria no autoriza a ignorar condiciones ya aceptadas. Una unión permite alternativas declaradas; no anula una restricción externa. Un tipo opcional no entendido no puede darse por satisfecho si el contenido necesita la condición que representa.

En The Policy Mirror, el interés por la superficie donde la política se vuelve práctica ayuda a localizar el riesgo. Aquí está en el modo de interpretar una lista, delimitar una capacidad y resolver el significado de una referencia.

El mapa CDNI no tiene que sustituir a quienes deciden. Debe conservar lo suficiente para que sepan qué están decidiendo. Una cobertura que crece de verdad amplía alternativas utilizables. Un resumen que solo crece porque borró las restricciones amplía, sobre todo, una promesa que nadie había formulado.