摘要

  • RFC 3113 要求 3GPP 在可行时原样采用 IETF 标准，不重复 IETF 已做的工作；若确有修改需求，应把问题带到相应 IETF 工作组，找不到工作组时再交给合适的领域主任。
  • 协作没有产生一个共同主权。两家机构继续按各自的知识产权、规范起草、批准与维护程序行动；联络人传递信息，却无权为 IETF 规则创造例外。

两张时间表不能生成第三种权力

移动系统的发布周期正在向前走，一个它依赖的互联网协议却可能仍在另一家机构讨论。3GPP 知道自己的终端、无线链路、核心网和商业发布时间。IETF 知道自己的工作组、共识过程和协议文本。双方都掌握重要事实，但任何一方都不能只凭“我需要你”就取得对方的批准权。

RFC 3113 在 2001 年 6 月把这个问题写成制度接口。它希望技术规范及时完成，并与既有固定和移动互联网系统、设备、协议实现最大互操作。紧接着，文档划出边界：每家机构仍按自己的规则和程序运作，包括知识产权政策、规范形成、批准与维护。

这不是礼貌性声明。它把依赖与管辖权拆开。3GPP 引用一份 RFC，不代表 IETF 批准了整套移动架构；IETF 拥有某个协议的标准过程，也不代表它可以决定 3GPP 的全部发布内容。协作层的职责，是让请求找到真正能决定的人，而不是把请求本身洗成决定。

先复用，再把修改送回原处

RFC 3113 记下 3GPP 的优先做法：可行时原样采用互联网标准，而且无意重复 IETF 已完成的工作。这个默认值能避免两种分裂。一种是两家机构为同一问题各写一套规范；另一种更隐蔽——移动版仍沿用协议名称，却在字段或行为上形成私人分叉。

“原样”不是绝对禁令。无线传输、移动状态、终端资源或安全架构可能暴露原规范没有处理的约束。RFC 因此规定变化路径：3GPP 若认为需要增加或修改，应直接向合适的 IETF 工作组提出；没有对应工作组，则找到适当的 Area Director。

关键不在“谁声音更大”，而在问题回到哪个控制面。3GPP 提供需求、环境证据与时间压力。IETF 用自己的程序决定是否以及如何改变 IETF 协议。3GPP 再决定如何在自己的规范中依赖结果。联络层能标出瓶颈，不能替两边按下批准键。

如果把这层做厚，风险反而增加。一个协调办公室一旦能以“赶发布”为名绕开工作组，它就会从路由器变成无责任的关口。RFC 3113 选择了薄接口：暴露依赖、找到责任主体、保存版本，不占有决定。

无线经验可以改变论证，不能自动改变授权

这份文档也为 IETF 指出 3GPP 内部的技术知识分布：无线接入与物理传输、移动管理与核心网、终端与应用、总体架构、安全和运维分别由相应技术规范组承担。

这是双向协作，而不是单向消费 RFC。一个在固定网络看来合理的重传或状态假设，到了无线链路上可能代价惊人；一个移动终端的切换，会把看似稳定的路径变成连续状态变化。3GPP 专家能把这些约束带进 IETF 讨论，使协议面对真实运行环境。

但专业知识与授权属于两类证据。知识说明设计会遇到什么；授权说明谁可以批准什么。参会、写信、最了解故障，都不自动赋予替另一组织作决定的权力。混淆二者，会把专家的可信度借给从未获得委托的制度主张。

RFC 3113 的安排恰好保留二者：专家进入正确技术场所，批准仍留在原有程序。

联络人是信使，不是例外制造者

文档鼓励工作层尽量非正式沟通，并参加相应邮件列表。必要时也可使用正式通信，由 IETF 领域主任和 3GPP 技术领导协助。设立联络或报告人，是为了解决无法通过普通工作组关系轻易处理的行政问题。

随后，RFC 明确封住捷径：IETF 联络人无权对 IETF 政策与程序作例外或特别安排。他能把信送到正确房间，却不能替房间形成共识。

2005 年的 RFC 4052 把这种边界扩展成通用规则。联络关系可防止重复劳动，但不得妨碍任何一方追求自身 mandate；凡落入 IETF 的工作，仍按通常 IETF 程序进行。联络经理可以改投误寄的请求、跟进依赖、携带经授权的信息，却不能因“代表 IETF”四个字而自行产生立场。

