参会日期：2026-03-15
参会时间：14:00 - 15:30
参会地点：Grand Ballroom 3
会议名称：New Participant Program (Afternoon Sessions 5-7)
参会者 & 本文章撰写者：赵星涵
ISC 菁才计划
RFC3161 时间戳签名信息如下
上午场内容总结
<此处插入公众号超链接>
| 场次 | 会议 | 总结 |
|---|---|---|
| Session 1 | Introduction to the IETF | 讲解了 IETF 的组织架构、资金模式、治理结构以及使命 |
| Session 2 | Participating in the IETF | 讲解了参与方式，包括邮件列表、Datatracker、会议工具 |
| Session 3 | Standards development | 讲解了标准制定流程，包括领域、工作组、共识机制及标准发布流程 |
| Session 4 | IETF Hackathon | 讲解了 IETF 黑客松 |
5. Internet-Drafts and RFCs
本次是 IETF 新参与者培训下午场的第一节，专门讲解了 Internet-Drafts (I-Ds) 和 RFCs
RFC 的核心属性
RFC 是 IETF 的最终产出物，一旦发布，其内容不可更改。如果发现错误，只能发布勘误表（Errata）或新的 RFC 来废弃/更新它，不能直接修改原文。截至目前，已发布接近 10,000 篇 RFC
传统 RFC 使用纯文本格式，但是自 RFC 8650 起，XML 成为权威源格式，其他格式均由此生成。基于 XML 生成的 HTML 成为首选阅读格式，支持响应式布局、SVG 图表和元数据链接等功能
ID 的核心属性
ID 有超过 40,000 份的存档，结构与 RFC 类似，但仅能声明预期状态。在未被采纳前无正式地位，任何人都可撰写并提交，无需审批，需被某个工作组或流采纳后才具正式意义
RFC 的状态
| 状态 | 说明 |
|---|---|
| Informational（信息类） | 为社区提供一般信息，不代表共识，也不一定经过严格审查 |
| Experimental（实验类） | 记录研究结果、原型实现或非标准技术 |
| Proposed Standard（提议标准） | 标准的第一阶段，规范已稳定，至少有两个独立实现证明其可行性 |
| Draft Standard（草案标准） | 该状态已弃用。新文档不再进入此状态 |
| Internet Standard（互联网标准） | 标准的最高阶段，需要极高的成熟度、广泛的部署和互操作性验证 |
| Best Current Practice（最佳当前实践） | 记录最佳当前实践 |
| Historic（历史类） | 表明该 RFC 已被新技术取代，或因其他原因不再推荐使用 |
| Unknown | 仅存在于极早期的 RFC（RFC 1128 之前），因为当时未定义状态字段 |
RFC 的出版流
RFC 并非全部来自 IETF 工作组，有五种不同的“流”，决定了文档的来源和审核路径
ID 和 RFC 的文档结构
无论是 ID 还是 RFC，都必须遵循严格的结构规范
头部元数据部分
ID 与 RFC 共有
- 标题
- 作者 / 编辑
- 发布日期
- 状态
- 更新 / 废弃的 RFC 列表
ID 特有
- 工作组名称（如已采纳）
- 流标识
- 过期日期（6个月）
- ISSN / DOI
自动生成内容
- 本文档状态（Status of this Memo）
- 版权声明（Copyright notice）
- 目录（Table of contents）
正文部分
- 摘要（Abstract）
- 引言（Introduction）
- 安全考虑（Security Considerations）
- IANA 考虑（IANA Considerations）
- 参考文献（References）
如何撰写 ID
工具规范
对于新人，使用 kramdown-rfc 工具，可以自动将 MD 转换为 RFCXML
对于老资历，可直接编写 RFCXML
使用 author-tools.ietf.org 提供的在线工具进行文章结构检查
最终应提交到 Datatracker，且 Datatracker 只接受 RFCXML 文件
语言规范
必须遵循 BCP 14（RFC 2119 / RFC 8174）定义的关键字：MUST, MUST NOT, SHOULD, MAY 等，因为这些词在法律和技术上具有特定含义
AUTH48
当一份 ID 通过了 IESG 审核，将进入发布为 RFC 前的最后一步：AUTH48
AUTH48 由 RPC（RFC Production Center）执行。在此阶段，严禁修改文档的技术内容，只能修改格式错误、澄清歧义和笔误。任何技术变更都需要退回重新走 IESG 审核流程
6. The Power of the Community
IETF 的技术标准并非仅由代码或文档定义，而是由“人”和“共识”构建的。这意味着，学习社区文化、社区行为规范以及人际互动在 IETF 的工作中是至关重要的
在 IETF 的社区中，所有互动必须保持尊重，禁止人身攻击、骚扰、歧视或恐吓行为。批评应针对技术方案、文档内容或逻辑，而非针对个人
7. Wrap-up
这是新参与者培训的最后一节课，对今天的全部课程进行了收尾与总结，并提供本次会议的具体活动指引，列出获取帮助的渠道
Above all - Enjoy!
