摘要

  • Alvaro Retana 共同撰写了 RFC 3021 和 RFC 3137，这两份记录将狭窄的运营商约束转化为有边界的协议行为：在点对点链路上使用 IPv4 /31 中的两个地址，以及通告较高的 OSPF 链路度量，使路由器在保持可达的同时不充当优先的转接路径。
  • Retana 还共同编辑了 RFC 4276，这是一份基于四份完成的厂商回复汇编而成的 259 题 BGP-4 实现报告；该文件让实现证据可见，同时明确警告编辑者没有独立核实受访者的回答。

三项标准记录，一个运营问题

互联网标准常被描述为文档，但运营商体验的是嵌入运行系统中的选择。地址必须在无冲突的情况下分配。路由器必须在维护时不会造成本可避免的路径故障。独立实现必须足够一致地交换路由，共享网络才能运转。文本重要，是因为它塑造这些结果，而不是因为发布本身就能让网络运转。

Alvaro Retana 的公开记录提供了一种有边界的方式来检视这一区别。目前的 IETF 档案显示其参与可追溯至 1998 年，发布了 17 篇 RFC，曾担任路由领域总监，并继续承担路由相关职责。该档案提供了角色背景。更强的人员层面证据来自署有其名字并针对具体运营约束的三份技术记录。

RFC 3021 于 2000 年 12 月发布，讨论在 IPv4 点对点链路上使用 31 位前缀。Retana 及其共同作者提议将此类前缀中的两个值视为主机地址，而不是将其中一个保留为网络地址、另一个保留为定向广播地址。这一决定将四地址子网的惯例转变为一种两地址的链路安排，在这种拓扑中，网络和广播语义已无必要。

RFC 3137 于 2001 年 6 月发布，描述 OSPF stub 路由器通告。Retana 及其共同作者记录了一种向后兼容的技术，用于在保持路由器可达的同时，阻止其他路由器将其用于转接。运营需求包括维护、关键状况以及平缓的引入或退出。该记录后来在 RFC 6987 取代它之后成为历史文档，因此 2001 年的机制必须作为不断演进的规范历史的一部分来描述。

RFC 4276 于 2006 年 1 月发布，记录了一次 BGP-4 实现调查。Retana 和另一位编辑汇总了 259 个问题以及来自四个已完成实现的回答。报告并不证明这些产品。它创建了一份带日期的比较，保留受访者提供的声明，识别差异，并说明编辑者没有独立核实这些回答。

综合来看，这些文件展示了一个一致的现实层。重要的单位不是头衔、委员会职位或履历，而是被记录的约束、协议决定，以及可观察的实现或运营影响。Retana 作为共同作者或共同编辑与这些记录相关联。单独的标准、部署、厂商代码或后续演进并非仅归功于他一人。

没有履历的人层面证据

有用的人物文章需要的不仅是一个人出席某活动或担任某角色的证明，它需要一份决策记录，把此人与一项技术约束和有边界的结果相连接。Retana 的三份文件以不同方式满足了这一考验。

/31 文件将他与一项号码资源决策联系起来。在点对点链路上，IPv4 地址稀缺并非抽象政策问题。传统子网语义可能消耗四个地址来连接两个接口。在大规模场景下，这种重复模式会产生可衡量的分配成本。该 RFC 定义了在何种拓扑下两个值都可以标识端点，并解释运营后果。

OSPF 文件将他与一项连续性决策联系起来。路由器可以在不适合转接的同时，仍为管理或目的地流量保持可达。没有共同的通告技术，运营商可能依赖破坏性的关闭、临时修改度量，或实现特定的行为。该 RFC 描述了一种方法，使现有路由器可以利用常规最短路径计算加以解读。

BGP 报告将他与一项证据决策联系起来。协议符合性不能仅凭标准存在或厂商声明来推断。结构化问卷可以揭示实现在哪些方面一致、不同、遗漏行为，或对可选特性的解读不同。该报告创建了这种比较，同时保留清晰的核实边界。

这些并不是可以互换的成就。前两份是描述行为的协议规范；第三份是描述实现者所提供回答的实现报告。它们具有不同的证据效力。把三者都当作泛泛的“领导力”，会抹去让记录有用的区别。