对外联络声明也有明确批准链。代表工作组的声明需要工作组讨论与主席同意；代表领域，需要领域主任；代表整个 IETF，需要 IETF 主席。RFC 4053 对这种文书的定义很朴素：它是一封组织间商务信函，可以请求信息、评论或行动。送达不是批准，截止日期也不是命令权。

开放文档让依赖从传闻变成证据

RFC 3113 鼓励双方共享有共同利益的草案。2001 年的文本特别强调网页开放访问，以及帮助对方理解文档结构的联系点。今天看来普通，当时却决定了一条依赖能否被精确审计。

有了可访问文本，“3GPP 正在等 IETF”可以被还原为具体 3GPP 规范、具体 IETF 草案版本、规范性或资料性引用、责任工作组和期望时间。讨论不必依赖会议转述。

状态仍不能混用。Internet-Draft 是进行中的工作，不是已批准 RFC；某个草案版本即使字节稳定，也可能过期或被替代。3GPP Technical Report 与 Technical Specification 也不是同一层级。联络声明说明存在请求，不证明接收方已经接受。

RFC 4691 后来描述了实际操作：3GPP、3GPP2 与 OMA 定期提供依赖清单，联络经理跟踪这些清单，必要时把加速分配 RFC 编号的请求转给相应领域主任。它使时间压力可见，却没有承诺 IETF 必定按另一组织的排期完成。

二十五年后，原则仍在，细节已经老化

IETF 当前仍把 3GPP 列为正式联络关系，并指向 RFC 3113。2026 年 3 月的一份 Internet-Draft 提议更新旧文档，理由是双方组织结构、名称、文档访问与协调细节已变化；它同时说，高层原则仍然有效：可行时原样采用、不重复工作、需要修改时回到 IETF。

必须尊重证据状态。这份草案是 work in progress，不能当成已经批准并废止 RFC 3113 的新 RFC。它能证明当前作者希望保留哪些原则，不能证明标准过程已经完成。

同月的 IETF–3GPP 协调会议纪要展示了接口的现实：跨组交流长期未结、反馈一度漏看、3GPP 依赖尚未完成的草案、3GPP 更愿意用 RFC 作为规范性引用，也有 IETF 不准备更新而由 3GPP 自行处理的事项。不同问题得到不同路径，恰恰说明没有一个合并权威替所有人作答。

这些材料不证明协作解决了每个问题，更不证明某一代移动网络因 RFC 3113 而成功。它们只证明依赖、版本、时限与责任主体至今仍是运行问题。

分权保管不是缺陷，而是安全属性

3GPP 保管自己的架构、发布与规范；IETF 工作组、领域和 IESG 保管 IETF 协议工作；IAB 管理联络关系；联络人管理路径与跟进；编辑确定实际引用；实现者把某个版本变成代码；运营者承担部署结果。

任何单件证据都不能覆盖整条链。3GPP 引用证明依赖，不证明 IETF 批准周边系统；RFC 证明出版，不证明部署；联络信证明请求，不证明接受；会议纪要证明讨论，不证明互操作；一段运行代码证明行为，也不取得重写制度边界的权力。

分权保管阻止了三种扩张：一方的时间表不能改写另一方程序；拥有一个协议不能扩张为拥有整个依赖架构；私人修改不能悄悄以同一协议名进入网络。

RFC 3113 的历史价值，不是让两个组织说上话这么简单。它让协作具备可追责结构：共享文件、标出依赖、把专家送到正确场所、把决定留给承担它的主体，并保存真正进入发布的版本。双方共享同一套系统，却没有合并批准权；正因如此，边界才可能长期工作。

来源

  1. https://www.rfc-editor.org/rfc/rfc3113.txt
  2. https://www.rfc-editor.org/rfc/rfc2850.txt
  3. https://www.rfc-editor.org/rfc/rfc2026.txt
  4. https://www.rfc-editor.org/rfc/rfc4052.txt
  5. https://www.rfc-editor.org/rfc/rfc4053.txt
  6. https://www.rfc-editor.org/rfc/rfc4691.txt
  7. https://www.rfc-editor.org/rfc/rfc3131.txt
  8. https://www.ietf.org/about/liaisons/
  9. https://www.ietf.org/archive/id/draft-kes-rfc3113bis-01.html
  10. https://datatracker.ietf.org/doc/minutes-interim-2026-ietf3gpp-01-202603160445/
  11. https://wiki.ietf.org/group/iab/3gpp_liaison_relationship
  12. https://www.3gpp.org/ftp/Information/Working_Procedures/archive/2019-08-23/3GPP_WP.htm