摘要

  • RFC 8008 中不同覆盖约束会累积收窄候选范围。把 IPv4 与 IPv6 前缀对象直接并列，可能得到空的合格客户端集合，而不是双栈覆盖。
  • RFC 9388 用显式 footprintunion 表达可选分支，但不会取消外部约束，也不会把一项能力扩展到整个合并覆盖图。
  • 客户端资格、内容条件执行、地图版本含义与容量建议回答不同问题。保持这些边界，才能支持本地选择，而不是让一个汇总图表暗中获得决策权。

两份真实声明，拼不出一项完整服务

假设合作方的介绍中有两句话：它能够使用 HTTPS 向一部分请求来源交付内容，也能够为另一部分范围提供某项必需的内容策略执行能力。两句话都可能真实。把两个范围涂在一张图上，再把两项能力勾选在同一张清单里，却不能证明图内任何一个请求都能同时获得两项服务。

这是一个说明性的判断场景，不是对某家公司的生产事故指控。问题在于，真实声明可以在汇总时失去各自的适用范围。清单保留了“有这种能力”，覆盖图保留了“涉及这些地方”，连接二者的关系反而被删掉了。

RFC 8008 为 CDNI 选择的是“附带覆盖范围限制的能力”模型。下游 CDN 可以总体上支持某个协议，却在特定区域不支持它。维护、服务资源差异，或者进一步下游的能力变化，都可能影响这种局部支持。

因此，上游要判断的不是合作方是否曾经、在某处拥有某项能力，而是该能力能否在本次请求所涉及的范围内使用。如果选定的内容安排需要多项能力，各项必需能力都应在相关范围内成立。把它们分别成立的范围求并集，不会制造一个同时满足全部前提的位置。

这并不是为所有内容发明一份统一核准清单。不同内容、商业安排和交付方式需要不同功能。真正不能省略的是已经确定的必需功能与其适用范围之间的联系。

CDNI 的问题陈述和使用场景讨论的是内容分发网络如何合作，例如扩展交付范围。合作不意味着网络资源归属于同一个主体，也不意味着每家参与者在每个地方都提供可互换的服务。共同语言连接不同承诺，不会自动抹平它们。

多写一个范围，为什么会把所有客户端排除？

标准中有一个比抽象讨论更直观的例子。一个能力广告列出了 IPv4 前缀对象，又在旁边列出了 IPv6 前缀对象。作者的意思可能很自然：这两类客户端都可以成为服务对象。范围列表更长了，介绍材料中的覆盖图也更大了。

但是，RFC 8008 附录 B 说明，不同覆盖类型的约束会累积收窄下游的候选资格。并列条件不是任意选择一个满足，而是共同约束判断。用于这一次请求路由判断的来源地址必须落在各项条件允许的集合中。

同一个被判断的地址不可能既是 IPv4 地址，又是 IPv6 地址。因此，这种并列方式无法匹配任何来源。RFC 9388 的图 2 明确用这个构造说明空的客户端集合。这里引用的是规范例子，不是虚构一个真实中断来增强文章的戏剧性。

双栈终端并没有被否认。终端可以通过两种地址族通信，但某次判断所使用的来源地址仍然属于其中一种。不能用设备还拥有另一个地址的事实，使被检查的同一个地址同时满足互不相容的条件。

更重要的是，读者必须先弄清本次路由决定针对哪一个请求路由来源。把终端、某个地址、某片地理范围和服务机器的位置都合并成“用户所在的地方”，会在逻辑问题之外再增加一层范围混淆。

从列表长度看，这次修改像扩容；从约束结果看，它却是归零。只检查两个地址族名称是否出现，不能识别这个差别。需要检查的是条件之间的运算关系。“而且”会收窄集合，“或者”才会表达可选路径。看起来相似的一串对象，可以承载截然不同的服务声明。

显式并集能扩展选择，却不能带走外层边界

RFC Editor 的 RFC 8008 当前记录列明，RFC 9388 对它作了更新。不能把 2016 年的初始表达能力写成今天仍然不可扩展的封闭体系。

2023 年 7 月发布的 RFC 9388 增加 footprintunion。它的值是一组覆盖对象，用于将这些对象表示为可选分支。IPv4 和 IPv6 对象放在这个显式并集内部，就能表达来源匹配任意一种地址族的意图。

更新的范围同样重要：它没有宣布所有覆盖数组今后都按并集解释。放在并集外面的条件，仍然具有收窄作用。标准中的地理示例将 ASN 条件保留在外部，再与国家和国家分区的并集组合。来源无论匹配哪条地理分支，都不能因此跳过外部 ASN 约束。

这意味着，“在指定网络内，并且位于这两类区域之一”，不能被简化成“属于指定网络，或者位于这些区域”。后一种解释会接纳前一种声明没有接纳的来源。它不是更友好的展示，而是更宽的承诺。