因此，本文仅围绕这三份文件展开。它不试图呈现完整职业史。它不推断当前雇主成果、市场份额、商业影响力、专利、私有运营事件或后续部署的责任。IETF 和专业档案确立了标准工作的连续性，但它们不能替代技术证据。

点对点链路中隐藏的地址成本

IPv4 子网惯例通常将全零主机值保留给网络，将全一主机值保留给定向广播。在传统的 /30 中，有四个地址：两个保留值和两个主机值。这种安排适用于多接入网络，网络和广播含义在其中可能有用。

点对点链路具有不同的形态。它恰好连接两个接口。没有第三个主机等待接收面向子网的定向广播，链路端点已经定义了唯一有用的目的地。将四地址惯例套用到每条此类链路上，会使一半地址值无法用于接口。

单独查看一条链路时，这种损失可能很小；但在拥有许多点对点电路的路由网络中，它会变得显著。每个 /30 消耗四个地址来给两个端点编号。用 /31 替代这一模式，则用两个地址服务同样的两个端点，每条链路节省两个地址。

RFC 3021 将此视为现有 IPv4 架构内的节约，而非较长期协议演进的替代方案。该决定并不创造新地址，而是改变一种狭义拓扑如何解读 31 位前缀中已有的两个值。

这一边界很重要。地址效率必须保持唯一性和转发正确性。两个接口不能意外获得相同的运营身份，路由器也不能将普通流量重新解释为该链路并不需要的广播。只有当两个端点和周围实现就语义达成一致时，该提议才有用。

Retana 的共同作者身份之所以相关，是因为该 RFC 明确了这一约束，并将其转化为标准轨行为。其结果不是关于稀缺性的一句口号，而是一条可在真实链路上实现、配置、测试和观察的规则。

RFC 3021 的有边界决定

RFC 3021 的核心决定是：当子网用于点对点链路时，将 /31 前缀中的两个地址值都视为主机地址。该文件将这两个值称为链路的端点，而不是网络地址和定向广播地址。

之所以可行，是因为拓扑提供了较大子网无法假设的信息。在恰好两个端点的情况下，跨链路发送的流量只有一个其他接口可到达。不存在多个主机供面向子网的定向广播寻址。传统保留会消耗这些值，却不能提供相应的运营功能。

该 RFC 并未宣称每个 /31 在任何上下文中都安全。它将行为与点对点链路绑定，并讨论了实现注意事项。设备和管理系统必须支持这种解读。地址分配、路由、诊断、访问控制和监控必须与双主机安排保持一致。

因此，这一决定既是一种效率机制，也是一份兼容性契约。运营商只能在拓扑和软件满足契约时节省地址空间。如果某个端点、工具或周边系统仍假定传统的网络和广播语义，表面上的节省可能变成一次中断或可观测性问题。

该文件还保留了分配与运营之间的区别。注册机构或地址计划可以记录包含前缀，但链路配置决定哪些具体值标识两个接口。准确的库存仍然重要。节约并不等于可以放弃记录；恰恰相反，它使精确记录更加重要，因为更密集的计划留给含糊的空间更少。

Retana 与其他列出的作者及 IETF 流程共享荣誉。已发布的 RFC 记录了一项集体标准决定。它并不显示哪一句话是谁写的、哪个厂商最先实现该行为，或哪个运营商在最大规模上部署了它。

运营经验比纯算术更强

/31 寻址的算术理由很简单。两个可用端点消耗两个值而非四个。仅靠算术并不能证明运营安全。更强的问题是：当惯例改变时，转发、控制协议、管理工具和故障处理是否都能正确运行。

RFC 3021 包含运营考量，而不是将该提议呈现为一份地址表练习。这种强调很重要，因为点对点链路位于包含路由邻接、接口管理、访问策略、诊断和自动化的系统中。被一台设备接受的配置仍可能令另一工具意外。

运行代码的证据可以出现在多个层面：设备可以接受该前缀；两个端点可以互相到达；路由邻接可以形成并保持稳定；监控可以识别接口；故障和恢复可以在不混淆两个地址值的情况下被观察；配置系统可以保留预期前缀，而不是错误地将其规范化。

RFC 的发布并不证明所有后续产品都通过了这些检查。它确立了一种标准行为，实现和部署可以据此被评估。运营商仍需要现行平台文档、分阶段测试、变更控制和回滚。

