摘要
- NRS 倡导应将 IETF 的工作视为公共技术组件库：协议格式、安全机制、需求词汇、注册表以及积累的实施经验。采用应是具体、版本化且经过测试的，而不是表达为对“互联网标准”的一般遵从。
- 技术符合性与机构权利必须保持分离。RDAP 可以定义查询响应，RPKI 可以携带签名授权对象，BGP 可以交换路由，但均不能决定谁拥有前缀、转移是否有效或运营商必须使用哪个注册服务。
- 运营商权利应来源于与认可注册机构或授权提供商签订的明确服务合同，并采用 NRS 可以倡导的模型保护：记录访问、控制验证、通知、合理决定、更正、采取不可逆行动前的暂缓、数据可移植性、提供商替代以及有限责任。标准更新不能自动修改该权利表。
- NRS 通过来源支持的倡导和可撤销的成员授权赢得信誉，而非技术权威。独立实现、对抗性测试和经过演练的迁移必须由认可注册机构和授权提供商执行；退出可防止其运营依赖演变为主权。
这种关系应从拒绝效忠开始
提出新号码资源服务的倡导者会倾向于从既有名称中寻求合法性。获得 IETF 认可、在 RFC 中被引用或得到受人尊敬的标准工程师的参与，看起来像是从提议到权威的捷径。NRS 应拒绝这一捷径，并且不应将自己呈现为新的机构。
IETF 可以制定出色的规范。它可以记录协议行为、在协议注册表中分配值、暴露安全假设并收集实施经验。但它不能授予 NRS——或任何倡导者——改变运营商注册、决定转移争议或中断连续性的权利。这些权力必须根据实际 governing 服务关系的文书陈述、接受并接受审查。
这种拒绝并非对标准的敌意。它是良好使用标准的条件。当各方能够采用协议而不接受其作者的政治权威时，协议最有价值。TLS 跨管辖区域保护连接，而不使其工作组成为每笔交易的所有者。RDAP 结构化注册查询，而不决定所记录的底层权利。RPKI 携带认证，而不凭空创造持有人的权利。
NRS 应采用同样的机构谦逊。它可以说明发布的证据显示命名的接口、实现和测试；负责这些实现的运营商必须做出并证实任何运营声明。它不应说：标准使我们的政策合法。技术证据支持服务。运营商授权支持机构。
这种区别对于一个旨在挑战注册机构越权的组织尤为重要。用一种借用的授权替代另一种，只会以更现代的技术标签复制问题。
开放标准是组件，而非指挥链
RFC 3935对 IETF 标准提供了有用的描述。它描述了如何一致地做某事（如果声称遵循规范）；它并不意味着 IETF 强制使用或监管合规性。其价值在于产品间的互操作性。
该描述应定义 NRS 的立场。协会可以倡导那些能降低独立控制系统间协调成本的组件。标准可以规定消息语法、错误行为、加密验证、媒体类型、发现或传输。合规意味着实现按照承诺在该接口上表现。
指挥链应止步于此。符合接口并不确立对消息所代表主题的权力。语法有效的注册响应仍可能包含有争议的持有人。有效的签名证明对密钥的控制，而非签名者获取地址块的法律依据。正确传输的路由证明路径已被宣布，而非宣布网络拥有该前缀。
因此，NRS 研究需要两张地图。技术地图列出规范、版本、配置文件、测试用例和实现状态。权力地图列出合同、运营商授权、法律约束、决策者、审查权和迁移选项。一张地图的失败不得被另一张地图的成功所掩盖。
这种分离赋予标准应有的力量。技术要求可以在兼容性要求精确之处精确。机构规则可以在权利要求理由之处保持可争议。没有参与者必须仅仅为了防止机构越权而削弱协议语言，因为合同规定了协议不能授权的内容。
NRS 应倡导配置文档，而非借用整个 RFC 系列的威望
“符合 RFC”对于严肃的注册服务而言过于模糊。RFC 系列包括标准轨文档、最佳当前实践、实验、信息、历史以及来自多个流派的出版物。文档会更新和废弃彼此。即使两个选项都被允许，它们也可能互不兼容。
NRS 应发布狭窄的提议采用配置文档，供负责机构评估。配置文档标识功能、确切 RFC、纳入的章节、更新、勘误、可选功能、扩展规则、安全参数、测试方法和过渡日期。它还应标识排除项。结果是一个可复现的工程承诺，而非对数字权威的诉求。
对于 RDAP，配置文档可标识实现支持的 HTTP 使用、响应结构、安全服务、引导行为和编辑约定。对于 RPKI 发布，可标识对象类型、存储库行为、清单处理、验证期望和失败状态。对于 DNS 委派，可规定传输和签名程序，而无意图监管区域内容。
配置文档应足够小，使其他提供商也能实现。如果符合性需要未发布的机构知识，则该配置文档已失败，即使一个提供商的服务正常工作。扩展点应被记录，强制性的私有字段应被视为锁定。
协会永远不应自动纳入“所有未来更新”。以后的技术文档可能改变成本、隐私、兼容性或依赖关系。每次实质性更新都需要根据提供商合同做出采用决定。对于紧急安全修复，该决定可以加快，但责任必须保持可见。
第一宪法语句是标准不能分配权利
NRS 应在每个采用配置文档的顶部提出一个非转换条款：技术符合性不决定所有权、资格、转移有效性、合同状态或管辖权，除非有独立标识的权利文书另行说明。
该条款之所以必要，是因为技术记录通过反复使用获得权威。最初作为运营联系人的注册表字段可能成为争议中的证据。签名对象可能被误认为所有权。协议状态码可能被视为裁决。如果这些转变悄然发生，软件将成为法律，而无人承担责任。
该条款并不会削弱技术记录。签名的可审计记录可以是强有力的证据。它可以证明一个被声明的行为者在某个时间使用认可的凭证授权了一项更改。它可以显示两个权威状态会冲突。它可以支持法院、对手方或审查者。
证据与最终权力不同。合同决定记录证明什么以及运营商如何质疑它。法律决定法院将承认哪些主张。网络决定它接受哪些路由。协议决定消息是否有效。保持这些命题分离可防止任何一层吞噬其他层。
这是 NRS 作为倡导者和研究参与者应寻求的与 IETF 的有限关系。IETF 可以定义可互操作的证据容器。认可的提供商和运营商必须通过明确协议定义证据容器内可能产生的机构后果；NRS 可以倡导这种分离。
RDAP 准确展示了界限所在
注册数据访问协议是一个理想的例子，因为其主题是注册信息。RFC 9082定义了查询模式，RFC 9083定义了 JSON 响应，RFC 9084涉及安全服务。这些规范可以使客户端和服务器相互理解。
它们不决定命名实体是否对地址范围拥有有效主张。它们不决定注册机构是否可以根据适用法律在任何管辖区编辑特定事实。它们不决定运营商是否可以将其注册服务迁移到其他提供商。这些是权力和服务问题。
NRS 应倡导暴露准确、可移植且机器可验证状态的 RDAP 配置文档。认可的 RDAP 运营商必须定义并提供配置文档、支持状态、来源、编辑和更正，并测试多个客户端和服务器。
运营商合同随后应提供协议中缺失的权利：访问完整的非公开记录、更正错误的能力、重大状态变更前的通知、拒绝理由、独立机构审查以及适合迁移的导出。成功的 RDAP 响应不能放弃任何这些权利。
这种设计将标准转化为反锁定工具。协议使服务表面可复现。合同防止提供商声称符合协议即为不准确或胁迫性决定开脱。
RPKI 证明授权链，而非机构主权
RPKI 更为敏感，因为其输出影响路由起源验证。RFC 6480描述了一种基础设施，其中证书和签名对象将地址和 AS 号码持有与路由授权相关联。发布和验证规范让独立运营的系统评估加密材料。
加密技术可以回答一个有限的问题：此对象在所选信任安排下是否有效，以及它表达了什么路由起源授权？它不能回答关于资源关系合法性的每一个先前问题。如果注册机构错误地更改了底层认证状态，验证者可能正确处理新对象，而运营商的权利已被侵犯。
NRS 应倡导将 RPKI 标准用作证据机制，而非替代正当程序。其配置文档应支持独立依赖方验证、可预测发布、密钥轮换、清单一致性、撤销可见性和恢复。测试应包括过时存储库、部分发布、密钥泄露和冲突状态。
合同必须控制不利机构行动。除了狭义定义且可证明的安全紧急情况外，可能使活动路由授权失效的有争议变更应收到通知、理由以及在审查前的实际暂缓。迁移所需的凭证和历史应在演练过的流程下可移植。
积极的承诺是强有力的：如果认可的认证机构实施它，NRS 倡导的模型可以使授权证据比自由裁量的注册决定更可验证。但只有当它不能利用对信任安排的控制来惩罚异议或阻止退出时，它才赢得这一地位。
BGP 是运营证据，而非契约
RFC 4271规定了用于在自治系统之间交换可达性信息的边界网关协议。运行中的网络提供了关于哪些前缀被宣布、通过哪个起源以及沿哪些路径的关键证据。
NRS 应在其研究中谨慎使用公共或经同意的证据。观察到的路由可以证实运营控制，识别连续性风险，并测试提议的注册更改是否与当前使用匹配。长期、多样化的观测可以揭示纸面记录遗漏的网络关系。
路由不解决所有权。客户可以授权提供商起源前缀。劫持者可以无权利宣布空间。有效的持有人可以留空一个块。任播可以产生多个合法起源。法院命令或转移可以在路由改变之前改变权利。将 BGP 可见性视为所有权会将运营协议转变为财产法庭。
因此 NRS 提议的证据规则应说明每个观测支持什么。路由收集器可以显示从其角度在某个时间可见的路径。运营商认证可以解释该宣布的商业或技术授权。RPKI 可以添加签名起源授权。合同和法律证据建立主张的其他部分。
标准的好处是可组合性：多个独立可检查的信号可以支持决策。危险是类别崩塌：一个技术上有效的信号被宣布为凌驾于所有其他信号之上的主权。NRS 应倡导前者，并警告后者。
规范大写字母必须止步于接口
RFC 2119和RFC 8174在文档引用 BCP 14 时为全大写要求词提供了定义含义。MUST 标识规范的绝对要求；SHOULD 允许在理解后果后进行合理的偏离。
NRS 提议的配置文档应精确使用此词汇。MUST 可以定义互操作性所需的字节、状态转换或安全行为。测试可以显示实现是否符合。SHOULD 可以要求实现者记录有效的异常。
大写字母不得创建机构管辖权。“客户端必须拒绝无效签名”是技术要求。“运营商必须放弃有争议的注册”是一项权利要求，需要合同授权、证据和审查。排版无法弥合差距。
NRS 倡导的模型提供商合同应明确说明技术要求如何进入服务关系。它应命名配置文档版本，并解释符合性是义务、服务级别承诺还是等效条件下的可接受实现。技术 SHOULD 不应被无声地转换为机构 MUST。安全 MUST 也不应被破坏互操作性的自由裁量政策例外所削弱。
这种翻译记录既保护工程师也保护运营商。工程师可以编写无歧义的规范，而不必担心每个大写字母都会转移主权。运营商可以识别义务的实际来源，并在不争议有效协议行为的情况下质疑机构决定。
独立实现是入场券
NRS 不应因为首选的供应商已经实现就宣布核心接口稳定。对于任何其故障可能影响权威状态、可移植性或路由安全连续性的功能，至少应有两个独立控制的实现交换数据并产生预期结果。
独立性关乎控制，而非品牌标签。共享相同隐藏库的两个产品可能重复相同的错误。由附属于一个变更权力的分支机构运营的两个服务可能无法测试机构交接。证据应识别代码谱系、运营商、测试所有权和任何共同依赖。
互操作性测试应涵盖成功之外的更多内容。应测试畸形输入、重放、重复事件、时钟偏差、过期状态、部分迁移、密钥轮换、不可用依赖、回滚和恢复。只接受快乐路径但无法在故障下保持连续性的实现不是替代提供商。
测试工件应在安全和隐私允许的情况下公开。第三方应能理解配置文档，复现非敏感案例，并区分自我证明与独立评估。生产数据无需暴露即可使符合性可信。
目标不是认证表演。而是提供商可替换性。如果第二个实现无法消费权威导出、验证其历史并提供兼容结果，那么无论源代码看起来多么开放，负责提供商都创造了另一个机构瓶颈。
运行中的证据必须包括运营商，而不仅仅是软件
软件互操作性证明规范可以协调机器。号码注册服务还需要证据证明它可以在压力下协调机构。NRS 应将运营商证据视为评估第二个问题的决定性因素。
试点应衡量控制验证需要多长时间，较小网络可以合理提供哪些证据，更正如何处理，持有人是否理解决定，以及现有自动化是否在提供商变更期间继续工作。应记录错误拒绝、错误接受、停机时间、员工负担和未解决的模糊性。
不同运营商类别很重要。跨国骨干网、本地接入提供商、大学、云平台和小型托管企业可能持有类似记录，但面临非常不同的员工、客户和法律约束。一个只适用于资源充足参与者的标准配置文档在技术上可互操作，但在机构上具有排他性。
负面证据应有定义好的途径回到配置文档。如果运营商无法在不停机的情况下实施凭证轮换，则应更改设计。如果强制字段暴露敏感商业结构而不改善验证，则应缩小范围。如果可移植性失败是因为接收提供商无法解释扩展，则该扩展不应是强制性的。
NRS 应发布基于来源的结果分析，并带有诚实的分母；实施机构必须发布运营措施。十次成功迁移只有在读者知道尝试了多少次、哪些失败以及为何失败时才有意义。只有当机构不能选择讨它欢喜的证据时，运营证据才能成为权威来源。
权利表必须是人类可读且独立的
技术配置文档将很复杂。运营商权利不应隐藏在协议引用中。NRS 应倡导一个简短、稳定的权利表，网络高管、工程师和律师都能理解。
该表应包括访问与运营商相关的完整记录；证明和更新控制权的记录方法；后果性行动前的通知；与命名规则相关联的理由；更正流程；独立审查；除已验证紧急情况外的不可逆变更暂缓；争议期间的连续性；以开放格式导出；迁移到合格提供商；凭证的返回或过渡；以及当负责提供商违反这些义务时的补救措施。
该表应说明它不保证什么。它不能保证每条路由都会被接受，不能保证每个管辖区都将地址利益视为财产，也不能保证合法制裁和法院命令永远不会适用。负责提供商可以承诺识别权威、保存证据、限制行动并提供合同流程；NRS 可以要求并审查这些承诺。
这种分离防止技术漂移改变权利。新的 RDAP 字段不会减少通知。修改后的 RPKI 对象不会取消暂缓。新的安全传输不会使迁移变为可自由裁量。权利只能通过合同中规定的修订规则改变。
这种设计是积极的，因为它使同意可操作化。NRS 不应要求运营商信任一种克制的文化。它可以在持久权利下倡导技术精确的服务，同时认可的提供商提供并运营它。
标准更新需要采用防火墙
开放标准在不断演进。安全问题被发现，加密算法老化，格式获得扩展，运营经验暴露模糊性。NRS 倡导的模型必须从维护中受益，同时不允许外部出版物自动修改运营商义务。
采用防火墙提供了该边界。技术委员会识别提议的更新，映射变更行为，测试兼容性并发布影响声明。权利审查询问更新是否改变证据负担、披露、成本、依赖或退出。运营商收到通知。授权提供商机构随后根据其合同采用、延迟、缩小或拒绝更新。
微小更正可以在不改变可观察行为或权利时走快速通道。安全紧急情况可以证明临时控制是合理的，但范围、证据、持续时间和回滚必须被记录。临时更新应在经过普通审查后确认，否则到期。
固定版本提供了确定性，但无限期固定可能造成漏洞。动态引用保持软件最新，但无限纳入将未来决策委托出去。防火墙将版本控制与有意的维护结合起来。
最重要的是，拒绝仍有可能。如果更新对于运营商使用的接口是不必要的，配置文档可以保持兼容性或提供过渡。在确切行为至关重要的情况下，合同可以解释拒绝它的技术后果。NRS 永远不应倡导将“IETF 发布了更新”转变为“运营商放弃了一项权利”。
等价性在网络需要相同之处应精确，在不需要之处应开放
开放标准政策经常赞美等价解决方案，而不识别等价在何处可能。NRS 倡导应更精确。在共享协议边界上，两个实现可能需要相同的可观察行为。客户端不能仅仅因为其内部安全设计创新就将无效签名视为有效。接收提供商不能忽略所需的状态转换并仍声称安全迁移。
远离接口，统一性可能不必要。如果提供商产生所需证据并尊重相同的运营商权利，他们可以使用不同的存储模型、编程语言、人员结构和欺诈控制。一个提供商可以通过专门团队验证控制声明，而另一个使用自动检查与人工升级。NRS 应要求独立运营商和评估者测试结果和错误路径，而不是规定其偏好的内部组织。
配置文档应相应地标记每个要求：确切接口行为、结果要求、可接受替代或本地选择。这种分类防止两种相反的滥用。提供商不能以创新为名打破共享状态，也没有倡导者或提供商能以互操作性为名标准化每个运营细节。
运营商需要一条途径来提议等效控制。提供商应识别目标，根据公开标准测试替代方案并提供理由。拒绝应是可审查的。如果重复的替代方案成功，基础配置文档可能过于规定性，应进行修订。
这是反对主权的另一个边界。标准在自治系统必须满足之处赢得严格合规。它们不赋予作者设计接口背后每个机构的权力。
安全紧迫性不得成为标准体紧急规则
互联网标准经常应对紧急威胁。漏洞可能需要快速弃用、密钥更换或协议变更。认可的技术运营商需要在长期机构辩论暴露运营商于可避免危害之前采取行动的能力；NRS 可以要求围绕该能力的保障措施。
紧迫性并不消除技术权威与机构权威之间的区别。技术证据应识别漏洞、受影响的函数、可利用性和安全替换。授权提供商随后根据其合同和采纳的权威决定需要哪些服务行动。IETF 文档可以是有力的证据，而不成为行政命令。
紧急措施应优先选择可逆的技术遏制。授权的技术运营商可以为新交易禁用有漏洞的算法，要求双重验证，增加监控或缩短凭证生命周期，同时保留运营商的底层记录。对注册状态的破坏性更改需要更高的门槛。
紧急通知应命名规范、受影响的版本、测试证据、行动、预期持续时间和审查路径。机密利用细节可以临时保护，但行动的法律和合同基础不能保密。在即时风险被控制后，独立审查者应能检查证据。
日落是必要的。在压缩条件下采用的安全响应不应仅仅因为恢复需要努力就成为数据收集或机构控制的永久扩张。当负责提供商对维护如何到达运营商负责时，标准维护保护系统。
协议注册表不应与号码权利混淆
IETF 经常为协议参数创建注册表。RFC 8126描述了诸如专家审查、规范要求和标准行动等策略，用于在这些注册表中分配值。IANA 功能可以管理生成的表格。
这些协议注册表解决了规范内部的命名空间问题。一个代码点不能表示两个不兼容的事物。审查者可以判断分配是否符合技术标准。这与决定谁对 IPv4 块或 ASN 拥有持久利益不同。
NRS 倡导的模型可能需要受控词汇表：事件类型、状态值、证据类别、配置文档版本和扩展标识符。它可以使用 RFC 8126 作为透明分配、冲突避免、审查者条款和申诉的设计指南。它不应推断相同的专家审查模型可以决定运营商权利。
指定专家可能有权决定扩展是否可互操作。专家不应决定运营商是否失去注册认可。第一个是狭窄的技术分配；第二个是不利的机构行为。
边界也保护 IANA。协议参数功能可以保持中立的技术服务，而不被要求验证编码在消息中的每个商业或法律主张。NRS 应倡导使用共享注册表以保持实现兼容，同时将权利裁决保持在理由、证据和补救可用的地方。
专利和许可风险属于可移植性分析
开放发布过程不保证所有实现都没有知识产权风险。IETF 程序要求在定义条件下披露已知权利，但披露不是完整的专利搜索或通用许可。
NRS 应倡导可以由多个提供商根据明确和非歧视性条款实现的配置文档。由一个供应商控制或受到不确定许可限制的强制组件可以将开放标准转变为经济锁定。
采用审查应询问谁拥有基本代码、专利、测试工具、模式和商标；继任者能否获得相同权利；开源实现和专有实现是否都可行；以及如果许可证被撤销会发生什么。答案应是退出影响声明的一部分。
这不是要求 NRS 倡导模型中的每个组件都是自由软件。独立实现可以使用不同的许可模型。宪法要求是可替代性。运营商不应在争议期间发现唯一符合的替代依赖现任提供商的许可。
在风险不确定的情况下，NRS 可以建议将组件隔离在接口后面，保留替代实现路径，避免使用专有格式的不可替代历史状态。标准采用应降低转换成本。如果它提高转换成本，则理由负担随之增加。
扩展必须承担自己的退出成本
每个成功的技术平台都会积累扩展。有些解决局部需求；其他则提供商的内部模型走私到所谓的共同标准中。NRS 应倡导实验，同时不允许扩展成为私人收费站。
基础配置文档应只包含每个合格提供商维护权威状态和连续性所需的内容。可选扩展必须命名空间、文档化，并在安全允许的情况下可忽略。如果某个扩展后来变成强制性的，它应通过独立实现、迁移和权利审查。
影响不利行动、持有人状态或凭证控制的扩展不能被当作元数据。它改变了权力面，并属于合同审查。仅仅改进分析的扩展不应成为注册认可的条件。
导出必须保留未知扩展，而不强制接收提供商执行它们。历史证据可以作为签名材料传输，而继任者只映射理解的语义。在无法安全保留扩展的情况下，运营商应在采用前知晓。
这种纪律使创新保持在边缘，共同层保持薄。它也使得授权提供商提供的产品可竞争。有用的高级服务可以基于价值竞争，但运营商的核心记录必须通过基础配置文档保持可移植。
符合性永远不应成为意识形态认证
NRS 倡导的模型需要独立符合性测试，而非忠诚度徽章。提供商应因其实现配置文档、保护密钥、维护唯一性、导出状态、通过恢复测试并接受权利表而合格。它不必支持 NRS 的每个倡导声明。
测试范围应公布。结果应标识测试的版本、日期、环境、评估者和局限性。失败应导致定义的修复路径。暂停应与失败的功能成比例；可选分析服务的缺陷不应使权威注册失效。
认证机构本身可能成为守门人。NRS 应倡导多个合格评估者；主管当局必须使用相同套件允许并监督他们，轮换审查者，披露冲突并允许申诉。自我测试可以支持开发，但高后果合格性需要独立证据。
运营商应能看到提供商是否通过了迁移测试，而不仅仅是普通服务。能够接受新记录但不能交出既有记录的提供商不符合可移植注册模型。
意识形态中立并不意味着对行为漠不关心。欺诈、伪造权威、含糊其辞以及拒绝归还可移植状态直接威胁共同服务。它们可以根据命名的规则进行测试和制裁。与这些功能无关的政治分歧不能被转化为技术失败。
退出必须在服务层执行，而非通过分叉唯一性
实际的退出权并不意味着两个权威提供商对同一资源做出冲突更改。那将用重复真实替代机构锁定。认可的注册生态系统需要 NRS 倡导的那种迁移协议，以保留一个有效状态。
序列应包括运营商请求、控制验证、通知当前提供商、识别未决争议、最终状态承诺、接收提供商确认、凭证过渡、发现更新、用于读取连续性的有限重叠以及最终切换。每一步都应产生提供商和运营商都能保留的证据。
当前提供商不应拥有自由裁量的否决权。它可以提出确定的欺诈担忧、法院命令、制裁限制或未解决的主张。中立审查者决定该问题是否阻碍、缩小或允许移动。争议应随记录一起转移，以便可移植性不会成为逃避。
开放标准使这一序列可复现。合同使性能对接纳它的提供商具有强制性。独立测试证明替代品可以执行它。这些要素单独都不足够。
退出权适用于每个服务提供商。NRS 不运营注册服务，结束 NRS 成员资格或代表不得影响有效记录或凭证。一个宣扬可移植性同时使其自身地位不可或缺的协会已将改革转变为继承。
合同不是开放互联网的敌人
互联网文化有时将合同视为反对开放技术协调的私人约束。在注册治理中，明确的合同可以是对机构权力的约束。它标识当事人、服务、权利、义务、责任、修订规则、条款、退出和补救。
替代方案通常不是自由。而是未定义社区制定的政策因账户持有人使用注册而约束他们的开放主张。该主张比精确条款更难检查和挑战。
NRS 倡导的模型提供商合同应按版本纳入技术配置文档，同时保持权利表稳定。它应指定哪些更改需要运营商同意，哪些可以在通知后执行，哪些解决紧急安全问题。目的、证据收集或不利行动权力的实质性扩展不应通过常规技术更新实现。
合同还应保留适用法律。NRS 和负责提供商不能承诺免于法院、监管机构或制裁义务。它可以承诺识别权威，避免超出要求的行动，在法律允许的情况下通知运营商，并尽可能保留审查和迁移。
最重要的是，合同必须与退出配对。垄断方以接受或重新编号条款提供的合同可以使依赖形式化而非同意。开放接口和提供商可移植性是将明确条款转变为有意义选择的条件。
NRS 应要求可替换服务并保持自身授权可撤销
机构可信度通常需要多年运营才能获得，这给新服务带来了悖论。运营商不会依赖未经验证的连续性，但没有用户就无法测试连续性。NRS 可以敦促认可的提供商通过首先证明可替换性来打破循环。
它可以在控制结果状态之前发布基础配置文档、权利表、测试套件和迁移程序。两个独立的演示提供商可以交换合成记录、轮换密钥、更正错误并完成敌对退出场景。审计员可以从保留证据重建决策。运营商可以在任何切换之前通过非权威镜像或收据参与。
演示应包括实施提供商的失败。NRS 失败应仅影响其倡导和成员记录，永远不权威注册状态。其他提供商能否恢复所需状态？运营商能否验证其记录已被包括？依赖服务能否发现继任者？未决争议是否保持可见？受损密钥能否在不悄悄更改历史的情况下更换？
这些演练证明的不仅仅是软件。它们证明机构没有将自己设计入标准。成功的继承测试证据表明提供商的权威仍然是服务性的。
当实时采用开始时，权威应按功能扩展。只读验证可以先于写权限。自愿可移植性试点可以先于通用服务。限制、回滚和独立观察应保持明确。NRS 永远不应为自己要求认可，也不应在承诺证据的同时先倡导提供商认可。
IETF 关系应是公开的、技术的和非排他性的
NRS 应作为倡导者、研究人员或授权成员的代表参与相关 IETF 工作，而非作为实施者、运营商或特权地位主张者。它可以提交互操作性发现、报告模糊性、提议扩展并提供安全分析。其证据应在质量上与任何其他参与者的证据竞争。
关系应在两个方向上都非排他性。NRS 可以倡导来自其他开放机构的合适标准，或在没有标准适合时发布提议的公共配置文档。IETF 可以与现任注册机构、供应商和其他运营商合作，而不给予任何一方机构优先权。
联络（如果使用）应有狭窄的条款、公开输出，且无权谈判运营商权利。IETF 领导者的参与不应被宣传为认可。RFC 中对 NRS 讨论的实施引用应被视为技术文档，而非主权认可。
这种姿态有益于 IETF。标准讨论保持聚焦于接口和运营证据，而不是成为关于号码资源控制的代理战争。它有益于 NRS，因为协会不能依赖赞助。它有益于运营商，因为他们可以使用技术结果而不接受隐藏的政治安排。
正确的语句很简单：标识的授权提供商实现了此规范并已演示互操作；NRS 记录了证据。任何更强的说法都需要不同的权威来源。
有限的 NRS-IETF 倡导关系
这种关系可以用十项承诺表达。
NRS 将标识并倡导确切的技术规范，而不是一般性地引用 RFC 系列。它将区分协议符合性与资源权利。它将要求核心可移植功能的独立实现，并发布责任运营商归因的测试范围、失败和版本过渡。它将把运营商体验视为能够更改配置文档的证据。
它不会允许标准更新自动修改权利。它将在单独合同中放置通知、审查、暂缓、更正和退出。它将保持扩展可移植并避免单一供应商依赖。它将贡献技术发现而不声称 IETF 认可。它将排练继承，以便其自身失败不会困住运营商。
IETF 无需承诺任何特殊回报。其现有的公开流程和规范可供实施者使用。NRS 应接受与其他人相同的审查，并通过证据、倡导和成员代表展示价值。
盟约刻意不对称。标准体不必祝福每个采纳者。采纳者对其附加于标准的机构后果承担责任。NRS 的可信度在它使该责任明确而不是借用全球名称时增长。
成功应是什么样子：通过证据而非宣告衡量
第一个衡量标准是互操作性。独立客户端和提供商在相同配置文档下交换完整记录，保留语义并一致处理失败。第二个是可移植性。运营者在公布时间内更换合格提供商，同时全局唯一性、历史和活动安全状态保持不变。
第三是权利执行。通知在后果性行动前到达，理由标识证据和权威，审查者可以中止错误，更正附加可见账户，有效争议不会导致路由中断。第四是机构克制。NRS 拒绝那些对管理有用但狭窄服务不需要的提议。
第五是市场可替代性。多个提供商可以在无需 NRS 首选供应商许可的情况下实现基础配置文档。转换成本随时间下降。扩展不会仅靠安装基数压力变为强制性。
第六是标准参与而不被俘获。NRS 贡献基于来源的报告并接受技术批评。它既不将 RFC 视为批准，也不试图将其合同偏好转变为会约束非参与者的协议要求。
这些措施可能明显失败。那是优点。一个只将成功定义为认可、成员或出版的机构可以在不保护运营商的情况下宣布胜利。一个通过互操作、连续性和退出判断的机构必须不断证明其目的。
开放协议应使权力更容易离开
NRS 最强有力的理由不是它能比任何现任者编写或运营更好的规则。而是它能改变规则与依赖之间的关系。开放技术标准可以使记录在提供商之间可理解。独立实现可以使声明可复现。运行中的证据可以暴露使运营商失败的配置文档。合同可以陈述权利和补救措施。退出可以使所有这些承诺保持非仪式化。
IETF 在这个模型中是技术工作的来源，而非宪法上级。其最佳标准告诉独立系统如何互操作。其自身使命声明否认出版强制使用。当标准触及号码治理时，这种谦逊应被保留。
NRS 应同样谦逊。它应倡导准确状态、可验证权威、必要的技术服务以及连续性，同时将运营留给认可注册机构和授权提供商。它不应从密码学、RFC 引用或受尊敬工程师的参与中推断政治主权。其权利规则应足够明确以执行，足够狭窄以离开。
结果不是没有权威的标准。而是权威分配给正确的工具。协议作者定义符合性。运营商和提供商签订服务合同。法院和公共法处理法律义务。网络做出路由决策。NRO 和认可注册机构协调这些参与者所需的最低状态；NRS 可以倡导克制，而不声称成为它们全部。
开放标准在它们使实施机构可替换时达到最高机构价值。如果授权提供商能证明这一主张，且 NRS 能准确记录它，那么倡导将已恢复使互操作技术成为抵御主权的最初克制的力量。
证据和分析限制
NRS 章程支持协会声明的方向：准确注册、有限簿记角色、自愿认可、企业自由、透明度和问责制。NRS 的公共使命支持其以运营商为中心的对注册控制和减少机构集中的强调。这些是用于定义建设性方向的第一方立场；它们不证明部署的可移植性、IANA 认可、独立实现或普遍运营商支持。
卢恒关于运行中代码优先的分析提供了规范框架，即最低共同规则、本地验证、自愿采用和运营商选择应优先于机构流程。其主张是声明的治理立场。本文中的具体 NRS 盟约、采用防火墙和测试序列是设计提案。
RFC 3935支持对互操作性、协议所有权和 IETF 拒绝强制或监管采用的描述。RFC 2026和RFC 6410支持独立实现、部署和运营经验的作用。这些是 IETF 关于其标准体系的声明，用作技术和机构证据，而非 NRS 权威的授权。
RFC 9082、RFC 9083、RFC 9084、RFC 6480、RFC 4271、RFC 8126、RFC 2119和RFC 8174支持有限的技术示例。它们不决定所有权、合同权利、法律所有权或 NRS 作为权威注册提供商的认可。
RFC 7020支持 IETF 对互联网号码非政策技术方面的责任与注册机构政策制定之间的区别。它描述了现有的机构安排；它不被视为该安排是永久、代表性或足够的证明。