Summary

  • RFC 8008 combines different CDNI footprint constraints by narrowing candidacy. Putting IPv4 and IPv6 prefix objects side by side can therefore describe an empty eligible client set, not dual-stack coverage.
  • RFC 9388 supplies an explicit footprintunion for alternatives. It does not erase separate enclosing restrictions or make different capabilities available everywhere on a combined map.
  • Coverage eligibility, mandatory content-policy enforcement, coherent map versions and capacity advice answer different questions. Keeping those questions separate preserves local routing decisions without inventing a central permission system.

The addition that subtracted everyone

Imagine preparing a downstream delivery advertisement. One footprint object covers an IPv4 prefix. Another covers an IPv6 prefix. The intention seems unexceptional: this CDN should be considered for requests coming from either address family. Two populations are listed where previously there was one. A presentation slide might show a growing service area.

The construction does not necessarily say what its author thinks it says. Under the cumulative narrowing described in Appendix B of RFC 8008, different footprint constraints apply together. A Request Routing source address must meet both. An address used for that decision cannot simultaneously belong to an IPv4 prefix and an IPv6 prefix.

This is not a hypothetical failure attributed to an unnamed operator. Figure 2 of RFC 9388 uses the construction to demonstrate an empty client set. Nor does it mean that an endpoint cannot be dual-stack. A device can use both families; a particular source address evaluated against those two constraints is still one or the other.

The distinction is modest enough to look like an encoding detail and consequential enough to determine who receives traffic. Counting advertised ranges will not reveal it. Neither will confirming that both address-family labels are recognized. The decision depends on the operator between the constraints.

For an upstream CDN, that operator defines which downstreams become candidates. For a downstream CDN, it expresses the limits of its willingness and capability. If a consumer silently treats every growing list as a growing union, it has changed the service statement. The consumer may be making a routing choice that neither participant actually advertised.

A footprint belongs to a capability

CDNI interconnects content delivery networks so that one can delegate work to another. The problem statement and use cases concern arrangements such as extending delivery reach. They do not turn the interconnected networks into one owner of all resources or one universal market for interchangeable service.

In the CDNI framework, advertisement, redirection, metadata, control and logging serve related but distinct purposes. The footprint and capabilities advertisement interface, FCI, helps an upstream select a suitable downstream. It is not itself evidence that a later content request has been served.

RFC 8008 chose capabilities with footprint restrictions. A capability object describes a supported feature and the footprint within which it applies. A network that supports HTTPS in one part of its service area may not support it in another. Maintenance or a different set of serving resources can change that relationship.

Flatten those statements into “supports HTTPS” plus “covers these regions,” and a crucial join disappears. The two checkboxes may each be true without being true for the same request. The apparent completeness of the combined map masks the missing intersection between the required feature and the relevant source.

Acquisition and delivery also have different roles. Support for a protocol used to obtain content from an upstream or origin is not automatically support for delivering it to the requester. If both capabilities are necessary to a chosen service arrangement, they must each apply where that arrangement requires them. Unioning their separate advertised footprints does not manufacture a client location where all prerequisites hold.

That is an analytical implication of preserving the capability objects, not a new universal CDNI checklist. Different content and commercial arrangements need different features. The error is not choosing a short checklist; it is using support established in one scope as if it satisfied a requirement in another.

Alternatives must be expressed as alternatives

The RFC Editor’s current record for RFC 8008 identifies RFC 9388 as an update. Reading the 2016 semantics as the whole present interface would miss the mechanism specifically provided for the earlier empty-set problem.

RFC 9388, published in July 2023, introduces footprintunion. Its value is an array of footprint objects. An IPv4 object and an IPv6 object inside that union can express the intended alternatives: a source may match one branch or the other.

The update does not declare all footprint lists to be unions. It gives alternatives an explicit place. Conditions outside that place keep their narrowing effect. The RFC’s geographical example combines an ASN restriction with a union of country and subdivision alternatives. The enclosing ASN condition remains relevant whichever geographical alternative matches.

That difference prevents two opposite mistakes. A flat conjunction of incompatible address-family constraints excludes everyone. A consumer that changes every condition into an alternative can admit sources that were meant to remain excluded. Both errors can appear behind the same tidy “coverage” label.