这是一种有用的责任划分。标准定义可互操作的含义；实现将含义转化为代码；运营商选择部署位置，并维护使部署可被理解的库存。这些层次中没有任何一层可以安全替代其他层。

Retana 的记录属于标准层。当独立软件和运营规程在不丧失唯一性、可达性或诊断清晰度的情况下实现该规则时，这项工作的价值才变得可见。

RFC 3021 未证明什么

RFC 3021 并未证明每条点对点链路都应使用 /31。它并未证明每个旧设备、管理平台、安全控制或排障工具都支持该行为。它并未确定部署数量或整个互联网节省的地址空间数量。

它也没有将地址节约转化为所有权合法性。高效利用可以减少浪费，但路由配置的合法性仍取决于准确的授权、唯一分配、运营责任和纠正错误的能力。如果记录错误或软件不兼容，更小的前缀并不天然更好。

该文件并不替代 IPv6 规划。它解决的是特定的 IPv4 效率问题。持续的价值在于，在 IPv4 点对点编号仍然必要的地方，运营商可以做出有边界的选择。

证据不支持将 /31 部署或后续厂商支持仅归功于 Retana。该 RFC 列出多名作者，经过 IETF 流程，并依赖实现者和运营商才成为运行行为。

更稳妥、也更窄的结论是：Retana 共同撰写了一种标准轨机制，定义了 IPv4 /31 中的两个值如何作为点对点端点地址使用，每条链路节省两个地址，同时要求兼容实现和准确的运营记录。

路由器可能需要可达性而不承担转接职责

第二份记录始于一个不同的约束。路由器可以“存活”到足以被管理、监控，或到达直连目的地，却不适合作为转接路径。运营商在维护、软件初始化、关键资源状况或分阶段引入与退出期间可能需要这种状态。

路由系统通常根据计算成本偏好路径。如果路由器继续通告普通的链路成本，其他路由器可能在其转发能力下降或尚未就绪时仍选择它作为转接。如果路由器完全撤销，运营商可能失去管理可达性和连接目的地的可见性。

运营需求包含两部分：流量应避免将该路由器用作其他节点之间的路径；同时，到达路由器本身或没有替代路径的网络所需的路由应继续可用。

RFC 3137 描述了针对该状态的一种 OSPF 通告技术。它不是发明一条旧路由器无法识别的新协议消息，而是让路由器以非常高的度量通告选定链路。其他 OSPF 路由器使用现有的最短路径行为处理这些通告，并在存在替代路径时优先选择替代方案。

这是一种连续性机制，因为它改变流量偏好，却不需要路由器从拓扑中消失。它可以降低维护切换的突然性，还为只有该路由器唯一连接的目的地保留了一条路径。

该技术并不能保证无损变更。收敛、实现行为、拓扑、时序和流量条件仍然重要。它定义了一种可支持受控切换的共同信号。

RFC 3137 的向后兼容机制

向后兼容是 RFC 3137 的核心。该技术通过 OSPF 实现已经理解的度量起作用。路由器通过以最大链路度量通告相关的非 stub 链路，表明自己不应被用作优先转接节点。

其他路由器不需要新的能力代码就能理解意图。它们计算路径，并在替代路径存在时找到成本更低的替代方案。高度量使经过被标记路由器的转接路径变得不具吸引力，同时不一定移除路由器自身的可达性。

转接与目的地可达性之间的区别至关重要。整体撤销会隐藏设备和所连接的网络。基于度量的通告则可以在保留路由器存在的同时，改变路径穿越它的方式。

该方法也说明了拓扑为何重要。如果没有替代路径，高度量并不能创造出一条。只经此路由器可达的网络的流量仍可能使用它。该技术表达偏好，却无法制造冗余。

因此，运营商需要知道哪些链路是冗余的、哪些目的地是单宿主、域收敛有多快，以及监控将如何解读度量变化。标准行为支持操作，但局部拓扑决定结果。

Retana 和其他作者将该机制定位用于关键状况和平缓运营切换。这种措辞把 RFC 与维护实践联系起来，却并不证明每次部署都使用相同规程或经历相同收敛行为。

平缓引入、退出与保留可达性

“平缓引入和退出”这一短语描述了一个有用的变更序列。正在进入服务的路由器可以先建立邻接并同步状态，再承载普通转接流量。正在离开服务的路由器可以在接口或进程关闭之前，先把转接流量引向别处。