RFC 9388 不允许 footprintunion 再包含另一个 footprintunion。并集的并集可以展开为一个并集，保持相同的可选范围，因此这一语法限制降低了复杂度。但并集外的合取条件并不是同一种嵌套，不能借“展开”之名一并删掉。

真正有效的简化，应当对同一来源得到相同资格结果。文本更短、对象更少或图表更整齐，都不是语义等价的证明。若简化后有新的来源被纳入，或者原本允许的来源被排除，就应认识到服务声明已经变化，而不只是材料被压缩。

图上的区域，不等于服务器的位置

覆盖图容易让人想到设施地图：某处有机器，就覆盖某处；机器能够从公网访问，就覆盖所有可到达的客户端。RFC 8008 的含义并不是这种推断。

它关注请求可以从哪里发出，以及 CDN 愿意向哪些来源提供内容。一个为接入用户专门建设的 CDN，可能把服务资源放在订户集中的地方。即使其他网络能够到达这些资源，运营方仍可能不愿接受所有外部请求。可达性不是商业意愿，也不是已经成立的交付安排。

ASN 描述也需要解释。标准并没有为所有上游规定一种统一方法，用来确定某个 ASN 对应哪些地址范围。同样，国家代码不能自行证明一条请求确实来自被标注的国家；来源的地理判定方法仍然在共同描述之外。

RFC 9388 增加的 subdivisioncode 使用 ISO 3166-2 国家分区代码，能够表达比国家更细的范围。词汇更精细，不代表测量自动更准确。分区代码既不是来源定位证明，也不是内容处理、保存和所有副本都位于同一司法辖区的证明。

IANA 的 CDNI 参数登记表统一了类型名称与定义，使参与者能够交换这些描述。登记表不会替某次请求判断地理归属，也不会替运营方证实某项范围推断的质量。

因此，一条声明可以格式清楚、来源可信，而其来源定位仍有不确定性。治理上应把这两个层面分别呈现。不能因为双方认识同一个代码，就把一方本地的推断升级为所有参与者共同承认的事实。

合作方的一个名字，可能包含下一级的贡献

CDNI 框架把广告、重定向、元数据、控制和日志放在相互配合但不同的接口位置。广告帮助上游选择候选下游，并不证明后续内容已经交付，也不要求候选下游完全依靠自有资源完成所有范围的服务。

RFC 8008 附录 A 提出一种级联情形：第一级下游在一部分范围内，依靠更下一级的 CDN 支持某个交付协议。一旦那个贡献消失，上游如何知道自己的第一级合作方不再适用于哪些请求？

发生变化的单位，是能力与范围的具体组合。某个协议在某片区域失去支持，不一定意味着整个合作方对所有地区、所有协议都失效。但是，继续保留一个没有能力范围关系的总体图，也可能使上游照旧做出已经失去依据的选择。

一张图上只剩合作方的名字，尤其容易掩盖这种变化。名字没有变，支撑特定服务的局部贡献却变了。若采购清单和备用路由都只依赖名字加总体区域，合作关系的连续性就会被错当成全部能力的连续性。

这并不推出“必须公开每一层拓扑”的结论。RFC 8008 注意到，以资源为基础的范围可能暴露网络内部结构，并未把这种披露设为普遍必需。上游往往需要的是哪项服务声明仍然有效，而不是它背后的每一台机器。

精确的局部更新可以同时保护两件事：失效的能力不再被误用，没有受到影响的区域和能力继续发挥作用。范围小不是治理不足；当变化本来就是局部的，范围准确恰恰是保持本地自主的条件。

会读元数据，不等于能执行内容条件

某个来源符合覆盖约束，仍然可能请求一份下游不能交付的内容。RFC 8006把元数据的解析、转发与规则执行分开处理。

对于必须执行的元数据属性，如果下游不理解它，或者无法执行它要求的功能，就不得向相应请求提供内容。先前收到一个看似有利的 FCI 广告，不会让这项内容义务变成可选。

标准也考虑到能力认知可能不一致或发生波动。即使双方事先通过广告或其他协商了解了支持情况，下游仍应评估与重定向及内容请求关联的元数据，并拒绝无法执行其强制条件的请求。共同声明不能代替最终需要保留的内容判断。

在适当的元数据再分发规则下，一个中转 CDN 可能安全地继续传递自己无法本地执行的元数据。它能中转，并不表示它能向用户交付。把信息继续送到合适的参与者，与在本地拥有履行该内容条件的能力，是两种不同权能。

RFC 8008 允许具体协议按协商规则忽略不理解的可选能力或覆盖类型，并要求协议定义可选类型协商及不支持情形的处理方式。这种扩展容忍并不是“未知的必需条件已经满足”的证据。用已理解的信息选出候选者，不能被写成候选者能够执行内容所需的一切规则。

CDNI 需求文档提供各接口目标的背景，但不能取代具体规范的边界。广告用于帮助选择，内容条件在其应当执行的地方继续成立。把这些层次合成一个绿色资格标志，可能恰好删掉最重要的剩余判断。