The standard prohibits a footprintunion from containing another footprintunion. A union of unions can be flattened without changing union meaning, so the restriction reduces syntactic complexity without removing that expressive capacity. It does not justify flattening a conjunction around a union. Reducing one kind of nesting is not a licence to discard another kind of condition.

A useful review therefore asks what a concrete source satisfies, rather than whether the advertisement looks comprehensive. The logical structure should survive simplification. A shorter equivalent statement is helpful; a shorter statement that changes who qualifies is a different service promise.

Where a request comes from is not where a server stands

“Coverage” encourages a geographical reading. An operator has a facility in a country, so perhaps it covers the country. It can be reached over the public Internet, so perhaps it covers every reachable user. Those inferences are not the footprint semantics.

RFC 8008 describes the area from which requests originate and to which a CDN is willing to deliver. An ISP-built CDN may concentrate serving resources near its own subscribers. That does not mean public reachability alone determines which outside traffic it will accept. Contractual, administrative and operational choices matter.

An ASN footprint also needs interpretation. The advertisement supplies a descriptor; CDNI does not define the universal method by which every upstream determines which address ranges belong to that ASN. Geographic descriptors likewise do not supply a universally authoritative geolocation measurement.

RFC 9388 adds subdivisioncode, using ISO 3166-2 codes, to express finer geographical constraints. A smaller named area improves the vocabulary of a statement. It does not prove the accuracy of the upstream’s source-location inference, establish legal residency of every processing step or show the location of every copy of content.

The CDNI parameters registry records these types so that participants can share their meanings. The registry does not decide whether a particular source is correctly located. That judgment still depends on the agreed interpretation and evidence available to the participants.

This is where local responsibility becomes visible. A boundary can be explicitly advertised while the evidence for placing a request inside it remains uncertain. Hiding that uncertainty under a bright region on a map is not interoperability. It is an unacknowledged assumption attached to an interoperable descriptor.

A parent’s coverage can depend on someone else

A first-level downstream need not serve every advertised area using only its own resources. Cascaded CDNs can contribute coverage. RFC 8008’s illustrative use case asks how a transitive downstream’s loss of a delivery capability affects the upstream’s choice of its first-level partner.

The important unit is the affected combination of capability and footprint. A descendant may supply one protocol in a subset that the first-level network cannot otherwise serve. Losing that contribution need not eliminate every protocol in every area. It can nevertheless invalidate the particular choice on which an upstream was relying.

An aggregate partner map can conceal this dependence. It shows the first-level network’s name and an area without preserving which feature depends on the next participant. When that feature changes, an upstream may keep choosing an apparently unchanged partner for requests whose prerequisite has disappeared.

The answer is not necessarily to reveal a downstream’s entire internal topology. RFC 8008 recognizes that resource-based footprints can expose structure and does not make such disclosure universally mandatory. What matters for selection is the service statement that remains valid, not every machine behind it.

A constrained update can therefore carry more useful information than a grand topology map. It can say which capability no longer applies to which sources while leaving other local work and unaffected arrangements alone. Narrow scope is not incomplete governance when it is the scope of the actual changed commitment.

Understanding metadata is not enforcing it

A request can match a delivery footprint and still concern content the downstream must not serve. RFC 8006 distinguishes metadata handling from enforcement. If mandatory-to-enforce metadata cannot be understood or its required functions cannot be performed, the corresponding content must not be served.

This remains relevant even when capability knowledge was exchanged in advance. Support can fluctuate or be misunderstood. RFC 8006 requires the downstream to evaluate the associated metadata and reject requests whose mandatory conditions cannot be enforced. An earlier capability advertisement does not waive the content-specific condition.

Similarly, safely passing metadata to another CDN is not equivalent to being able to serve the content oneself. Transit can be legitimate without local enforcement support where the specified redistribution rules permit it. Turning that forwarding ability into a local delivery claim would cross a different boundary.

RFC 8008 allows unrecognized optional capability or footprint types to be ignored under a concrete protocol’s negotiated handling. That extensibility provision is not proof that an unknown requirement has been met. An upstream cannot turn “I selected using what I understood” into “the downstream can enforce every condition this content needs.”