无论哪个方向，时机都很重要。通告高度量可以创造一段时期，在此期间路由器仍然可见，但不被优先用于转接。运营商可以观察拓扑、验证替代路径，并在路由域反映预期状态后继续下一步。

保留可达性具有实际价值。管理系统可以继续联系路由器；运营商可以检查状态和日志；直连地址仍然被表示；一次失败的维护步骤不一定要求重新发现已经消失在路由中的设备。

同样的能力也可能被误用。如果高度量状态无意中保持激活，容量可能集中到其他路径上。如果监控因为路由器仍然可达而将其视为完全健康，预期的维护状态就可能被忽略。如果拓扑缺乏替代路径，流量仍可能以高成本穿越该路由器。

因此，运营规程需要明确的状态记录：路由器为何进入该状态、通告何时改变、预期哪些替代路径、通过了什么验证，以及正常度量何时恢复。协议信号和变更记录服务于不同目的。

RFC 3137 提供协议技术，并不提供运营商完整的维护策略。实现、自动化、观察和回滚规程仍属本地责任。

废止边界

RFC 3137 后来被 RFC 6987 废止。这一事实不应被隐藏，也不应被用来抹去早期文件。标准之所以演进，是因为经验、更广泛的协议覆盖、更清晰的行为或新需求为替代提供了理由。

2001 年的 RFC 仍然是 Retana 及其共同作者所处理问题和当时记录技术的证据。当前的实现决策应查阅现行规范链，而不是把早期 RFC 当作最终权威。

这一区别在人员层面报道中很重要。一份出版物可以在历史上具有意义，却不一定是现行规范。只描述原始文件会误导读者对现行实践的理解；只描述替代文件则会移除展示该运营问题最初如何被标准化的决策历史。

因此，准确记录应保留两种状态。Retana 共同撰写了 RFC 3137；该文件描述了一种向后兼容的 OSPF stub 路由器通告技术；RFC 6987 后来取代了它。本文不声称 Retana 单独控制了这一演进，也不声称每个现行实现都完全不变地遵循 2001 年文本。

版本化标准历史是网络现实的一部分。运营商不仅需要知道文件说了什么，还需要知道哪份文件现行有效、自己的软件实现哪种行为，以及适用哪些切换假设。

BGP 文本需要实现证据

BGP 连接独立运营的网络，因此互操作故障可能超越单一产品或组织的边界。协议规范确立预期行为，但独立代码库可能以不同方式实现可选特性、遗漏用例、以不同方式解读含糊语言，或暴露不同的运营控制。

RFC 4276 通过一份实现报告填补这一证据缺口。该报告以结构化调查实现行为的方式伴随 BGP-4 标准流程。其 259 个问题涵盖广泛的协议细节和运营特性。

Retana 在该工作中担任共同编辑，而非所述实现的唯一作者。报告汇编了 Alcatel、Cisco、Laurel 和 NextHop 的回复。这些组织提供了完成的答案；编辑者负责组织并发布比较。

这种角色边界让记录更强，而非更弱。文件说明了存在的证据以及由谁提供。它不会把编辑工作转化为厂商工程荣誉。

该报告还让差异可见。标准流程可以利用这些差异，识别哪些规范文本、可选行为或实现实践需要更仔细的关注。运营商可以把差异的存在作为理由，去测试其网络所依赖的确切特性。

259 题调查是一张地图，不是一张证书

长篇调查提供覆盖面，但不会自动提供独立核实。RFC 4276 明确说明编辑者没有核实这些回复。这句话是证据的关键部分，而不是可以省略的免责声明。

因此，该报告应被解读为一份受访者提供的实现地图。它记录了四家实现者在某个时间点如何回答一组共同问题。它可以揭示声称的支持、差异以及需要进一步检查的领域。

它不是证明每个答案在每个软件版本中都正确的认证。它并不证明在所有路由规模、策略组合、错误条件、时序序列或运营环境下都能互操作。它不能替代数据包级测试、多厂商实验室、符合性套件或生产观察。

四份完成的回复也定义了样本边界。它们提供的是关于回复实现的证据，而不是每一个 BGP 实现。产品、版本和行为在发布后可能变化。

这些限制并不会让报告变得无用。透明、结构化的比较，强于对“所有实现行为都相同”的毫无根据的假设。报告告诉后来的读者问了什么、谁回答了，以及回答在哪些方面不同。

