编者按：为了实现网络强国的战略，越来越多的工程师会向IETF提交个人草案（draft），并期望有朝一日会成为RFC。

　　一般而言，草案成为RFC的最主要途径是该草案被IETF的某个领域中的某个工作组“认领”。本文介绍IETF的工作组认领“草案”的流程和规则。值得指出的是工作组正式认领一项草案后，草案的原始作者虽然通常还是这个工作组草案的作者，但不再拥有更改工作组草案文本的控制权。也就是说，如果作者愿意把草案提交至IETF，则意味着他放弃了对草案的拥有权，把它无偿的分享给世界。本文基于IETF的一个草案介绍IETF工作组认领个人草案的相关流程。预计这个草案本身也会经过这一过程，最终成为IETF的RFC。

　　引言

　　根据[RFC2418]，互联网草案（Internet-Drafts，I-D）用于“发布和传播工作组讨论进程中的文档”。然而，大多数I-D都是以个人提交的形式开始的，只有被工作组决定认领后才能成为工作组文档。

　　互联网草案被工作组采用之后

　　在工作组正式认领一项草案后，其原始作者不再拥有更改工作组草案文本的控制权。也就是说，作者只有发布更新版的草案的权力，对草案的所有实质性修改都需要达成工作组的“共识”，而不再由作者决定。

　　实际上，原始作者通常会继续编辑文档并对文档的语言进行修饰。但如果文档有实质性的更改，则必须提交至工作组，根据[RFC2418]在工作组达成“大致共识”。当然，也有可能有新作者或新编辑加入草案作者的行列，或者原始作者退出。

　　“认领”代表着一项承诺，即工作组将在这个草案上花费时间和精力，但这并不能确保证草案将能够达成工作组的共识并提交IESG作为RFC发布。

　　通过互联网草案的规则

　　工作组发起对某一个草案的“领养”征求意见的流程并不是IETF标准流程的必需步骤。工作组主席有权决定哪个文档可以被工作组认领，并根据规程创建工作组草案。

　　一个简单的情况是，工作组可以决定将现有文件一分为二，仅采用其中某一部分。IETF的理念是在文档中保留不必要的部分是可恶的官僚作风。如果工作组决定创建一个设计团队来解决这个草案中涉及的问题，则表明工作组已认领了该草案。因为工作组没必要花费宝贵的时间委任设计团队去处理没有认领的草案。创建设计团队通常发生在工作组无法在两个相互竞争的个人草案之间做出选择，而决定合并它们的时刻。

　　根据[RFC2026]所述，未经工作组认领的草案也可以提交给IESG。

　　通常推荐工作组主席通过征求工作组的意见来决定是否认领一个个人草案。但工作组主席也应该考虑[RFC7221]中描述的其他方法。

　　o 在相关的工作组中对某个草案进行了一段时间的技术性讨论之后，任何参与者可以要求认领该草案。

　　o工作组主席有权决定何时征求工作组的意见，以决定是否认领某个个人草案。但在工作组的讨论表现出对某个草案明显兴趣时，主席应顺从这一趋势。

　　o 工作组主席或工作组秘书必须向工作组邮件列表发出正式认领草案的征求意见请求，同时必须至少留出两周的响应时间。

　　o  认领请求应提醒所有参与者，而不仅仅是作者，他们有义务根据[RFC8179]披露相关的知识产权信息。

　　o  参与者在响应工作组关于认领草案的征求意见请求时应考虑以下方面：
　　　　* 草案必须符合工作组目前的章程，或者只需对章程作简单修改。
　　　　* 草案的目的应该明确。
　　　　* 草案应该是有用的。
　　　　* 文档的写作质量应足以作为进一步工作的基础。
　　　　* 不应有强烈的技术异议。
　　　　* 相关知识产权信息的披露都应是可接受的。
　　　　* 该工作不应与IETF中其他工作冲突。

　　o  对这些标准的非正式总结是：这是工作组想要以近似于草案所述的方式来解决问题吗？

　　o  在两周的响应时间之后，工作组主席必须及时审议意见和讨论，以判断是否就认领草案达成大致共识，以及工作组是否对这项工作有足够大的兴趣，从而有可能完成这项工作。

　　o  如果有这样的共识，工作组主席将宣布结果。如果结果是同意，将要求作者使用适当的命名约定发布草案的一个新版本。

　　o  工作组认领个人草案的整个流程受到[RFC2026]中描述的上诉流程的制约。

　　撤回被通过的互联网草案

　　有时，由于缺乏兴趣，缺乏努力或缺乏共识，认领的草案没有达成工作组能够提交给IESG作为RFC发布的共识。在这种情况下，工作组可以正式撤回草案，将其明确从工作组的议程中删除，并交还给原始作者控制。

　　工作组草案的撤回应是相关工作组明确显示出的结论，有关决定应遵循下列建议：

　　o 有证据表明工作组草案的进展已停滞相当长一段时间后，工作组主席应评估明显缺乏进展的原因。这些原因可能包括缺乏兴趣，缺乏努力或缺乏共识。

　　o 如果一份文件的进展停滞了相当长一段时间，工作组主席应与工作组草案起草人和编辑协商，设法恢复进展，并根据缺乏进展的原因采取适当行动。例如，由于明显缺乏兴趣而被搁置的工作组草案，可能会通过号召一些志愿人员对工作组草案进行详细审查而取得进展。同样，由于编写者/编辑缺乏努力而停滞不前的工作组草案，可因工作组吸收新的草案编辑或代替部分现有编辑而取得进展。

　　o 如果在促使工作组草案取得进展的努力失败之后，完成工作仍然不太可能，工作组主席可自行决定考虑正式撤回工作组草案。

　　o 在这种情况下，工作组主席或工作组秘书必须向工作组邮件列表发出正式撤回工作组草案的征求意见请求，同时必须至少留出两周的响应时间，并解释其原因。

　　o  在两周的响应时间之后，工作组主席必须及时审议意见和讨论，以判断是否有任何具体证据表明完成工作是可行的，还是不太可行的。

　　o  如果不可能在文档上取得进一步进展，工作组主席将宣布协商一致倡议的结果和工作组文件的正式撤回。这将导致该文件从工作组的议程中删除，并交还作者控制。

　　o  工作组撤回草案的整个流程受到[RFC2026]中描述的上诉流程的制约。

引用标准

[RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <https://www.rfc-editor.org/info/rfc2026  >.

[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, September 1998, <https://www.rfc-editor.org/info/rfc2418  >.

[RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, DOI 10.17487/RFC5378, November 2008, <https://www.rfc-editor.org/info/rfc5378  >.

[RFC8179] Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 8179, DOI 10.17487/RFC8179, May 2017,<https://www.rfc-editor.org/info/rfc8179  >.

资料参考

[RFC7221] Farrel, A. and D. Crocker, Ed., "Handling of Internet-Drafts by IETF Working Groups", RFC 7221, DOI 10.17487/RFC7221, April 2014, <https://www.rfc-editor.org/info/rfc7221  >.

原文：《Process for Working Group Adoption of Drafts》  ，翻译：张登科