The CDNI requirements document provides context for the interfaces; it does not replace their specific semantics with a general service guarantee. The disciplines are complementary: understand the advertised scope, establish the necessary feature support and retain mandatory checks at the content decision.

Capacity now has advice of its own

It would be wrong to conclude from RFC 8008’s bounded initial design that modern FCI can never convey load. The current registry includes FCI.Telemetry and FCI.CapacityLimits, specified in RFC 9808, published in July 2025.

The extension provides utilization information and usage limits to inform delegation. It explicitly makes that information advisory, not a guarantee, commitment or reservation of capacity. A limit is scoped to the footprint of its enclosing advertisement; applicable limits are considered together, rather than selecting only whichever looks most specific.

This advances the information available without erasing the earlier questions. A request can be inside an advertised capability footprint while advice counsels against sending more traffic. Conversely, apparently available headroom does not put an otherwise excluded source inside that footprint or confer unsupported content-policy enforcement.

Usage evidence also needs the same meaning as the limit being compared. A metric referring to another source, another footprint or another aggregation window cannot automatically answer the intended question. Reporting lag matters when interpreting an adjustment. None of those observations makes an advisory number a held slot for the next request.

The governance benefit is a clearer separation of decisions, not a universal scoreboard. Capability eligibility asks whether this arrangement fits the request. Capacity advice informs how much traffic to delegate under the stated limits. The upstream still has to make a choice; the downstream’s advice is not a promise that every chosen request will complete successfully.

A named area needs its versioned meaning

RFC 9241 specifies advertisement transport using ALTO. The RFC Editor record identifies the document independently of the base semantics. ALTO provides a concrete way to retrieve capabilities with footprints, not a replacement definition of what each capability promises.

An ALTO PID footprint can depend on a network map. The advertisement names its dependent resource and carries the corresponding version tag. The ALTO protocol supplies the map framework. A stable area identifier does not by itself fix the addresses currently associated with it.

A consumer that attaches an advertisement from one dependency version to a differently defined map can give the same label a different service area. This is a consistency problem, not a demand for synchronized global clocks. The question is which map the statement refers to, not whether every CDN shares a precise wall-clock reading.

There is another easy inversion. Under RFC 9241, an empty array of advertised capabilities means no mandatory-to-implement capabilities for any footprint. Within a capability object, however, an absent, null or empty footprint list means global coverage for that object’s capabilities. “Empty” has opposite operational effects at different levels.

Filtering does not remove the need for context. A filtered advertisement retains the canonical full advertisement’s version tag. A partial response is useful for the requested portion; it is not automatically evidence about every portion not requested.

ALTO Entity Property Maps define domain-specific hierarchy and inheritance. RFC 9388’s subdivision-code domain has no hierarchy or inheritance. One cannot borrow address-prefix inheritance rules to assume that a country property automatically supplies a subdivision property.

ALTO incremental updates can convey changes efficiently. They help keep a locally interpreted statement current. They cannot repair the wrong combination operator. A rapidly updated misunderstanding is still a misunderstanding.

Common meaning without a common permission office

RFC 8008 requires authentication and integrity in protocols carrying these advertisements. Otherwise forged claims of no footprint or no capability could prevent delegation. Authenticating the statement’s source is essential; proving its quality or truth is another task. Commercial commitments and later audits remain relevant outside the semantic vocabulary.

Lu Heng’s minimum-initial-specification argument offers a useful way to frame the result. Participants need enough common meaning to understand the initial arrangement. Future routing and service decisions remain local. New expressive types can be adopted voluntarily through usable, understood agreements.

That is not permission to ignore obligations already accepted. A legitimate union can widen an advertised choice without overriding an enclosing restriction. A legitimate optional extension can add information without silently removing a mandatory content condition. Voluntary adoption concerns whether to take on an arrangement, not whether to reinterpret its commitments after others rely on them.

The Policy Mirror also makes the smaller surface worth examining: the interface through which policy becomes operational. Here that surface is a consumer’s interpretation of scope, conjunction, alternatives and dependency versions. Its defaults can make decisions that look like mere data handling.

The CDNI map matters because it can become that decision surface. Keeping the map honest does not require a central office to approve each request. It requires every actor to see which advertised statements apply to the request at hand—and which further decisions or uncertainties those statements do not settle.