Retana 的编辑贡献属于这种证据纪律。成果是一份可被检视和质疑的公开记录。本文不会从调查中推断厂商市场份额、产品质量排名或商业结果。

四位受访者与差异的含义

RFC 4276 中列出的完成回复的受访者为 Alcatel、Cisco、Laurel 和 NextHop。在报告所述范围内，他们的回答代表独立的实现工作。

回答之间的一致可能表明不同实现者以相似方式理解并实现了某行为。差异可能表示可选功能、版本边界、解读缺口、实现选择或错误。报告本身是调查的起点，而不是最终诊断。

对运营商而言，差异的存在会改变采购和部署问题。仅有功能名称不够。网络可能依赖特定的属性处理、收敛行为、路由选择细节或错误情形。应在拟使用的软件版本之间测试确切组合。

对标准作者而言，实现报告可以揭示文本在何处不能产生一致的代码。在散文中看似清晰的功能可能产生分歧行为。反过来，广泛一致可以支持规范可实现的判断。

对厂商而言，共同问卷可以使产品边界明确。它也会施加压力，把不支持的行为与缺陷和可选选择区分开来。报告并不裁定每一项差异，但它防止所有差异保持不可见。

教训是：互操作是一种被观察到的状态。发布、品牌和合规语言是输入；独立系统之间的交换提供更强的结果。

标准编辑、实现者和运营商是不同角色

三份文件澄清了三种不同的责任。标准作者定义可互操作行为及其约束；实现者编写并测试代码；运营商选择版本、配置系统、观察结果并管理变更。

一个人在职业生涯中可以承担多个角色，但具体来源不应被拉伸到超出其记录的角色。RFC 3021 和 RFC 3137 将 Retana 与共同撰写的协议决定联系起来；RFC 4276 将他与一次编辑性的实现证据流程联系起来；现行 IETF 档案将他与路由标准参与和曾任领域总监的服务联系起来。

这些记录都不证明他写下了每一实现的厂商代码、在某个特定网络部署这些机制，或控制后续运营结果。本文将这些主张置于范围之外。

角色分离提高问责。配置失败时，根因可能是规范含糊、实现行为、集成、自动化、拓扑或操作程序。把每个结果都归到最知名的标准参与者身上，会妨碍准确诊断。

它也改善荣誉分配。共同作者、审阅者、工作组、实现者、测试者和运营商贡献了不同形式的工作。一篇人员层面文章可以承认 Retana 有记录的决策，而不把他人的工作吸收到他的名下。

这就是归属边界贯穿全文的原因。它们不是降低主题重要性，而是使重要性可辩护的技术准确性的一部分。

运行代码与被记录的状态

只有当行为到达运行系统并保持可观察时，三份记录才有用。一个 /31 前缀必须无歧义地标识两个端点；高 OSPF 度量必须把转接流量转移到真实替代路径，同时保留必要的可达性；BGP 实现必须按照运营商可测试的行为交换和处理路由。

运行代码并不是唯一要求。被记录的状态同样重要。地址计划需要准确的前缀和接口记录；维护系统需要时间戳、原因、预期路径变化和恢复状态；互操作测试需要软件版本、配置、测试用例和观察结果。

没有这些记录，正确行为可能变得与意外无法区分。一次地址节省可能被遗忘，随后被错误配置；维护度量可能超过预期窗口仍然存在；厂商功能可能在缺乏证据的情况下被认为在各版本间等同。

标准提供共享语义；运营台账保存这些语义如何被应用。二者一起支持人员变更、升级、故障和审计之间的连续性。

这就是 Retana 文件所反映的 Heng.lu 现实层：资源唯一性与效用、运行代码证据和运营连续性。本文用该框架作为分析约束，并不以教义替代五个公开来源。

证据仍然是实践性的。当独立系统能够实现协议决定、运营商能够观察它、记录能够解释发生的变化时，协议决定才赢得信心。

维护信号需要负责人和退出条件

RFC 3137 的度量技术会改变路由状态。每次这样的改变都需要负责人和退出条件。原因可能是启动、维护、资源压力、测试或计划移除。预期时长和恢复标准应当明确。