今天的 FCI 可以讨论容量，但建议不是预留

若只读 RFC 8008 的初始设计，很容易得出过时结论：FCI 不会传递当前负载，所以覆盖之外的容量永远无从表达。当前登记表已经不是那五种初始能力的永久封闭清单。

2025 年 7 月发布的 RFC 9808增加 FCI.Telemetry 和 FCI.CapacityLimits，提供利用率及指定使用限制，帮助上游决定委派多少流量。它同时明确，这些信息是建议，不是容量保证、承诺或预留。

容量限制仍然附着于包含它的广告覆盖范围。所有适用限制都应共同考虑，而不是只挑一个看似最具体的限制。这让流量判断更有依据，却不会把原本被范围排除的来源纳入，也不会补上不存在的内容策略执行能力。

使用量和限制也必须具有相同的比较含义。一个来自其他遥测源、针对其他范围，或者使用不同聚合时间窗的数值，不会因为同样叫“利用率”就自动回答当前问题。报告滞后同样影响人们从调整中能推断什么。

这里应保留两个判断：某项内容安排是否适合这个来源，以及在适用限制与观察下应向它发送多少流量。前者不是后者，后者也不是下一次请求成功的证明。一个好看的余量数字，不是已经为本次请求锁定的服务位置。

更新后的共同语言增加了可用信息，没有消灭本地选择。下游提供建议，上游决定委派；参与者仍然要理解范围、必需功能与证据局限，而不是用一个分数接管所有决定。

地图版本限定名称的含义

RFC 9241规定使用 ALTO 传送 CDNI 广告，其当前 RFC Editor 记录可以与基础语义文档分别核对。ALTO 提供具体传输和信息资源框架，并不重新定义每项能力的承诺。

当范围用 ALTO PID 表示时，它可以依赖一份网络地图。ALTO 协议提供这些地图资源的框架。广告标明相关依赖资源及其版本，使接收方能够知道这次能力声明引用的是哪一个地址集合。

相同区域名称持续存在，不代表名称后面的地址集合从未变化。若把某次广告与另一版本地图相接，同一个名称可能被赋予不同的服务范围。此时改变的不是合作方名称，而是名称所表示的候选来源。

这是一项含义一致性问题，不是让所有 CDN 同步全球时钟的要求。版本标签告诉人们引用了什么，不会测量交付延迟或服务质量，也不会承诺未来所有流量都能被接受。

RFC 9241 中还有一个容易反转的差别：广告能力列表为空，意味着没有对任何范围提供必须实现的 CDNI 能力；而某个能力对象里的覆盖列表缺失、为空值或空列表，则意味着该对象的能力具有全局覆盖。空出现在不同层级，可以产生相反效果，不能发明一条“空就是不可用”或“空就是默认继承”的通则。

过滤也不会免除上下文。过滤广告的版本标签对应其来源的完整广告。针对某些范围的回复有助于减少信息量，但不自动证明所有未查询范围都支持或都不支持某项功能。

ALTO 实体属性地图的层级和继承规则由实体域定义。RFC 9388 的国家分区代码域没有属性层级与继承。不能把地址前缀的继承逻辑搬到地理代码上，假定国家层面的某个属性必然给每个分区提供同样声明。

ALTO 增量更新能够更有效率地传递变化，但更快的更新不会把错误的交集变成正确的并集。含义必须先被正确保存，时效改进才有意义。

共同含义不需要变成共同许可中心

RFC 8008 要求承载广告的具体协议提供完整性与认证。攻击者若伪造“没有覆盖”或“没有能力”的声明，就可能阻止本来可行的委派。认证来源因此很重要。

但是，来源认证不是地理正确性、交付质量或容量预留的证明。既有商业关系、约定和必要的后续核查仍在共同描述之外发挥作用。网络需要共享可理解的说法，而不是假装一种传输真实性已经解决所有业务真实性。

卢恒关于最小初始规范、本地未来决策与自愿采用的论述，可以帮助理解这里的制度边界。参与者先获得足以建立安排的共同含义，再保留各自对未来操作的选择权。可选扩展有实际用途、被参与者理解时，可以通过自愿协作加入。

自愿采用并不是可以事后忽略已经接受的义务。显式并集拓展了声明中的可选分支，不会撤销外部限制；不理解某个可选类型，也不会自动满足内容中不可缺少的条件。选择是否进入一种安排，与在别人依赖之后悄悄改写安排，不是同一自由。

The Policy Mirror提醒人们关注政策成为实际决定的接口。在这里，它就是条件的组合、能力适用范围及地图引用的解释。展示工具可以说自己只是汇总，却已经决定哪些来源被视为可服务。

CDNI 覆盖图的价值不在于尽可能大，而在于忠实表达每一方到底提供了什么。共同语言不必代替上游选路，也不必代替下游决定意愿。它应让双方看见决定所依赖的边界，以及那些声明没有替他们解决的问题。