Note:64 互联网协调系统的最小初始规范，本地化未来决策与自愿采纳
LARUS Limited 首席执行官兼 LARUS 基金会创始人。他致力于互联网基础设施、IP 地址市场和全球互联网治理的交叉领域，并直接参与了五大区域互联网注册管理机构的工作。本文旨在阐明号码资源在实践中的管理方式，并推进构建一个更具问责性和韧性的关键 IP 资产管理框架。
摘要（Abstract）
本文描述了一种用于互联网协调系统的设计模式，其目标是在提供共享技术参考点的同时，不在参与运行该系统的各方之上形成持续性的权威结构。本文定义了三个相互关联的原则：最小初始规范（Minimum Initial Specification）、本地化未来决策（Localized Future Decision）与自愿采用（Voluntary Adoption）。
在该模型下，初始规范仅定义实现唯一性、互操作性、共享安全性与安全所需的确定性且可本地验证的规则。在初始规范之后，未来的变更不再由中央机构批准，而是由运行代码的参与者自行选择采用、忽略、分叉或放弃。
不采用并不构成违规。未采用后续变更的参与者仍保留在其现有的兼容集合中。若某参与者产生的状态不符合另一参与者所接受的确定性规则，则该状态可被后者在本地忽略。其结果是兼容性选择、分叉、隔离或选择性互操作，而非制度性惩罚。
本文不定义线缆协议（wire protocol）。它规定了一种最佳当前实践（Best Current Practice），用于设计协议、注册系统、标识符系统及协调机制，使其不演变为永久性的治理机构。
1. 引言（Introduction）
许多互联网系统最初具有明确而狭窄的技术目的：通过共享一个公共参考点、标识空间、验证规则或类似注册的记录，使独立参与者能够互操作。随着时间推移，这些系统往往积累了实现初始互操作性所不需要的权力。
这种情况通常分三步发生：
第一，将未来问题提前纳入创始层，即使技术上尚无必要。
第二，将应由运行自身系统的参与者做出的选择，转而依赖持续性机构的认可、解释或状态判定。
第三，将发布、注册、建议或程序性批准视为足以产生操作性义务，即使参与者尚未在系统中实际采用该变更。
结果是系统变得脆弱：技术参考层演变为治理层；记录者变为守门人；协调工具变为未来控制的来源。
本文提出一种不同的设计纪律：
– 最小初始规范：仅规定实现基础互操作性、唯一性、共享安全与安全所必需的确定性共同规则。
– 本地化未来决策：在初始规范之后，未来选择由运行代码的参与者决定。参与者可选择采用、拒绝、分叉、断开或选择性互操作。任何参与者都无法改变其他持续运行兼容规则参与者的互操作性。
– 自愿采用：后续变更只有在参与者实际实现、运行、验证并采用后才成为现实。
这些原则彼此关联：
过度初始规范会将未来控制预置在共同层中；
持续性认可层会在部署后重新产生权威；
将“发布”等同于现实会使文档转变为命令。
设计直觉很简单：有效性必须由参与者可本地验证的确定性规则决定。参与者可选择采用、拒绝、分叉或选择性互操作，但最多只会退出某个兼容集合，而无法破坏其他兼容参与者之间的互操作性。
这一原则与类似**比特币（Bitcoin）**系统的经验一致：共识规则由运行验证代码的节点执行，而非由高于其上的机构强制执行。
2. 范围（Scope）
本文适用于互联网协调系统，包括但不限于：
– 共享注册系统
– 标识符系统
– 命名与编号体系
– 协议扩展机制
– 控制证明系统
– 可移植性系统
– 以及任何依赖共同技术参考点的架构
本文并不反对共同规则，而是主张这些规则应当是：
– 确定性的
– 最小化的
– 可本地验证的
– 且仅限于系统运行所必需
本文不要求区块链或任何特定技术，但要求一种设计属性：参与者应能够基于初始规范在本地判断有效性，而无需向任何权威请求许可。
3. 约定与定义（Conventions and Definitions）
3.1 要求语言（Requirements Language）
本文中的大写术语遵循 BCP 14（RFC 2119 与 RFC 8174）的定义。
3.2 术语（Terminology）
初始规范（Initial Specification）
系统首次部署所需的规则、数据结构、格式、不变量、验证流程及状态转换规则。
共同层（Common Layer）
参与者实现互操作所需的最小共享规则集合或参考结构。它不是机构，而是技术实体。
确定性验证规则（Deterministic Validation Rule）
允许参与者通过本地计算或验证判断某状态、记录或消息是否有效的规则。
全局不变量（Global Invariant）
为保持唯一性、互操作性或安全而必须保持一致的属性。
参与者（Participant）
运行、验证或依赖系统的节点、组织或实体。
兼容集合（Compatibility Set）
可互操作的参与者集合，由其验证规则决定。
采用（Adoption）
参与者对变更的实际实现与使用。
不采用（Non-Adoption）
选择不实施某变更，不构成无效。
本地拒绝（Local Rejection）
参与者在本地拒绝不符合规则的状态或消息。
分叉（Fork）
验证规则差异导致的兼容集合分裂。
协调产物（Coordination Artifact）
用于协调的文档或记录，但不自动产生约束力。
4. 问题陈述（Problem Statement）
设计者常常试图通过在创始层中写入过多内容，或设立一个持续性的机构来解释未来问题，以减少不确定性。这看似谨慎，实际上往往具有风险。
在创始层中过度规范会带来三个代价：
第一，它将未来的选择提前固化在共同层中，使变更更加困难，同时也放大了被控制或“被俘获”的影响。
第二，它在技术有效性与制度性认可之间制造了模糊地带。
第三，它会促使负责维护记录、发布文档或召集参与者的机构，将这些行为视为对未来现实的权威。
同样的问题也会在系统部署之后出现。如果一个系统需要持续性的机构来批准变更、决定状态或解释日常运行，那么该系统实际上已经形成了一个“后创始”的控制层。这个层级最初可能只是管理职能，但可能逐渐演变为治理结构，最终成为关键瓶颈。
本文的设计目标并不是改进制度性的裁量权，而是避免对这种裁量权的依赖。
一个设计良好的互联网协调系统，应在一开始就定义确定性且可本地验证的有效性规则；将非不变量的选择保留在共同层之外；并且仅在参与者在实际运行系统中自愿采用时，才使后续变更成为现实。
5. 原则一：最小初始规范（Minimum Initial Specification）
5.1 原则说明（Statement）
初始规范应仅定义实现基础互操作性、唯一性、共享安全性与安全所必需的最小确定性共同规则。
5.2 要求（Requirements）
采用该原则的设计应满足：
- 必须（MUST） 明确识别其全局不变量（Global Invariants）。
- 必须（MUST） 为每一个全局不变量定义确定性的验证规则。
- 不得（MUST NOT） 在初始规范中加入任何非必要规则，除非该规则用于维护既定的全局不变量或支持系统首次部署。
- 必须（MUST） 将验证规则与政策偏好、商业安排、制度角色、治理目标以及主观裁量相分离。
- 必须（MUST） 允许参与者在无需询问任何机构、注册系统、委员会或政策主体的情况下，在本地验证常规有效性。
- 应当（SHOULD） 定义用于本地验证所需的数据结构、签名、证明、状态转换规则、冲突处理规则或其他机制。
- 应当（SHOULD） 在可预见未来变化的情况下，定义扩展信号、版本控制、兼容性标识或分叉识别机制。
- 必须（MUST） 确保所需的协调产物具备可移植性、可审计性、可复现性与可替代性。
- 应当（SHOULD） 优先采用客观且可由机器验证的条件，而非主观判断标准。
- 不得（MUST NOT） 将未来的制度性认可设为判定有效状态的唯一途径。
5.3 设计含义（Design Implications）
“最小初始规范”并不意味着规范模糊不清，而是指只对必须成为共同基础的部分进行严格定义。
系统仍然需要足够的共同结构来运行。关键在于区分：
– 哪些内容必须成为共同规则（用于保证唯一性、互操作性、共享安全与安全）；
– 哪些内容可以保留在共同层之外（例如运营者偏好、商业实践、部署节奏或后续采用选择）。
如果一个设计无法清晰说明其全局不变量及对应的确定性验证规则，那么很可能意味着：
它引入了过多的裁量空间 而缺乏足够可验证的技术基础
6. 原则二：本地化未来决策（Localized Future Decision）
6.1 原则说明（Statement）
在初始规范之后，未来决策应保持在运行代码的参与者本地。某项未来决策仅对那些实际采用该决策的兼容集合生效。无需任何持续性权威进行批准，且不采用并不构成无效状态。
6.2 要求（Requirements）
采用该原则的设计应满足：
- 不得（MUST NOT） 要求参与者在不改变其所在兼容集合的确定性验证规则的前提下，向任何既有机构、注册系统、委员会、董事会或政策机构申请许可。
- 不得（MUST NOT） 建立一个常设机构，使其“认可”成为后续变更得以成为现实的唯一途径。
- 必须（MUST） 区分：初始规范下的“有效性”与后续可选变更下的“兼容性”。
- 不得（MUST NOT） 将不采用后续变更视为无效。
- 必须（MUST） 允许未采用新变更的参与者继续留在原有兼容集合中运行。
- 必须（MUST） 允许参与者通过采用新的验证规则或运行配置，加入新的兼容集合。
- 必须（MUST） 允许参与者在本地拒绝任何不符合其验证规则的状态、记录、状态转换或消息。
- 不得（MUST NOT） 授权任何机构、注册系统或其他主体，仅因参与者拒绝某项变更，就将其判定为“无效”。
- 应当（SHOULD） 明确标识分叉、版本、配置或兼容集合，使参与者清楚自己运行的规则以及可互操作的对象。
- 应当（SHOULD） 避免任何设计，使既有记录维护者能够阻止本来有效的参与者继续互操作。
6.3 设计含义（Design Implications）
“本地化未来决策”并不意味着由中央权威将决策权“分配”给地方参与者，而是指：系统从设计上确保在初始规范之后，大多数未来选择无需任何集中分配机制。
初始规范在一开始就完成了边界限定——
它定义了确保唯一性、互操作性、共享安全与安全所需的最小不变量，其余内容均不进入共同层。
因此：
– 未来变更不通过中央批准产生效力
– 而是由参与者在运行中选择采用、忽略、分叉或放弃
一个拒绝变更的参与者：
– 可以不加入新形成的兼容集合
– 可以与部分参与者断开
– 可以继续运行旧版本兼容集合
– 可以分叉
– 可以选择性互操作
但它无法破坏那些仍在运行相互兼容规则的参与者之间的互操作性。
对于无效或不兼容状态，其结果是本地拒绝，而非惩罚机制。
无需任何人裁定某参与者“状态不良”，因为运行兼容验证规则的参与者会自然拒绝该无效状态。
7. 原则三：自愿采用（Voluntary Adoption）
7.1 原则说明（Statement）
互联网协调系统中的变更应通过参与者的实现、验证、部署与实际采用而成为操作上的现实，而不是仅通过发布或声明生效。
7.2 要求（Requirements）
采用该原则的设计应满足：
- 不得（MUST NOT） 将发布、注册、建议、会议批准或程序性批准视为足以产生普遍操作性义务。
- 必须（MUST） 允许参与者按自身选择，对新规则、扩展、配置或流程进行渐进式部署。
- 必须（MUST） 允许参与者拒绝后续变更且不被视为无效，只要其状态转换仍符合其所在兼容集合的确定性验证规则。
- 必须（MUST） 在初始规范允许的前提下，允许参与者继续使用旧的兼容集合。
- 必须（MUST） 允许运行不同兼容集合的参与者，在规则不兼容时对彼此状态进行本地拒绝或忽略。
- 应当（SHOULD） 为重大变更定义采用路径，包括版本信号、兼容性标识、迁移指南及测试向量。
- 应当（SHOULD） 为重大变更定义拒绝路径，包括未采用参与者如何继续运行、如何标识自身兼容集合以及如何避免模糊互操作。
- 必须（MUST） 确保所需的协调产物可以被退出、迁移、镜像、重新实现或替代，而不会产生不可承受的转换成本。
- 应当（SHOULD） 使注册系统、记录、建议与协调产物描述已被采用的现实，而非宣告尚未被采用的未来现实。
- 必须（MUST） 避免设计成：某项变更只有在既有机构事先认可的情况下才能成为现实。
7.3 设计含义（Design Implications）
“自愿采用”是检验一个变更是否真正有用、可接受且可部署的现实标准。
需要明确：
– 提案不是现实
– 建议不是现实
– 注册更新不是现实
– 文档不是现实
现实只在参与者实现、验证、部署并依赖该变更时出现。
不采用不会产生任何“违规状态”，它只是一个事实： 该参与者没有加入由该变更形成的兼容集合
这并不意味着要取消标准流程、注册系统、文档或评审机制，而是限制它们的权力边界：
– 它们可以帮助协调
– 可以发布参考资料
– 可以描述采用情况
– 可以提出建议
但它们不能仅凭声明，就让未被采用的未来现实对未运行该变更的参与者产生约束力。
8. 三项原则之间的关系（Relationship Among the Three Principles）
这三项原则是相互强化的，不能单独发挥作用。
最小初始规范（Minimum Initial Specification）确保共同层包含的是确定性的验证规则，而不是自由裁量的权力。
本地化未来决策（Localized Future Decision）确保未来选择保留在运行代码的参与者手中，而不会被集中审批层重新接管。
自愿采用（Voluntary Adoption）确保后续变更必须经受实现与使用的检验。
一个只采用其中一项或两项原则的系统，仍可能通过其他方式重新产生中心化。
– 仅有最小初始规范但缺乏本地化未来决策，仍可能在部署后出现权力累积。
– 仅有本地化未来决策但缺乏最小初始规范，会产生模糊性，因为参与者无法在本地判断有效性。
– 仅有自愿采用但缺乏确定性验证，会导致混乱，因为参与者无法区分兼容变化与无效状态。
– 仅有确定性验证但缺乏退出、可移植性或可替代性时，如果记录体系无法脱离，仍可能产生锁定效应。
综合而言，这些原则共同构成一种系统：共同层精简、有效性可本地验证、未来变更基于自愿，且无需常设机构来决定日常运行。
9. 推荐设计模式（Recommended Design Pattern）
9.1 确定性共同层（Deterministic Common Layer）
共同层应仅限于以下内容：
– 稳定的标识符语义；
– 确定性的有效性验证规则；
– 为保持唯一性所必需的冲突解决规则；
– 线缆层或协议层的互操作要求；
– 共享的安全不变量；
– 必要时的控制权证明机制；
– 在需要记录时具备可移植性与可审计性的记录格式；
– 扩展信号机制与兼容集合识别。
共同层不应包含：
– 商业模式规则；
– 定价规则；
– 区域性政治偏好；
– 与技术不变量无关的资格或意识形态标准；
– 任意裁量的执行权；
– 主观价值评判；
– 机构使命扩张；
– 任何主要用于维持既有机构权威的规则。
9.2 运营者决策空间（Operator Decision Surface）
除非直接影响已声明的全局不变量，否则以下内容应保持在共同层之外：
– 部署时间；
– 商业用途；
– 客户地域；
– 租赁、融资或转让安排；
– 本地资格偏好；
– 运营顺序；
– 非共享有效性所必需的路由策略；
– 商业模式；
– 组织结构；
– 自愿迁移时间；
– 可选配置或扩展。
参与者可以在这些方面做出不同选择。这些差异可能形成不同的兼容集合、商业关系、对等互联（peering）安排或运营生态，但只要不违反兼容集合中的确定性验证规则，就不会构成无效性。
9.3 采用循环（Adoption Loop）
在可行情况下，重大系统变更应遵循以下顺序：
- 提案（proposal）；
- 实现（implementation）；
- 测试向量或确定性验证方法；
- 由自愿参与者进行有限部署；
- 观察互操作性与安全影响；
- 标记兼容集合；
- 编写描述已采用现实的文档或建议。
协调产物应当跟随采用之后出现，而不是试图提前定义现实。
9.4 退出、分叉与可移植性（Exit, Fork, and Portability）
符合该设计模式的系统，应将退出、分叉与可移植性视为正常设计要求，而非失败情况。
系统应明确说明参与者如何：
– 继续运行在旧的兼容集合中；
– 采用新的兼容集合；
– 分叉进入新的兼容集合；
– 迁移记录、标识符、证明或运行状态；
– 在不依赖既有记录维护者的情况下验证记录有效性；
– 在兼容允许的范围内实现选择性互操作。
如果一个系统无法在不破坏有效运行的前提下实现退出或分叉，那么它很可能已经在其记录机制中隐藏了治理权力。
10. 适用性与限制（Applicability and Limits）
该设计模式特别适用于以下场景：
– 系统具有多参与方且跨司法辖区；
– 独立部署具有重要性；
– 协调层需要保持精简（薄层）；
– 未来变化可能发生但难以精确预测；
– 锁定效应会带来治理风险；
– 有效性可以实现为确定性或可本地验证。
在以下场景中，其适用性可能较弱：
– 系统设计本身就是单一管理域；
– 强实时耦合要求始终保持统一行为；
– 涉及生命安全，必须实现即时的全局一致性；
– 无法通过任何实际可行机制实现本地验证有效性。
即便在这些情况下，设计者仍应尽可能减少共同层，并避免引入基于裁量的未来控制机制。
11. 非目标（Non-Goals）
本文并不：
– 禁止所有形式的协调；
– 禁止共享注册系统；
– 要求使用区块链或分布式账本技术；
– 保证达成共识；
– 保证政治中立性；
– 要求所有参与者必须采用所有后续变更；
– 将拒绝采用视为无效；
– 在声称兼容的同时为不兼容的本地行为背书；
– 消除对安全关键共同规则的需求。
12. 安全考虑（Security Considerations）
更精简的协调层可以带来：
– 降低被“俘获”（capture）的风险；
– 减少制度性错误的影响范围；
– 提高系统的可替代性。
但与此同时，增强的本地自主性也可能带来：
– 安全策略不一致；
– 降级路径风险；
– 分裂压力；
– 兼容性声明不清；
– 不安全的分叉。
因此，采用本设计模式的系统必须（MUST）明确规定安全不变量。尤其包括：
– 用于共享有效性的认证与授权要求，必须是确定性的且可本地验证；
– 版本协商与扩展处理必须避免在影响安全的情况下发生“静默降级”；
– 拒绝、分叉与替代路径必须评估滥用与拒绝服务（DoS）风险；
– 兼容性标识应足够清晰，以防止在不兼容规则之间发生误互操作；
– 不得允许本地变体在不满足规则的情况下虚假宣称兼容性。
安全例外的存在，并不能成为建立通用许可层的理由。
它只证明：需要引入用于维护既定全局不变量的确定性安全规则。
13. IANA 事项（IANA Considerations）
本文不涉及任何 IANA 操作。
14. 参考文献（References）
14.1 规范性引用（Normative References）
– RFC 2119 — Bradner, S., 《用于在 RFC 中指示要求级别的关键词》，BCP 14，RFC 2119。
– RFC 8174 — Leiba, B., 《RFC 2119 关键词中大小写歧义》，BCP 14，RFC 8174。
14.2 参考性引用（Informative References）
– RFC 6709 — Carpenter, B. 与 B. Aboba，《协议扩展的设计考量》，RFC 6709。
– RFC 7282 — Resnick, P., 《IETF 中的共识与“哼声表决”》，RFC 7282。
附录 A：设计检查清单（Design Checklist）
一个声称符合本文设计原则的系统，应能够清晰回答以下问题：
- 什么是全局不变量（Global Invariants）？
- 哪些确定性验证规则用于维护这些全局不变量？
- 初始规范中哪些规则是首次部署所绝对必要的？
- 哪些未来问题被有意留在共同层之外？
- 哪些未来选择可以由参与者在不改变其兼容集合的情况下自行决定？
- 参与者如何采用后续变更？
- 参与者如何在不被判定为无效的情况下拒绝后续变更？
- 兼容集合如何被标识或发现？
- 当状态在参与者规则下无效或不兼容时，本地拒绝机制如何运作？
- 分叉路径是什么？
- 可移植路径是什么？
- 如何从任何必要的协调产物中退出？
- 参与者是否能够在不依赖既有记录维护者的情况下验证常规有效性？
- 记录与协调产物是在描述已被采用的现实，还是试图宣告尚未被采用的未来现实？
- 系统是否已将嵌入共同层的决策数量降至最低？
- 系统是否避免了由持续性权威来决定参与者日常状态？
作者地址（Author’s Address）
H. Lu
[TBD]