如果在没有负责人的情况下应用高度量，网络可能陷入一种退化但貌似稳定的状态。冗余路径承载更多流量，而监控可能显示被标记的路由器仍然可达。缺少硬故障可能掩盖持续成本。

如果该状态过早解除，转接流量可能在转发或服务就绪之前返回。如果过晚解除，容量和弹性仍然被削减。正确时机取决于本地系统的证据，而不是标准中的固定语句。

运营台账可以把协议信号连接到变更记录。它可以显示受影响的路由器、原因、拓扑预期、验证、应用时间、清除时间和回滚路径。这种记录帮助后来的运营商区分有意的度量与故障或被遗忘的配置。

标准使信号可互操作；组织使变更可问责。Retana 的共同作者身份属于第一项任务。本文不把证据中未出现网络的本地维护程序责任归于他。

互操作是一项持续测试

RFC 4276 捕捉的是一个时间点。调查之后，BGP 实现继续演进，扩展、错误处理、运营实践和软件版本也是如此。2006 年的报告不能证明当前行为。

其持久价值是方法上的：提出精确问题；列出受访者；保留回答；识别差异；说明证据是否经过独立核实；不要把功能标签与可互操作运营混为一谈。

该方法适用于当前部署。运营商应测试他们计划使用的软件版本和功能，并记录配置、预期交换、观察到的路由、错误行为、收敛和回滚。BGP 行为也跨越组织边界，因此共享运营必须被观察，而不是归于单一行为者的权威。

四位受访者展示了独立的代码路径，但样本仍然有边界。后来的证据应补充此前状态，而不是把它变成永久证书。

Retana 的编辑角色支持这条透明的证据路径。它并不使调查成为普遍基准，但展示了标准工作如何揭示实现现实，而不是假设它。

当前角色是背景，不是结果证明

IETF 档案记录了 Retana 的持续参与和曾任路由领域总监的角色，而 INTC 将他列为主席和受托人。注明日期的 RFC 仍是主要证据；角色页面不能证明产品、部署、商业、客户、事故或项目结果。

证据未证明什么

这五个来源并未证明 Retana 独自发明 /31 寻址、OSPF stub 路由器行为或 BGP 实现调查。各 RFC 列出多名作者或编辑，并属于更广泛的标准流程。

它们未证明有多少网络部署了 RFC 3021、全球节省了多少地址，或每个产品和运营工具都正确处理了 /31 链路。

它们未证明 RFC 3137 仍是现行规范。它已被 RFC 6987 废止。它们也未证明每次维护切换都无损，或每个拓扑都有替代路径。

它们未证明 RFC 4276 中每个回答都正确。编辑者说明受访者提供的回答未经独立核实。四份完成回复不能代表每个 BGP 实现或后续版本。

它们未证明厂商市场份额、产品质量、专利所有权、商业影响力或当前雇主成果。它们未确立对私有故障、客户事件、监管决定或后续协议变化的责任。

它们未授权发布私人联系方式、历史地址、电话号码、电子邮件地址、证件或其他个人信息。

证据支持一个更窄却更强的论断：Retana 有记录可查地作为三份记录的共同作者或共同编辑，使地址效率、路由维护和实现比较更加明确且可测试。

一份有边界的标准与运营记录

记录始于一项号码资源约束。传统 IPv4 子网语义可能为只有两个端点的链路消耗四个值。RFC 3021 定义了点对点 /31 的解读，将两个值都用作主机地址，在兼容系统和准确记录支持该选择之处，每条链路节省两个值。

它继而转向一项维护约束。路由器可能需要保持可达，却不承载优先转接流量。RFC 3137 记录了一种向后兼容的 OSPF 度量技术，可在保留必要可达性的同时把转接引向替代路径。后来 RFC 6987 的替代仍是现行规范历史的一部分。

它接着处理一项证据约束。BGP 规范文本不能证明独立实现行为相同。RFC 4276 记录了一次包含 259 个问题和四份完成回复的调查，展示差异，并保留了回答未经独立核实的限制。

Retana 的贡献在标准和编辑层有记录。结果通过实现者、运营商和持续记录才变为运营现实。本文不把集体标准工作转化为英雄叙事。

共同的教训很简单：当地址值、路由度量和协议特性的语义清晰、其实现可比较、其运营状态可观察并可纠正时，它们才值得信赖。这些已发布的文件使这些条件更加明确。

来源