IETF之道:互联网工程任务组新手指南

Paul Hoffman, Editor


About This Document

Copyright © 2012 IETF Trust. All rights reserved.

The current version of this web page can always be found at http://www.ietf.org/tao.html; that page can also be retrieved protected by TLS. To contribute to this document or to discuss its content, please join the "tao-discuss" mailing list. A history of the major versions of the Tao can be found here. This particular version was created on 2012-11-02.

此网页使用的语言为中文。 如下为《IETF之道》的 各种语言版本列表


1. 简介

自成立初期以来,互联网工程专责小组(IETF)面对面会议的与会人数一直以惊人的速度增长。 每次IETF会议都会有很多新人参加,并且其中很多人将继续成为定期参会者。 会议规模较小时,新人相对容易适应环境。但是今天,一位新人会见到更多新人, 有些人之前只是作为文档或发人深省的电子邮件作者而为人所知。

本文档描述了IETF的许多方面,其目的是向新人解释IETF的运作方式。 这将带给他们一种温馨有趣的感觉,从而使会议和工作组的讨论变得更富有成效,人人都有收获。 此文档开篇相当简短,但之后会逐渐展开详述, 以回应IETF新人在他们首次参加面对面会议或者积极参加自己的首个工作组之前希望了解的内容。

当然,实际情况是很多IETF参与者根本不去参加面对面会议。相反, 他们活跃在不同的IETF工作组的邮件列表上。 由于新人可能难以理解工作组的内部运作, 因此本文档提供了新人成为积极参与者所需的一般信息。

IETF始终处于变化当中。尽管预计本文档中的原则随着时间推移会保持基本不变, 当您读到它时,一些实用细节可能已经发生了变化;比如在进行某种操作时, 一个基于网页的工具也许已经取代了电子邮件地址。

《IETF之道》中提到了包括BCP RFC, 技术文档RFC和STD RFC的多种IETF文档。BCP RFC为互联网的当前最佳实践提供建议RFC; 技术文档RFC是IETF的主要技术文档系列,被委婉地称作“请求建议”;而STD RFC是被确认为“标准”的RFC。 实际上,全部三种文档都是RFC;参见Section 6以了解更多信息。

此网页是《IETF之道》RFC系列的延续。 参见[RFC6722]了解系列中最后一个RFC如何成为此网页的说明。 此《IETF之道》网页版是基于[RFC4677],合著者是Susan Harris。 此文档的最早版本发表于1994年,作者是Gary Malkin。

那么,为什么称为“道”?道的发音为 "dow",它是中国古代思想家老子学说的精髓。 它为人熟知的标志是黑白相间的阴阳圈。道家学说认为宇宙是一个有机体, 而人类是作为宇宙整体互相依赖的部分。道有时被译为“方法”,但根据道家哲学, 这个字的真正含义无法用文字表达。

1.1 《IETF之道》中使用的首字母缩略词和缩写

以下列出本文档中的一些首字母缩略词和缩写。

术语 含义
AD 领域负责人
BCP 当前最佳实践
BOF 专题讨论会
FAQ 常见问题
FYI 仅供参考(RFC)
IAB 互联网架构委员会
IAD IETF行政主管
IANA 互联网号码分配机构
IAOC IETF行政监督委员会
IASA IETF行政支持活动
ICANN 互联网名称与数字地址分配机构
I-D 互联网草案
IESG 互联网工程指导组
IETF 互联网工程任务组
IPR 知识产权
IRTF 互联网研究任务组
ISOC 互联网协会
RFC IETF正式发布的文稿名称
STD 标准(RFC)
WG 工作组

2. 什么是IETF?

IETF是一群人自发组织的松散组织,为互联网技术的工程和演变做出了贡献。 它是参与制定新互联网标准规范的主要机构。IETF的与众不同之处在于它是作为事件的集合来存在, 而非一家公司,而且没有董事会、没有会员、不收会费; 参见[BCP95]《IETF使命声明》了解更多信息。

IETF的使命包括:

IETF会议并非会议,尽管也有技术演讲。IETF不是传统的标准组织, 尽管它制定的许多规范成为了标准。IETF由志愿者组成, 他们中的许多人为了完成IETF使命,每年会晤三次。

IETF没有会员制。任何人都可以注册并参加任何会议。 加入IETF或工作组邮件列表,即可成为IETF成员(参见Section 2.3)。 在这里能找到关于IETF当前活动和所关注问题的最佳信息。

当然,如果没有某种结构,没有任何组织能像IETF一样成功。就IETF而言, 其结构由其它组织提供,有关描述请参见[BCP11]《参与IETF标准流程的组织》。 如果您参与IETF而且只阅读一个BCP,那么这就是您应该阅读的。

IETF网站http://www.ietf.org是关于 会议、工作组、互联网草案、RFC、IETF电子邮件地址和更多其它内容的最佳信息来源。

从很多方面来说,IETF的运行建立在其参与者的信念之上。 “创始信念”之一体现于David Clark早期说的有关IETF的一句话:“我们拒绝国王、总统和投票。我们信奉“大致共识”和“运行的代码”。” IETF内普遍接受的另一个信念则如Jon Postel早期所说:“发送建议时要保守;接受建议时要开放。”

IETF是真正关于其参与者的。因为IETF欢迎所有有兴趣的个人,IETF参与者来自世界各地, 而且来自互联网行业的许多不同领域。IETF仅使用英语开展工作。 参见Section 3.12了解关于许多人融入IETF方式的信息。

另一件对新人来说很重要的事情是:IETF绝对没有“运营互联网”,尽管也许有人错误地这样说。 IETF制定常被互联网用户采用的自愿性标准,但它不控制互联网,甚至也不在互联网上巡查。 如果您因为想成为监督者的一员而对IETF产生了兴趣,那IETF可能会令您非常失望。

2.1 低调开始

IETF首届会议于1986年1月在圣地亚哥Linkabit召开,有21人参加会议。 1986年10月在门洛帕克SRI召开的第四届IETF会议是首次有供应商参加的会议。 1987年2月在加利福尼亚州美国国家宇航局艾姆斯研究中心(NASA Ames Research Center)召开的第五届IETF会议引入了工作组这个概念。 1987年7月在佛吉尼亚州麦克莱恩市MITRE召开的第七届会议是参会人数首次超过100人的会议。

第14届IETF会议于1989年7月在斯坦福大学召开,它标志着IETF整体结构的一次重要改变。 当时对许多“任务组”进行监督的IAB(当时是互联网活动委员会,现为互联网架构委员会)的结构被改变, 仅留下两个机构:IETF和IRTF。IRTF的任务是考虑互联网的长期研究问题。IETF当时也发生了变化。

互联网协会(ISOC)于1992年1月成立后,IAB向ISOC提出IAB的活动应在互联网协会的支持下进行。 在日本神户召开的INET92会议上,ISOC董事会批准了IAB的新章程,以反映所建议的关系。

IETF于1993年7月在荷兰阿姆斯特丹召开会议。这是首次在欧洲召开的IETF会议, 美国和非美国参会者几乎各占一半。IETF于2000年首次在亚洲(澳大利亚阿德莱德)召开会议。

目前,IETF在北美、欧洲及亚洲召开会议。其意图是每年在每个地区召开一次会议, 尽管由于日程安排问题,会议更多在北美召开,而在欧洲和亚洲召开较少。 非美国参会者的数量继续居高不下; 比例约占50%,即使在美国召开的会议也是如此。

2.2 组织结构

2.2.1 ISOC(互联网协会)

互联网协会是一个促进互联网扩张的国际性、非盈利的会员制组织。 ISOC实现这个目标的方法之一是通过此处描述的其他以"I"开头的组织 团体的财务和法律支持,尤其是IETF。 ISOC为许多在IETF过程中担任领导职务的人提供保障,并在某个以"I"开头组织希望对媒体发言时作为公共关系渠道。 ISOC是互联网的主要无名英雄之一。

自2005年春开始,ISOC还成为IETF直接雇佣的行政人员的总部。 这一点在[BCP101]《IETF行政支持活动结构 (IASA)》中有详细描述。 员工最初仅包括一位行政主管(IAD),负责全职监督IETF会议计划、支持服务的运行 (秘书处,IANA(互联网号码分配机构)和RFC编辑(本节后面有详细叙述))和预算。 他或她(目前为男性)领导IETF行政支持活动(IASA),负责诸如收取会费,支付发票等任务, 还为IETF工作组、IESG、IAB以及IRTF的工作提供支持工具(本节后面有详细叙述)。

IETF管理监督委员会(IAOC)由志愿者组成, 所有成员均由IETF社区以及适当的ISOC和IETF领导团队前当然成员直接或间接选拔。 IASA和IAD接受IAOC指导。

IAD和IAOC都对IETF标准制定没有任何影响,下面我们就要讲述这个问题。

2.2.2 IESG(互联网工程指导组)

IESG负责IETF活动的技术管理以及互联网标准流程。它按照ISOC董事会批准的规则和程序管理流程。 但是,IESG并不过多行使直接领导权,如同您在许多其他标准化组织中所看到的那样。 如其名称所示,其角色是进行指导而非发号施令。IESG批准或指导IETF工作组(WG)的成果、 启动和结束工作组并确保即将成为RFC的非工作组草案的准确性。

浏览IESG网页http://www.ietf.org/iesg.html, 了解有关正在处理的草案、已发表的RFC、进行最终审议的文档以及IETF月度状态报告的最新信息。

IESG由领域负责人(常被称为 "AD")组成,他们由提名委员会(通常称为 "NomCom")选拔,任期为两年。 IESG成员的选拔过程详见[BCP10]《IAB和IESG的选择、确认和恢复过程:提名和恢复委员会的运行》。

当前领域及缩写如下所示。

领域 描述
应用(APP) 用户程序,如电子邮件和网页所看到的协议
总体(GEN) IETF流程以及不适合其他领域的工作组总览(这种情况非常少见)
互联网(INT) 不同的IP数据包传递和DNS信息处理方式
运营和管理(OPS) 运营方面、网络监控和配置
实时应用程序与基础架构(RAI) 对延迟敏感的人际通信
路由(RTG) 把数据包发往它们的目的地
安全性(SEC) 认证和隐私
传输(TSV) 针对特殊数据包的特殊服务

由于IESG对互联网草案能否成为RFC有着巨大影响力,很多人多少会把AD看作天神一般。 IETF参与者有时毕恭毕敬地征求AD对某个特定主题的意见。但是,大多数AD其实与你我一样平凡, 而且很少以高高在上的态度说话。事实上,当被要求提供特定技术意见时,AD也许经常会听从IETF参与者的意见, 因为他们觉得参与者在此问题上的知识比自己更丰富。

人们期望某个特定领域的AD比其他任何人都了解此领域工作组的综合工作。 另一方面,整个IESG审查每一个被建议成为RFC的互联网草案。 任何AD都可以把他/她感到严重担忧的草案记录为“讨论”,以进行投票。 如果通过讨论无法解决这些担忧,则规定一个推翻程序, 必须至少有两位IESG成员表示担忧才能阻止草案进入下一阶段。 这些程序帮助确保AD的“偏爱项目”如果对其他IETF协议产生负面影响就无法进入标准系列, 同时AD的“心病”无法无限期地形成某种妨碍。

这并不是说IESG从不行使权力。当IESG看到工作组违背其章程, 或者当工作组要求IESG将其设计拙劣的协议变为标准,那么IESG会采取行动。 事实上,由于工作量非常大,IESG通常被动地采取行动。它最终批准多数工作组把互联网草案变为RFC的请求, 而且通常在已经出现严重错误时才会介入。另一个看待此事的方法是:选拔AD的目的是让他们思考,而非只是执行流程。 IETF标准的质量既取决于它们在工作组中受到的审查,也取决于AD对工作组审查进行的详细监察。

IETF按照大致共识的原则运行,由IESG评判一个工作组的结果是否符合IETF社区的共识。 (参见Section 4.2了解有关工作组共识的更多信息。) 因为如此,IESG可能阻止工作组所产生结果的一个主要原因是该结果并未真正获得IETF整体, 即所有领域内的全部工作组的共识。例如,一个工作组的结果也许会与来自另一个领域的其他工作组开发的技术相冲突。 IESG的一项重要工作是监督所有工作组的成果,以帮助避免IETF协议相互冲突。 这就是为什么AD应该审查来自所有领域的草案,而非只审查自己领域的原因。

2.2.3 IAB(互联网架构委员会)

IAB负责密切关注互联网的“大局”,并专注于IETF活动各个领域中的长期计划和协调。 IAB随时掌握着互联网重要的长期问题动态,并且把这些问题告诉它认为应该了解这些问题的人士。

IAB成员特别关注IETF的新兴活动。当提议设立一个新的IETF工作组时, IAB会审查其章程以保证架构的连续性和完整性。甚至在小组获准成立之前, IAB成员也非常愿意和提议设立小组的人士讨论新的想法。

IAB还支持和组织互联网研究专责小组,并召集邀请性研讨会, 对具体的互联网架构问题进行深度审查。研讨会报告通常会向IETF社区和IESG提出建议。

IAB还负责:

和IESG一样,由NomCom选拔的IAB成员经ISOC董事会批准后,将任职两年。

2.2.4 IANA(互联网号码分配机构)

IETF活动的核心注册机构是IANA(参见http://www.iana.org)。 许多互联网协议要求在协议推出后,有人负责跟踪记录新增的协议项目。 此类必要注册的典型例子是TCP端口号和MIME类型。IAB已指定IANA组织执行这些任务, 而IANA的活动由互联网名称与数字地址分配机构ICANN提供财务支持。 IAB选择了ICANN,而且IANA提供的服务是免费,详见[RFC2860]

10年前,没有人会预料到能在报纸头版看到IANA的消息。IANA的角色始终非常低调。 IANA同时管理着根域名系统这一事实迫使它成为一个更为公开的机构, 一个曾经被各种从不关注其角色为何的人恶意中伤的机构。 如今,IETF一般不再参与IANA域名和IP地址的分配职能(现在由ICANN监督)。

尽管作为注册机构听起来并不有趣,许多参与者将证明IANA一直以来对互联网有多么重要。 让细心保守的经营者运行一个长期稳定的存储库,让人们大胆尝试,无需担心把事情搞砸。 人们曾严重依赖IANA创始人Jon Postel来维持秩序,同时互联网始终在突飞猛进的增长, 在他于1998年过早地去世之前,他的工作做得很出色。

2.2.5 RFC编辑

RFC编辑和IESG一起, 对互联网草案进行编辑、设定格式,然后作为RFC发表。 一项重要的次要角色是为所有RFC提供一个权威性的存储库(参见http://www.rfc-editor.org)。 某个RFC发表后,就不再进行修订。如果它描述的规范发生了变化,那么标准将在“废止”第一个RFC,在另一个RFC中重新发表。

IETF社区内最流行的一个错误观念是IANA履行RFC编辑的角色。 虽然RFC编辑和IANA多年来均由同一批人担任,但RFC编辑是一项单独的工作。 今天,这些工作由单独的组织完成。IAB批准将担任RFC编辑的组织和RFC编辑的总政策。 RFC编辑由IASA资助。

直到2009年年底,RFC编辑都是一个单独实体。 其职能被IAB在与IETF社区协调后分割为许多能够被不同的人或组织执行的角色, 由IAB任命的RFC系列编辑领导。有关RFC编辑模式的描述请参见[RFC6635]

2.2.6 IETF秘书处

的确有几名拿着报酬维护IETF的人员。IETF秘书处提供日常后勤支持, 这主要是指协调面对面会议以及管理IETF特定的邮件列表。 秘书处也负责保持官方互联网草案目录的更新并使之井然有序、维护IETF网站并协助IESG工作。 它提供各种工具供社区和IESG使用。IETF秘书处根据合同为IASA工作, 而IASA的经费来自收取的参加面对面会议的费用。

2.2.7 IETF信托机构

快到2005年年底时,设立了IETF信托机构(IETF Trust)来持有并许可IETF的知识产权。 设立IETF信托机构的原因是必须有人持有知识产权,而且此人应是一个法律上可识别的稳定实体。 在任何特定时间,IETF受托人和IAOC成员都是同一批人。几乎没有IETF参与者和IETF信托机构发生接触。 这是一个好的现象,说明他们在安静地做自己的工作。 您可以在IETF信托机构的官方网站找到更多信息:http://trustee.ietf.org

2.3 IETF邮件列表

任何打算参加IETF会议的人都应加入IETF公告邮件列表 (参见https://www.ietf.org/mailman/listinfo/IETF-Announce)。 全部会议信息、RFC公告、IESG协议行动和最终审议都在这里发布。希望走“技术路线”的人也可加入IETF的综合讨论列表 (参见https://www.ietf.org/mailman/listinfo/ietf)。 这里会讨论一些重要话题(工作组有自己的邮件列表,以进行与自己工作相关的讨论)。 另一个邮件列表会随时公布刚发表的每个互联网草案的新版本 (参见https://www.ietf.org/mailman/listinfo/I-D-Announce)。

这些邮件列表和其他IETF管理的邮件列表的订阅由一个名为 "Mailman" 的程序处理。 Mailman可能会对订阅邮件的格式有点挑剔,有时不能很好兼容将所有电子邮件转化为HTML文件的电子邮件程序。 但是,如果您能以Mailman喜欢的方式设定邮件格式,它就会处理得很好。

IETF讨论列表不受监管。这意味着所有人都可以就影响互联网的问题发表意见。 但是,正如[BCP45]《IETF讨论列表章程》所述, 它并非公司或个人招揽生意或发布广告的场所。 在IETF讨论列表上发表之前,阅读完整的RFC(非常短!)是一个好主意。 事实上,列表确实有两位“纠察”,他们密切注视着不适当的内容,而且还有一个禁止屡教不改者在列表上发言的流程, 但幸运的是,这种情况非常罕见。

只有秘书处和少数IETF领导者能批准发布到公告列表的邮件,尽管这些邮件可能来自各种人士。

尽管IETF邮件列表大体上“代表”着IETF参与者,但请务必注意:参加IETF会议并不意味着您将被自动添加到任何一个邮件列表中。


3. IETF会议

会议、研讨会、展览会以及各种其他类型的会议在计算机行业很普遍。 但IETF的面对面会议却和这些会议截然不同。会议每年举办三次,是为期一周的“部落聚会”, 其主要目标是激励工作组完成自己的任务,次要目标是促进工作组和各领域之间一定程度的交流。 会议的开支由参会者和每次会议的主办公司(如果有的话)承担, 尽管IASA会为诸如一些工作组会议的音频广播之类的内容拨出额外资金。

对许多人来说,与标准计算机行业会议相比,IETF会议如同一股清新空气。 没有展览厅、极少辅导式讲座、没有鼎鼎有名的行业评论家。 相反,对参会者而言,在会议期间有大量的工作要做,还有相当多的社交活动时间。 IETF会议对销售和营销人士来说毫无意义,而却受到工程师和开发人员的高度关注。

IETF会议的一般流程从周日的辅导式讲座和非正式聚会开始, 在周一到周五召开工作组和BoF会议。每次工作组会议持续1到2.5小时, 有些工作组在一周中召开多次会议,这取决于他们预计要做的工作量。

在这一周的晚上会召开两次全体会议,一次是技术全会,一次是行政管理全会。 技术全会由IAB组织,通常邀请一到两个专家组谈论很多工作组和领域感兴趣的话题。 由IETF主席组织的行政管理全会涵盖诸如来自RFC编辑的进度报告和下次会议的公告等内容。 全体会议是和IESG以及IAOC进行分享的好时机。 赞美是受欢迎的,但更常见的是表达担忧和抱怨。

目前IETF在北美、欧洲和亚洲召开会议,大概每年在每个地区召开一次会议。 过去几届会议的参会人数约为1200人。到目前为止,已召开了80届IETF会议, 可以在IETF网页上查阅即将召开的会议列表: http://www.ietf.org/meeting/upcoming.html

参加IETF面对面会议的新人常常感到有些震惊。他们本以为这些会议和其他标准化组织的会议或计算机会议相似。 幸运的是,一两天后他们的震惊感就消失了,在会议期间得到的许多乐趣令很多新的参会者充满了活力。 另一方面,IETF人士有时候会令人吃惊的粗鲁,例如,当有人在话筒前发言时还大声说话, 或者推开人群去取食品或饮料。这类违反社会公德的行为似乎在IETF会议上比在计算机会议上更常见。

3.1 注册

要参加IETF会议,您必须注册登记并缴纳注册费。 会议地点和提前注册会在会议前大约两个月公布 — 如有可能会提前更多时间。 公告通过电子邮件发送到IETF公告邮件列表,相关信息于同一天在IETF网站http://www.ietf.org发布。

您可以在会议召开前在网上注册登记并付费,或者在会议召开时在现场报名。 要想获得注册费优惠,您必须在提前注册截止期限(会议开始前约一周)前付费。 注册费包括一周的所有会议、周日晚上的欢迎招待会(酒吧当场付现金)、每日欧式早餐、下午休息时的饮料和小吃。

注册在会议召开的那周仍然开放。但是,秘书处强烈建议参会者尽早到达进行注册, 注册通常在周日中午开始,一直持续到周日晚上的招待会。招待会是很受欢迎的活动, 您可以在这里品尝一点美食,和其他先期到达的参会者进行社交。

值得注意的是,参会者的姓名和地址以及IETF邮件列表在任何时候都不会被出售。

您在注册前,会看到一个名为“重要须知”的网页。您应真正地仔细阅读,因为它列出了IETF的知识产权规定。

如您需要给其他参会者留言,您可以在登记处附近的软木板上留言。这些软木板还会刊登最后一刻的会议和房间变更信息。

您还可以把失物招领物品交给登记处。会议结束时,失物招领处剩下的任何物品一般会交给酒店或者被带回到秘书处办公室。

此外,IETF登记处常是一个安排与人见面的方便地点。如果有人说“在登记处和我碰面”, 您应该弄清楚他们是指IETF登记处还是酒店的登记处。这是导致参会者错过和朋友碰面的一个常见原因。

3.2 决意冒险,整周参会!

IETF工作组会议从周一早晨一直安排到周五下午。相关的非工作组会议经常在之前或之后的周末召开。 最好计划参加整个星期的会议,以便能从工作组之间的交叉互动和走廊讨论中受益。 如下文所注,议程是不固定的,已经出现过许多参会者已安排好旅行计划, 但由于最后一刻的会议日程发生变化而错过重要会议的情况。整周都出席会议是避免这种烦恼发生的唯一途径。

如果您整周都找不到感兴趣的会议,您仍可以通过参加IETF的不同会议来充分利用这次机会。 大多数IETF参会者携带笔记本电脑,经常看到他们中的很多人在会议过程中在终端室或走廊上工作。 会场的很多地点常常有良好的无线网络覆盖(餐厅、咖啡厅等),因此不开会时查收电子邮件对IETF人士来说是相当常见的事情。

3.3 新人培训

鼓励新人参加周日下午举办的新手培训会,它是专门为首次参会者量身打造的。 培训由IETF教育团队组织实施,其目的是提供有用的入门信息。 内容包括胸牌上不同颜色圆点的含义、IETF的结构以及对IETF新人而言必不可少且有启发性的许多其他话题。

在下午晚些时候举行的是新人见面和问候活动,仅限新人和工作组主席参加。 这是您尝试发现自己感兴趣的领域内知识渊博者的绝佳场合。 您可以随意接近任何一位工作组主席,不仅限于您的领域, 以便了解他们的工作组或请他们帮忙找到您领域内的某个人。

3.4 着装规范

因为参会者必须佩戴胸牌,所以必须穿带领子的上衣。另外强烈建议穿长裤或半裙。 真的,很多身着西装的新人在周一早上参加会议时常常会尴尬地发现其他人都穿着T恤、牛仔裤(如果天气允许则是短裤)和凉鞋。 IETF内还有些人拒绝穿西装以外的任何服装。幸运的是,他们的知名度(由于其他原因)使人们原谅了他们这种特殊癖好。 着装的一般原则是“视天气而定”(除非您打算努力工作,足不出户,那么此时的原则是“穿着舒适”!)

3.5 工作组会议

IETF会议的核心是工作组会议本身。不同的工作组主席风格迥异,因此无法概括一个工作组会议会给人什么感觉。 尽管几乎所有工作组都有会议议程,有些会议严格按照议程进行,而有些则不那么严格。

在IETF会议中,有几件对所有工作组会议都很重要的事情。 在会议快要开始时,主席会发放“蓝纸”,它们是一些纸质表格,每个人在上面写下自己的姓名和电子邮件地址。 这些表格用于长期存档,以便显示有多少人参加了某个会议,在极少数情况下会显示都有哪些人参加。 正常的礼节是注意蓝纸从哪里传过来,然后沿着相同方向传递下去。

在会议上发言时,您应该总是走到房间的话筒前。对于有争议的话题,大家会在话筒前排队, 但如果您有问题要问或者能对讨论做出贡献,那么要毫不犹豫地第一个站到话筒前等待发言。 工作组主席或主持人会提示您何时可以发言。尽管您在自己的座位举手要容易一些,但话筒还是非常有用: 可以让远处的人听见,并让房间里的人听到您的提问或评论。 还希望您在话筒前说出自己姓名,以便做会议记录的人知道发言者是谁。

3.6 胸牌圆点含义

有些IETF成员的胸牌上会有一个彩色的小圆点。有些人的圆点不止一个。 这些圆点用来识别足够“愚蠢”以至于自愿承担许多额外工作的人。 颜色的含义如下所示。

颜色 含义
蓝色 工作组/BOF主席
绿色 东道主
红色 IAB成员
黄色 IESG成员
橙色 提名委员会成员
紫色 IAOC
粉红色 IRSG
蓝绿色 RSE

(媒体记者佩戴橙色胸卡。)

东道主能够回答有关终端室、餐厅和当地令人感兴趣地方等问题。

重要的是,IETF新人不应害怕和胸牌上有这些圆点的人开始交谈。 如果IAB和IESG成员以及工作组和BOF主席不想和任何人说话,他们从一开始就不会佩戴这些圆点。 但是要注意,AD通常在IETF会议上的时间都很紧张。 在IETF会议上和AD交谈的结果往往是被要求在两星期后再给他(她)发送电子邮件。 另外,当您开始和一位AD(甚至工作组主席)开始走廊谈话时,最好花30秒时间为他们介绍讨论的背景。

3.7 终端室

东道主所做的最重要的工作(这取决于您的观点)之一是为参会者提供互联网接入。 通常,所有会议室和多数公共区域的无线接入都很好,在终端室还提供有线接入。 贡献设备、服务和时间的人和公司会得到真诚的赞扬和感谢。

虽然鼓励尽早为会议做好所有准备,但仍可能无法避免出现一些在“最后一刻”才发现的问题, 那么这些问题可以利用终端室来解决。 对于需要趁脑海中的记忆还新鲜时撰写出差报告或状态报告的人,终端室也很有用。

您需要佩戴胸牌才能进入终端室。 终端室提供大量的电源插线板和笔记本以太网端口以及无线网络(为不需要以太网,但需要电源的人准备), 通常还有公用打印机,有时还配备工作站。注意终端室并不提供终端,这个名称是有历史典故的。 终端室内的帮助台是询问关于网络故障问题的好地方,虽然他们可能会让您去找其他网络工作人员。

3.8 美食小吃

Marshall Rose曾评论说,IETF是可以享用“很多美味午餐和晚餐”的地方。 尽管确实有人在IETF吃的很好,那是他们自己去找的美食;午餐和晚餐并未包含在注册费中。 秘书处安排周日晚上欢迎招待会(并无意用它代替晚餐)的开胃小吃、 周一至周五的欧式早餐(取决于会议地点)和一些下午休息时间的(最好的)饼干、布朗尼蛋糕、水果和其他美食。 这些费用常由会议东道主或会议赞助商支付。

如果您宁愿走出酒店用餐,东道主一般会提供距离会场不远的用餐地点列表。

3.9 社交活动

东道主组织和管理的另一件非常重要的事情是IETF社交活动。 社交活动有时是和高科技有关的,也可能是在艺术博物馆或接待厅举行的。 但要注意,并非所有IETF会议都有社交活动。

鼓励IETF新人参加社交活动。提倡所有人佩戴胸牌,把笔记本电脑留在酒店。 社交活动旨在让人们有机会在社交层面,而非技术层面会晤。

3.10 议程

IETF会议的议程是非常不固定的。议程信息可以在会议开始前几周从网站上获得。 登记处有小字号的议程可供索取,供那些想放在兜里留底或夹在胸牌后的视力好的人士使用,便于查阅。 当然,在IETF的“最终”这个词的含义和世界其他地方是不一样的。最终议程仅仅是发送到打印机的版本。 秘书处将在IETF登记处(不是酒店登记处)附近的公告牌上张贴变更的议程。 这些迟来的变更不是经常发生的:会议主席和发言人意识到不可预料的冲突时,会“及时”进行变更。 IETF变化不断,以至于无法提前几周敲定议程。

议程上还有指示会议室位置的地图。会议室分配也会随着议程变化而变化。 有些工作组在会议期间会开几次会,一个工作组的不同时间会议会尽量安排在同一会议室召开。

3.11 EDU前来支援

如果IETF的某个方面仍让您感到迷惑(即使您已经阅读完《IETF之道》), 那么您可以参加由教育(EDU)团队提供的现场培训。 这些非正式课程专为新人设计,同时也适用于资深的IETF人士。 除了新人培训,EDU团队还为文档编辑和工作组主席提供研讨会, 另外还有对新人和IETF长期参会者必不可少的有一定深度的安全技术讲座。 EDU会议一般在周日下午举行。 您可以在以下网站获得更多关于EDU的信息:http://www.ietf.org/edu/

3.12 哪里适合我?

IETF会议对不同的人有不同的意义。有许多在IETF非常活跃的人却从未参加过IETF会议。 因此,您不必为感受IETF气氛而来参加会议。 以下准则(基于对不同行业人员的成见)也许能帮助您做出是否真的希望参会的决定, 如果希望参会,那么就利用好您首次参会的时间。

3.12.1 信息系统经理

如本文所述,IETF会议不同于您参加过的任何贸易展览。 如果您参加IETF会议的目的是找到下一年度互联网行业的热点,那您会非常失望。 可以肯定,参加工作组的会议只会使您对业界动态产生更多的迷惑, 而不是帮助您了解行业中正在发生什么或将要发生什么。

但这并不是说产业界的人士不应该参加IETF会议。作为信息系统经理, 您可能希望考虑派遣负责和IETF正在开发的技术相关的专人参加会议。 当这些人阅读当前互联网草案和相关工作组列表上的信息时, 他们会意识到他们的出席对贵公司或工作组来说是否值得。

3.12.2 网络运营商和互联网服务提供商

即便不必应付新协议或那些已经使用协议的更新版本,运营网络本身也是一项繁重的任务。 如果您负责的网络一直使用最新的软件和硬件,或者您还利用大量业余时间关注相关工作组的话, 您一定会发现参加IETF会议是有价值的。 相当数量的IETF工作涵盖了ISP和大型企业运营中的很多其他方面, 因此运营商的意见对保持这一工作的活力和相关性很有价值。 许多IETF的最佳运营文档都来自现实生活中的运营商,而非设备厂商和学术界。

3.12.3 网络硬件和软件供应商

过去一直认为IETF会议的印象基本上是象牙塔里的学术会议,,但是现设备在的参会者基本都来自业界。 IETF的大多数领域里,主导协议撰写和领导工作组的人都受雇于设备厂商,所以设备厂商参加IETF是非常合适的。 如果贵公司生产网络硬件或软件,但还没有派人参加过IETF会议,那么仅仅为了告诉他人贵公司和会议是否相关,您也应该来参会。

这并不是说让公司在IETF会议期间停止营业来让每个人都参加会议。 如果贵公司有几位技术人员来参会,那么一般就最好不要派营销人员,甚至技术营销人员来IETF了。 同样,也不需要技术部门的所有人都来参会, 如果他们根本不阅读互联网草案也不关注工作组邮件列表讨论,则更没有必要参会。 许多公司仅指派几名专人参加会议,选拔他们参会是因为他们有能力撰写完整、有用的出差报告。 此外,许多公司有内部协调工作和标准策略。如果一家公司的部分或全部业务依赖于互联网,那么其战略应该包括IETF。

3.12.4 专业学者

对于计算机科学研究者来说,IETF会议常常是一个理想去处,他们能在这里发现即将要部署协议的最新情况。 通过在特定领域关注他们感兴趣的工作组,从事网络或通信研究的教授和研究生(有时也有本科高才生)可以在IETF获得非常丰富的信息。 信步走进不同工作组的会议室,和在自己学校院系里听专题讲座和研讨会具有同样的效果。研究人员当然也可能会对IRTF活动产生兴趣。

3.12.5 计算机行业媒体

如果您是媒体记者并考虑参加IETF会议,我们已在《IETF之道》中为您专门编写了一个特别章节 ; 请参见Section 8.2

3.13 会议纪要

IETF的会议纪要会在每场会议结束后两个月整理出来,并在网上发布。 请一定要阅读一遍; 因为会议纪要中有许多您可能在别处无法找到的IETF相关信息。 例如,您能在会议期间找到大多数工作组的章程概述,它们使您能够更好地了解任何工作的发展过程。

会议纪要有时以一段详实的(并且富有趣味性的)信息开始。 每一卷都包括会议最终(后见之明)议程、IETF概述、领域和工作组报告,以及协议和技术演示幻灯片。 工作组报告和演示幻灯片有时可能不完整,这是由于资料没有及时上交给秘书处发表而造成的。

资料里也包括一份参会者名单,上面有注册登记表上提供的姓名和所属组织。 要了解有关获得会议纪要的信息,请参见网络列表:http://www.ietf.org/meeting/proceedings.html

3.14 其他常见事项

IETF人士一般都非常平易近人。不要害怕与人接触并介绍您自己。 也不要害怕提问题,特别是当您遇到不熟悉的术语和缩略词时。

走廊上的交谈很重要。很多优秀的工作都是由人们在会议间歇,午餐及晚餐时相互交流来完成的。 IETF的每一分钟都能被认为是工作时间(这让有些人很沮丧)。

小会议(历史上常被不准确地称为“吧台BOF”)是一种非官方的聚会,通常在工作组会议间歇期间或深夜进行, 很多工作都在这种场合完成。这些小会议通常在IETF会场周围的不同地点, 例如餐馆、咖啡馆、未使用的礼堂以及泳池(如果我们运气够好的话)举行。

不管走廊上的谈话多么有趣,打扰一位饥肠辘辘的IETF人士享用茶歇时的布朗尼蛋糕和曲奇饼都是不明智的。 首任IETF执行主管Steve Coya常说“拿上您的饼干,然后从桌子旁走开。”

IETF人士有很强的独立精神。您可以质疑观点或者给出替代方案,但不要指望IETF人士服从您的命令。

IETF会议,尤其是全体会议,不是供应商推销产品的地方。当然人们可以回答关于他们公司和产品的问题, 但请记住IETF会议不是展览会。这并不影响人们销售和IETF有关的T恤、纽扣和口袋保护袋以收回成本。

在登记处旁一直有一个“资料分发台”。 用于放置一些合适的资料供参会者取用(例如,工作组会议上所讨论问题的副本、网上有关IETF信息的描述)。 请事先联系秘书处,然后再在资料分发台上放置您的资料;秘书处有权撤走他们认为不合适的资料。

如果您在会议期间依赖您的笔记本电脑,最好带上备用电池。 在一些会议室,您并不是总能找到空闲的电源插座,而连续使用无线接入对电量的消耗比您预想的要快。 如果您在会议室的座位靠近电源插座,要做好为周围的人插拔电源的准备。 许多人还自带接线板,这是您在会议上和邻座交朋友的好办法。如果您需要电源插头适配器,应该事先买好, 因为您需要的插头适配器一般在自己的国家更容易买到。


4. 工作组

大量IETF工作是由众多工作组完成的;在撰写本文时,有大约115个不同的工作组。 [BCP25]《IETF工作组准则和程序》对于任何一位参与工作组讨论的人来说, 是一个非常好的参考资源。

一个工作组其实只是一个有少许成年人监督的邮件列表。您通过订阅邮件列表“加入”工作组。 所有邮件列表都对任何人开放。任何人都能在工作组邮件列表上发布信息, 虽然大多数邮件列表要求非订阅者对其所发布的信息进行编辑。 每个工作组有一到两位(很罕见的情况下有三位)主席。

更重要的是,每个工作组都有自己要遵守的章程。章程规定该工作组的讨论范围和目标。 工作组的邮件列表和面对面会议应严格遵循其章程运作,不应讨论其他与自己主题无关的“有趣”话题。 当然,看看一些工作组范围外的东西偶尔也是有益的,但大多数讨论必须围绕章程中列出的主题进行。 事实上,一些工作组的章程规定了工作组不予讨论的主题,尤其是在起草章程的过程中出现的一些有吸引力但模糊不清的主题。 不同工作组的章程对于那些希望了解各工作组的人们来说是一份有趣的读物。

4.1 工作组主席

对工作组主席角色的描述请参见[BCP11][BCP25]

作为自愿的“牧猫人”,工作组主席的首要任务是为工作组确定共识目标和里程碑,随时更新章程。 其次,通常在工作组秘书和文档编辑的帮助下,工作组主席必须管理工作组的讨论,包括在邮件列表上的讨论以及适当时候安排会议进行的讨论。 讨论有时会在某些争议点陷入僵局,工作组主席需要引导人们进行有成效的交流互动,并在达成大致共识时宣布讨论结束。 有时工作组主席还需要管理与非工作组参与者或IESG的互动交流,尤其是当工作组文档即将发表时。 工作组主席对工作组成果的技术性和非技术性质量负责。可以想象,考虑到各种行政、人际关系和技术需求,有些工作组的主席会比其他工作组主席胜任得多。

强烈建议工作组主席参加工作组领导力培训,通常在IETF会议前的周日举行。 通常在会议期间周三前后还会有工作组主席午餐会,会在此时提出一些与工作组主席有关的话题并进行讨论。 如果您对他们讨论的内容感兴趣,请观看幻灯片:http://edu.ietf.org

4.2 在工作组内完成工作

令新参会者感到疑惑的一件事情是,为什么IETF工作组的面对面会议不如其他组织中的面对面会议那样重要。 任何在面对面会议上做出的决定还必须在工作组邮件列表上达成共识。 有很多实例证明,在工作组会议上做出的重要决定随后在邮件列表上被否决, 常常是因为某个未出席会议的工作组成员指出了在形成该决策中逻辑上存在重大失误。 最后,工作组会议并非“修改草案的会议”,这和其他标准化组织不同:在IETF,修改草案工作在其他地方完成。

另一个使很多人感到迷惑的问题是工作组不进行正式投票表决。 处理有争议话题的一般规则是工作组必须达成“大致共识”,意思是关注此问题的绝大多数人必须达成一致。 每个工作组确定“大致共识”的确切方法各不相同。 有时共识是由“嗯”声大小来决定 ; 如果您同意该提案的话,当主席提示时您就嗯一声。 大多数“嗯”问题都分两个部分:如果您同意提案,就对第一部分嗯一声,如果您不同意,就对第二部分嗯一声。 新人会觉得这种方式很奇特,但很有效。由主席决定工作组何时达成了大致共识。

没有正式投票导致有些提案被耽搁了很长时间。 但大多数经历措辞尖刻的辩论后, 看到达成大致共识的IETF参与者都认为这样的耽搁往往能形成更好的协议。 (试想,您如何能在一个任何感兴趣的人都能加入并且无法确定人数的小组里投票呢?) 有多种方法来定义“大致共识”。一个简单的版本是: 强烈反对的意见必须经过辩论,直到大多数人都确信这些反对意见是错误的为止。

一个相关问题是有些人认为他们的提案应该在工作组讨论,即使工作组主席不这么认为。 例如,如果建议的工作确实不属于工作组章程范畴,那么工作组主席可以限制对该议题的讨论, 以使工作组专注于章程规定的工作。如果有人认为工作组应该讨论一个话题, 而主席认为该话题超出工作组章程的范围,那么可将他们关注的这个问题提交给相应的AD, AD或许同意将此话题加入到工作组的章程,或者他认为该话题已被现有工作组章程覆盖, 或者他同意工作组主席的看法 — 参与者应该在此工作组之外讨论该提案。

一个工作组文档经过充分讨论后,通常会经历工作组最终审议阶段(常缩写为 "WGLC")。这有望成为工作组解决问题的最后时间。 有时,WGLC将提出如此多的问题,以至于修订被纳入草案后还需进行第二个WGLC。 关于WGLC的启动没有正式规则,如果需要一个WGLC,工作组主席就可做决定。

有些工作组采用的方式是,指定一名工作组“秘书”来处理文档和相应的更改。 如果有问题跟踪器,秘书可以使用它,或者只需负责关注邮件列表上做出的所有决定, 使其在文档的较新版本中得到体现。

当一个工作组实现了其章程规定的使命时,就应该停止相关工作。 (但多数工作组的邮件列表会在工作组撤消后继续运作,仍然讨论原工作组的相同主题。) 在IETF,工作组因为完成其使命而关闭是一个成功的标志。这是曾接触过其他标准化组织的新人所不能理解的IETF的一个方面。 然而,有些工作组主席从未设法使其工作组结束,或是不断向章程里添加新任务,致使工作组延续了许多年(或者在少数情况下长达数十年)。 这些高龄工作组的后期成果往往没有他们早期做的好,这些杂乱的结果有时被归因于所谓的“工作组退化综合症”。

4.3 工作组文档

工作组草案和独立草案是有正式区别,但实际上,二者在操作程序上没有太大差别。 例如,许多工作组邮件列表也讨论独立草案(由工作组主席自行决定)。 工作组主席要决定哪些草案可以成为工作组草案以及这些草案的作者或编辑将是谁。 此决定往往在和工作组磋商的基础上做出,有时还需要和AD进行磋商。 当许多人想成为草案作者时,这个过程会变得非常棘手,或者当工作组为了做某项具体工作而建立,却没人愿意做草案作者时,事情也会变得同样棘手。 有关互联网草案程序的细节在本文档后文中会详细阐述。

有些工作组有非常复杂的文档或一套复杂的文档(或者两者兼有)。 从一个或多个复杂的文档中去除所有错误是一项令人望而生畏的任务。 为帮助解决这个问题,有些工作组使用“问题跟踪器”,这是针对文档中未决问题、问题状态、修改建议等内容的在线列表。 使用问题跟踪器不但能帮助工作组不遗漏重要工作,还可帮助解答某些人事后的问题:为什么某项工作会以一种特定的方式完成。

对于工作组文档,文档编辑的工作需要让工作组主席满意。常常有不止一位编辑负责工作组文档,尤其是复杂的文档。 非文档编辑的职责是保证文档的内容准确地反映工作组决定,尤其是在创建新协议或扩充一个协议的情况下; 如果文档编辑不遵从工作组的共识,工作组主席要么会更加强有力地要求进行修改,使文档符合共识, 要么让更能响应工作组要求的人取代该文档编辑。随着工作组文档的进展,参与者在工作组邮件列表上提出修改意见; 文档编辑应关注讨论并在达成一致意见时修改文档。

如果一个参与者做出了重要的贡献,编辑或主席可以邀请该参与者成为合著者或合编者, 但这须经过工作组主席的同意。在选择某个互联网草案作为工作组文档前, 工作组有时会考虑几个备选文档。工作组常常从多个备选方案中采纳观点,然后形成一个工作组文档; 在这种情况下,由主席决定谁将被列为标题页上的作者,谁将在正文中被作为供稿人获得鸣谢。

当工作组文档的进展将超出工作组的范围时,工作组主席将指派一个“牧羊人”来接管最后流程。 文档牧羊人的角色描述见[RFC4858]

4.4 准备参与工作组会议

每个人(新人和资深专家)在参加面对面会议之前应该做的最重要的一件事情是事先阅读互联网草案和RFC。 工作组会议明确不是进行教育培训:它们的目的是制定工作组文档。 即使您不打算在会议上发言,您也应该在参加会议前阅读,或至少翻阅工作组文档,以便您能理解所讨论的内容。

工作组主席负责安排会议议程,通常是提前几周安排。 如果您希望在会议上讨论什么内容,一定要让主席知道。 所有工作组会议的议程均可提前在IETF网站上查阅,但有的工作组主席可能在提交议程方面 比较松懈(如果不是完全疏忽的话)。

秘书处只提前几周安排工作组会议,而会议日程安排常常会在会议开始一周前临时发生变动。 如果您只参加一个工作组会议,您在接到这样的临时通知时要预订航班会很困难,尤其是工作组会议的日程发生变动。 务必随时掌握最新的日程安排,以便您自己能安排好航班和酒店。 但说到底,您可能不应该只来参加一个工作组会议。 假设您已经阅读了几个工作组的草案和RFC,您的知识可能在几个工作组会议上都很有价值。

如果您被列入面对面会议的议程中,您可能应该准备几张幻灯片。但不要带着辅导式的演讲来; 参会者应该都事先阅读了草案。所有会议室均提供笔记本电脑演示所用的投影机。

下面是有关您在工作组或全体会议演示时使用幻灯片的一些提示:请勿在每张幻灯片上都放上贵公司的标识,即便这是除IETF之外会议的惯例。 IETF对这种企业广告感到不悦(全体会议演示时的会议赞助商除外),而且大多数演示人甚至在第一张幻灯片上都没有放自己公司的标识。 IETF是关于技术内容的,而非公司推广。幻灯片常常黑白即可,以易于辨认,只在真正增加易读性时才使用彩色。 再次重申,内容是幻灯片的最重要部分,而不是演示的方式。

在工作组会议期间,您会觉得有用、甚至可能有趣的一件事情是是关注该工作组相关Jabber聊天室中的现场连续评述。 现场连续评述常常用作会议记录的依据,但也会包括笑话、叹息以及其他无关的唠叨。 Jabber是一种免费的流式XML技术,主要用于即时通讯。 您可以在以下网址找到许多平台Jabber客户端的链接:http://xmpp.org/xmpp-software/。 Jabber聊天室有工作组的名称,后面添加了 "@jabber.ietf.org"。 实际上,这些聊天室全年可用,并非只限于IETF会议期间,有些聊天室在制定协议期间被活跃的工作组参与者使用。

4.5 工作组邮件列表

如前所述,IETF公告和讨论邮件列表是IETF活动的主要邮件列表。 不过,也有许多其他和IETF工作有关的邮件列表。例如,每个工作组都有自己的讨论列表。 此外,还有一些长期性的技术辩论从IETF列表中转入相关主题的专门列表。 我们强烈建议您关注自己要参加的工作组的邮件列表上的讨论内容。您在邮件列表上花的功夫越多,您在会议中所需完成的工作就越少, 从而有时间进行交叉互动(即参加自己感兴趣的主要领域以外的工作组,以拓展自己的视野)。

邮件列表还为那些希望关注工作组工作或为之献计献策但无法参加IETF会议的人提供了一个论坛。 正因为如此,IETF程序要求所有决定都要“在列表上”确认,您会经常性地听到工作组主席说“让我们把它列在列表上”而结束讨论。

许多IETF讨论列表使用Mailman或另一个列表管理器Majordomo。 它们通常有一个 "-request" 地址,用来处理加入和退出列表的管理细节。 (参见Section 2.3以了解有关Mailman的更多信息。) 当这样的行政处理事项出现在讨论邮件列表中时,人们通常会皱眉。

IETF讨论列表将存档。也就是说,所有发送到列表的邮件都会自动存储在主机上,供匿名的HTTP或FTP访问。 许多此类存档都列在以下网站:ftp://ftp.ietf.org/ietf-mail-archive, 或放在基于网络的档案库中。如果您找不到所需列表,可发送邮件到列表的 "-request" 地址(不要发给列表本身!)。 工作组章程列表http://datatracker.ietf.org/wg是一个有实用价值的信息来源。 http://www.ietf.org/wg/concluded是较旧的、已结束的工作组列表。

有的工作组列表对邮件大小有限制,特别是为了避免较大的文档或演示稿被发送到每个人的邮箱中。 值得记住的是,参与者并不是都有宽带连接(甚至有宽带连接的人在外出旅行时也通过较慢的连接收取邮件),因此简短的邮件很受欢迎。 文档可作为互联网草案发布;演示材料可发布到发件人控制的网站上,或直接发送给索取材料的人。 有些工作组建有专门的网站来保存这些大文档,发件人可先在专门网站上发表,然后只发送文档的链接网址到列表中。

4.6 临时工作组会议

工作组有时会在IETF会议之间举行临时性会议。临时会议并不取代IETF会议 ; 然而工作组不能决定不在他们不喜欢的地方举行会议, 而是三周后在坎昆(或甚至一些不起眼的地方)开会(只是举个例子)。临时会议需要获得AD批准并需要至少提前一个月公告。 会议地点和时间需要对所有参与者都是公平的。如同定期举行的IETF会议一样,需要有人做记录,工作组需要点名。 在临时性工作组会议上做出的暂时性决定仍需要在邮件列表上获得批准。

近年来,一些工作组开始举行“虚拟临时会议”,通过电话和/或网络进行,而不是面对面。 虚拟临时会议非常有用,可让工作组在定期IETF面对面会议之间关注自己的工作, 而且参加会议的成本远远低于面对面的临时会议。虚拟临时会议的报告要求与面对面的临时会议相同。

IESG制定了临时工作组会议时间和地点的提前通知规则,以及报告会议结果的规则。 这些规则的目的是确保临时会议能够让尽可能多的工作组成员参加,并保持工作组流程的透明度。


5. 专题讨论会BOF

为了组建工作组,您需要有一个章程以及能够胜任主席一职的人选。 为此,您需要让大家感兴趣,以便他们能够帮助您确定章程并说服AD,让他相信此项目是值得做的。 面对面会议有助于实现这一目的。事实上,很少有工作组是由AD组建的; 大多数工作组是在面对面BOF会议后成立的,因为参会者对相关话题表示有兴趣。

BOF 会议必须先获得相关领域的AD批准才能安排。 如果您认为自己真的需要一个新的工作组,请非正式地接触AD并出示您的计划书,看看他或她的想法。 下一步是请求在下一次面对面会议上安排一个会议时段。在会议召开时在现场报名。 当然,您不必等待会议召开就可以先行做一些工作,如设置邮件列表,开始讨论章程之类。

BOF会议的风格与工作组会议截然不同。BOF会议的目的是确保能够创建好的章程,并有好的里程碑, 有足够的人手愿意去做创建标准所需的工作。有的BOF已经着手准备互联网草案,而其他的则需从零开始。

在BOF之前就有草案的优势是有助于讨论有的放矢。 另一方面,有了草案往往会限制BOF中的其他人希望在章程中做的工作。 务必记住:大多数BOF会议举行的目的是为了获得支持以最终成立工作组,而不是获得对某个文档的支持。

许多BOF都不会转化为工作组,有各种各样的原因。一个常见问题是没有足够的人就工作重点达成一致。 另一个典型原因是工作最终不能成为标准; 例如,文档作者并不真正想把变更控制权交给工作组。 (我们将在本文档后面讨论变更控制权。)一个特定主题只能安排两次BOF会议;或是成立工作组,或是放弃该主题。


6. RFC和互联网草案

如果您是新的IETF参与者并正在寻找某个RFC或互联网草案, 请访问RFC编辑的网页:http://www.rfc-editor.org/rfc.html。 该网站上也有其他RFC文集的链接,其中许多RFC都有搜索功能。 如果您知道自己要找的RFC的编号,请访问RFC编辑的RFC网页:http://www.rfc-editor.org/rfc.html。 对于互联网草案来说,最好的资源是IETF网站:https://datatracker.ietf.org/doc, 在这里您可以按标题和关键词进行搜索。

6.1 如何发表RFC

资深IETF参与者最经常听到新人提出的一个问题是“我如何发表IETF标准?”而更好的问法是“我是否应该撰写IETF标准?” 因为答案并不总是为“是”。如果您的确决定要撰写将成为IETF标准的文档,请注意整个过程可能是相当繁琐的,即使每个步骤看上去都很简单明了。 但也有很多人顺利完成这个过程,而且也有许多书面指导可帮助作者完成这一过程,同时不会挫伤他们的自信。

您必须决定的首要事情之一是您是否希望您的文档在工作组中加以考虑,或者您是否希望它被视为提交给IETF的个人(非工作组)文档。 即使大多数的IETF标准来自工作组,但有的却是个人努力的成果: 可能没有适合的工作组,或者可能适合的工作组太忙于其他工作而无法考虑您的想法。

每个IETF标准都作为RFC(“请求建议”)发表,每个RFC都开始于互联网草案(常称为 "I-D" 或“草案”)。 将文档作为IETF标准发表的基本步骤如下:

  1. 将文档发表为互联网草案。
  2. 接收有关草案的建议。
  3. 根据建议对您的草案进行编辑。
  4. 将步骤1至3重复几次。
  5. 请AD将草案带到IESG(如果是个人提交的文档)。如果草案是工作组的正式成果,由工作组主席请AD将草案带到IESG。
  6. 如果领域指导接受所提交的文档,他们会进行自己的初步审查,可能会要求您更新后再采取下一步骤。
  7. 获得更多IETF会员的审查。特别是IETF中的一些领域已组建审查团队来审阅准备提交给IESG的草案。 其中两个最活跃的审查团队来自安全委员会 ("SecDir") 和总体领域审查团队 (Gen-Art)。 请注意所有这些审查都有助于提高最终RFC的质量。
  8. 与IESG会员讨论问题。他们的问题可通过简单的回答加以解决,或者需要对文档进行添加或变更内容。
  9. 等待RFC编辑发表文档。

有关上述步骤的更全面说明可参见[BCP9]《互联网标准流程》。 撰写草案并希望草案成为IETF标准的人必须阅读BCP 9,以便能够跟进其文档在整个过程中的进展情况。 您可以在IETF Datatracker上跟踪文档进展情况,网址为http://datatracker.ietf.org。 BCP 9(以及对它进行更新的各种其他文档)对常常被人误解、甚至是被资深IETF参与者误解的话题进行详细论述: 不同类型的RFC将经历不同的流程并有不同的排名。有六种RFC:

只有前面两种标准(建议的标准和完全标准)属于IETF内的标准。 在题为《并非所有RFC都是标准》[RFC1796]的文档中可找到相关摘要。

还有两个子系列的RFC,分别称为BCP和STD。当前最佳实践文档描述互联网中各种技术的应用,也经常用来记录IETF流程中的诸多部分。 FYI子系列由上面所列的“信息性文档”组成,并采用了特殊标签。(还有一个“仅供参考”RFC子系列,其目的是记录概述和介绍性的话题, 或对广泛受众有吸引力的话题;不过,该系列已经正式关闭。)

STD RFC子系列的目的是确定事实上规定互联网标准的RFC。有些STD实际上是一个以上RFC的集合,而“标准”这一命名适用于整套文档。

6.2 优雅放手

有的人不希望自己的文档被纳入IETF标准系列,其最大的原因是他们必须放弃对协议的变更控制权。 也就是说,一旦您提议您的协议成为IETF标准,您必须完全放弃协议的控制权。如果达成共识,协议的某些部分可能被完全更改、 整个章节被删除、添加全新的内容,甚至名称也可能被更改。

有的作者觉得很难放弃对自己所钟爱的协议的控制权。 如果您属于这类人,想都不要想把您的协议变成IETF标准。 另一方面,如果您的目标是制定最好的标准并得到广泛的实现,那么您可能会喜欢上IETF流程。

此外,互联网标准的变更控制权并不在协议被接受为标准系列时结束。 协议本身在以后也可能因各种原因而被更改,其中最常见的原因是实施者在实施标准时发现了问题。 这些后来发生的变更也处于IETF控制之下,而不是标准文档编辑的控制之下。

IETF标准存在的目的是人们可以用它们来编写可以互操作的互联网程序, 并不是为了记载作者的想法(可能是极好的想法),也不是为了让某个公司吹嘘说“我们有一个IETF标准。” 如果一个标准系列RFC只有一个实现(一般要求必须有两个实现才能成为标准系列),那么从一开始把它做成标准系列就是一个错误。

注意,新作者不能把其他人的文档当作自己的文档提交,参见[BCP78]第5.6节第 (a) 条。

6.3 互联网草案

要紧的事先做。最后进入RFC存储库的每个文档刚开始时都是互联网草案。 互联网草案是临时性文档 ; 它们的目的是让读者提出建议,以便作者能够仔细考虑这些建议,然后决定在草案中采纳哪些建议。 为了提醒人们互联网草案的临时性,互联网草案在六个月后自动从在线活动目录中删除。它们绝非标准。如[BCP9]所说:

“互联网草案不是‘发表”某一规范的手段;规范是通过RFC机制发表的....互联网草案没有正式地位,可随时变更或删除。 在任何情况下,任何论文、报告或征求建议书均不得引用互联网草案,任何供应商也不得声称自己符合互联网草案的规定。”

当有人不了解IETF(或故意想欺骗他人)却又在吹嘘自己发表了互联网草案时,您总是能够分辨出来;毫不费力。

提交互联网草案后,您把部分发表权交给了IETF,以便您的互联网草案能够免费提供给希望阅读并提出建议的每个人看。 有关您转让和未转让给IETF的权利,请参阅[BCP78] 《IETF贡献者的权利》。

在以下网址有一个非常有用的检查工具:http://tools.ietf.org/tools/idnits。 在提交互联网草案前使用这个工具,有助于避免您的互联网草案因形式和格式错误而被拒收。

I-D的格式应该和RFC差不多。与许多人的看法不同的是,I-D的格式和RFC的格式几乎完全一致, 但如果您在创建I-D时使用与RFC编辑所用格式相同的格式,这在您的草案发表为RFC时会简化RFC编辑的工作。 [RFC2223]《RFC作者说明》描述了提交格式。 还有一个叫做 "xml2rfc" 的工具,可从http://xml.resource.org下载, 它能把XML格式的文本转换为有效的互联网草案。

互联网草案可能是工作组草案,也可以是个人提交的文档。 工作组草案通常由工作组审查后再接受为工作组文档,虽然最终决定由主席做出。

如果您对某个草案的状态感兴趣,或者记不清楚它的确切名称,或者希望查明工作组正在讨论的是哪些草案,有两个实用工具可用。 以下网址的“互联网草案数据库界面”:https://datatracker.ietf.org/doc, 能够让您按作者、工作组、日期或文件名进行搜索。这在作者希望跟踪掌握自己的草案在发表过程中的进展情况时很有用。

互联网草案命名有一些非正式规则,这是多年来形成的规则。 对现有RFC进行修订而形成的互联网草案常常在其名称中带有 "bis",意味着“再次”或“两次”; 例如,一个草案可命名为 "draft-someone-rfc2345bis-00.txt"。

6.3.1 作者建议读物

在创建您的互联网草案第一稿之前,您应该阅读四个文档:

同时,您还应该浏览IETF工具网页:http://tools.ietf.org, 在这里您将找到可将您的IETF工作自动化的其他工具链接。

6.3.2 文件名和其他事项

在您准备提交互联网草案时,请提交到http://datatracker.ietf.org/submit。 网页上的说明将引导您完成必要的步骤,还提供了一个电子邮件地址,可在您需要时提供个性化的帮助。

在提交草案的第一版本时,您还要把您提议的草案文件名告诉草案管理员。 如果草案是正式的工作组成果,文件名将以 "draft-ietf-"开头,随后是工作组的名称,再后面是一两个描述性单词, 最后为 "00.txt"。

例如,S/MIME工作组有关创建密钥的草案可命名为"draft-ietf-smime-keying-00.txt"。 如果不是工作组的成果,文件名可以 "draft-" 和其中一位作者的姓氏开头,随后是一两个描述性单词,最后是 "00.txt"。 例如,由Smith撰写的草案可命名为 "draft-smith-keying-00.txt"。如果草案是个人提交的文档,但与某个工作组相关, 作者有时会在自己的姓名后面加上工作组的名称,如 "draft-smith-smime-keying-00.txt"。 如果您遵循以下网址http://www.ietf.org/ietf/1id-guidelines.txt的命名准则, 您建议的文件名很可能被接受。

草案第一版后,文件名中的编号将递增;例如,上述的S/MIME草案第二版将命名为 "draft-ietf-smime-keying-01.txt"。 注意存在文件名在一个或多个版本后发生变化的情况,例如当个人文档被升级为工作组成果时; 草案的文件名变更时,编号恢复为 -00。 在出现此类名称改变时,工作组主席将告知互联网草案管理员草案以前的名称,这样数据库才能准确无误。

6.4 标准系列RFC

创建并推进标准的程序可参见[BCP9]。在互联网草案经过充分讨论大致达成共识, 表示草案内容可以成为有用的标准时,就会呈交给IESG考虑。 如果草案是正式的工作组草案,工作组主席将把它发给相应的AD。 如果草案是个人提交的文档,草案的作者或编辑将把它提交给相应的AD。 如果有人觉得工作组主席、AD或IESG在考虑标准的创建或推进时做出了错误的决定,BCP 9还描述了相应的上诉流程。

在I-D提交给IESG后,IESG将在整个IETF范围内宣布最终审议(常常简称为 "LC")。 这有助于获得没有一直跟进草案进展,但有时能对草案进行进一步变更的人们的注意。 这也是工作组中的人在觉得自己的意见没有受到重视后,能够把自己的意见告诉大家的时候。 IETF最终审议期限对工作组草案至少是两周,对个人提交的文档至少是四周。

IETF最终审议的目的是在IESG考虑之前,让全社区对文档进行讨论。注意这里的“讨论”一词。 就您没有阅读过的文档发送IETF最终审议建议,或者发送了建议但不打算讨论您的观点,通常都被视为不合礼貌的举止。 IETF最终审议并非投票表决,旨在让人们对某一文档提出支持或反对的活动通常会适得其反。 话虽如此,由首次阅读文档的人提供的IETF最终审议建议能够暴露出IETF和工作组例行审查可能完全遗漏的问题。 正因为如此,讨论对所有人开放。

如果IESG批准草案成为标准系列RFC,他们会请RFC编辑将其发表为提议标准。此时通常会发生几件事情。 首先,常见的是标准中的一些规范需要改变措辞,因为一个实现者会认为它们是这个意思,而另一个实现者会认为它们是那个意思。 另一个常见现象是没有实现者实际上会尝试实现标准的一些功能;这些功能被删除的原因不只是没有人对其进行测试,还因为它们是不必要的。

如果某个标准没有从提议标准变为互联网标准,请不必惊讶。 要成为互联网标准,RFC必须有多个可互操作的实现,并且提议标准中未使用的功能必须删除。 在以下网址列有额外的要求:[BCP9]。常用的大多数标准都是提议标准,从未向前发展。 这可能是因为没有人抽出时间来尝试把它们变成互联网标准,或者标准中的规范性引用文件仍然是提议标准, 或者可能因为大家都有更重要的事情要做。

6.4.1 实话实说 — MUST、SHOULD和MAY的使用

撰写规范并如您所愿地得到实现是一门艺术。您可以使规范非常简短,只列出一个要求清单, 但这往往导致实现者有太多的回旋余地。相反,如果您使规范非常冗长,包括无数的建议, 实现者往往会漏掉要求(并常常不同意您的建议)。最好的规范是介于两者之间的。

使开发人员更有可能创建标准的可互操作实施的一个方法是要阐明规范中哪些是要强制执行的。 早期的RFC使用各种表达方式来解释需要的是什么,因此实现者并不总是知道哪些部分是建议,哪些部分是要求。 最终,IETF中的标准撰写者决定将自己的措辞限于具有几个特定含义的几个特定词汇。

[STD3]《互联网主机要求 -- 应用程序和支持》撰写于1989年, 有一个简短的词汇清单,看上去很有用,即“必须”(must)、“应该”(should) 以及“可能”(may)。 这些定义在[BCP14]《RFC中用来表明要求级别的关键词》中得到更新和进一步完善, 此文档在当前互联网标准中得到广泛引用。 BCP 14还明确定义了“不可以”(must not)和“不应该”(should not),并列出了所列词汇的几个同义词。

在标准中,为了让人清楚您使用的是BCP 14中的定义,您应该做两件事情。 首先,提及BCP 14(虽然大多数人把它称为RFC 2119,因为这正是BCP 14要您这么做的),以便读者知道您如何定义所使用的词汇。 其次,您应该指出您所用的哪些词汇实例源自BCP 14。这方面的习惯作法是使用大写单词。 正因为如此,您才会在IETF标准中看到大写的 "MUST" 和 "SHOULD"。

BCP 14是一份简短的文档,阅读或撰写IETF标准的每个人都应该阅读此文档。 虽然 "must" 和 "must not" 的定义相当清楚,但 "should" 和 "should not" 的定义却在许多工作组中引起了大量讨论。 在审查互联网草案时,常常提到的一个问题是:“句子中应该包含MUST或SHOULD吗?” 这个问题的确问得好,因为规范不应该有无端的MUST,但也不应该为了互操作性在需要用MUST的地方使用SHOULD。 这就造成了在标准中过度指定要求和对要求指定不足的难题。

6.4.2 标准中的规范性引用

撰写IETF标准时,令许多新手(以及相当多的资深IETF人士)犯错的一个方面是关于在标准中如何“规范性引用”非IETF文档或其他RFC的规则。 规范性引用是指为了实现标准而必须遵循的对某个文档的引用。 非规范性引用(有时称为“参考性引用”)是对实现者有用但并非必要的引用。

IETF标准可能会规范性地引用处于相同或更高标准级别的任何其他标准系列RFC,或引用任何在IETF以外制定的“开放式标准”。 “相同或更高级别”规则是指成为标准RFC,被规范性引用的所有RFC也必须是标准或已发布的互联网标准。 此规则详见[BCP97]。此规则向实施者保证互联网标准中的一切都是相当稳定的,甚至在标准以外引用的内容也是如此。 在等待其他文档跟进时,这也可能使标准RFC的发表延迟数月(有时甚至数年)。

对于什么是“开放式标准”并无硬性规定,但通常是指任何人都可以获得(虽然可能需要付费)并且是由公认的标准组织制定的稳定的标准。 如果外部标准发生变化,您必须在您的规范中引用该标准的具体例示,并附上该标准的制定日期。 有些外部标准组织并不提供旧版标准,这对需要在将来使用的IETF标准来说是个问题。 若有疑问,草案作者应该向工作组主席或相应的AD咨询某个外部标准是否可在IETF标准中使用。

6.4.3 IANA考虑事项

越来越多的IETF标准都需要注册各种协议参数,例如协议中的命名选项。 如我们在Section 2.2.4中所述,所有IETF标准的注册机构一直都是IANA。 由于标准要求的注册数量大、种类多,IANA需要制定有关如何注册参数、不能注册什么、谁(若有人)将决定注册什么等具体信息。

撰写可能需要新的IANA注册或在当前IANA注册中增加新值的互联网标准的任何人需要阅读[BCP26]《撰写RFC中IANA考虑部分的准则》, 它描述了RFC作者应如何正确地请求IANA注册或修订注册。IANA还维护着在产生BCP 26之前很久就开始的注册。

6.4.4 安全考虑事项

每份RFC和互联网草案必须具备的是“安全考虑”章节。此章节应描述协议的任何已知漏洞、可能出现的威胁以及处理它们的机制或策略。 请勿在此章节中进行粉饰 ; 特别是不要说“这就是我们的协议,如果您要安全性,只需用IPsec即可。” 这是根本行不通的,因为它并没有回答IPsec如何与您的协议互动的问题,反之亦然。参见[BCP72]《撰写RFC文本安全考虑的准则》 以详细了解如何撰写较好的安全考虑章节。

6.4.5 IETF标准中的专利

在最近几年里,知识产权的问题越来越频繁地出现,特别是与专利相关的问题。 IETF的目标是让自己的标准在市场上得到广泛使用和验证。如果创造一个使用标准的产品需要获得专利许可, 人们实现该标准的可能性就会下降。不足为奇是,一般规则是“尽可能地使用良好的非专利技术。”

自然,这并不总是可能的。有时专利会在标准已经发布后出现。 有时,拥有专利的某种东西是如此宝贵,以至于没有非专利的对等物。 有时专利持有人很慷慨并承诺向所有实施者授予专利的免使用费许可, 因此使实现几乎就像没有专利存在一样简单。

IETF处理标准中专利的方法是人们争论不休的一个话题。 有关IETF文档中所有知识产权 (IPR) 的正式规则(并不只是专利)可参见[BCP78][BCP79]《IETF技术中的知识产权》。 参加IETF工作组的每个人可能会觉得这些文档有趣,因为它们规定了每个人同意遵守的规则。

允许IETF标准的实现者免费使用其专利的专利持有人常常得到IETF成员的很多美好祝愿。 这类慷慨行为比您想象的更常见。例如,RFC 1822是IBM对其在一个特殊协议背景下的安全专利的许可, 而安全社区因此对IBM赞誉有加(相反,不少其他公司却因为在自己安全专利上的倔强固执而为人所不耻)。

如果您正在撰写互联网草案并且您知道有一个专利适用于您正在描述的技术,不要在文档中列出专利。 相反,请浏览以下IETF知识产权网页http://www.ietf.org/ipr来决定如何继续。 知识产权在RFC中不被提及,因为RFC在发表后从不变更,但知识产权可能随时变更。 因此,在RFC中列出知识产权列表可能是不完整的,会误导读者。 [BCP79]提供了在作者知晓知识产权问题后应该添加到RFC中的具体文字。

6.5 信息性和实验性RFC

如前所述,并非所有RFC都是标准。事实上,许多重要的RFC根本就不是标准系列。 目前,不打算成为标准的RFC有两种名称:信息性,如本文《IETF之道》,和实验性。 (实际上还有第三种名称,即“历史性”,但这是为曾在标准系列中,但因为缺乏当前使用而被移除的文档预留的, 或是为最新思考表明该技术实际上对互联网有害的文档预留的。)

信息性RFC的作用在IETF常常成为争论的话题。许多人们喜欢这类RFC的存在, 特别对于在IETF以外创建但被IETF文档引用的规范来说更是如此。 对于属于IETF工作组所进行工作的指导规范来说,这类RFC也有帮助作用。 另一方面,有些人将信息性RFC称作“标准”(虽然RFC并非标准), 其目的通常是欺骗轻信的公众去相信他正在推销或支持的东西。 发生这种情况时,就会引发新一轮有关信息性RFC的争论。

实验性RFC针对的是可能有趣但不清楚是否会有强烈实现兴趣的规范,或者是不清楚在部署后是否会起作用的规范。 也就是说,规范可能会解决问题,但如果不清楚是否有许多人认为该问题是重要的, 或认为他们会花功夫用该规范去解决该问题,则该规范可能会标记为实验性RFC。 如果规范后来受到欢迎(或证明是有效的),可重新发布为标准系列RFC的质量。 实验性RFC还用来促使人们对这样的技术进行实验:看上去可能属于标准系列材料,但仍然存在不少未解答问题的技术。

IESG制定了如何在信息性和实验性状态间取舍的准则: http://www.ietf.org/iesg/informational-vs-experimental.html。 如果您正在创建您认为可能成为实验性RFC的文档,知道当前的观念将有助于您证明所提议选择的正确性。


7. 如何为IETF做出贡献

7.1 您能做些什么

阅读 — 审查属于您专业领域的互联网草案并在工作组中对草案发表意见。 以友好、助人的方式参加讨论,目标是使其尽可能成为最好的互联网标准。多听少说。 如果您不同意,请针对技术问题来讨论,绝对不要人身攻击。

实现 — 编写使用当前互联网标准的程序。 标准如果没有互联网用户使用,那么它的价值并不大。实现哪怕是“不重要”的标准,因为如果它们出现在更多的软件中,其重要性也会提高。 向相关工作组报告您发现的标准问题,以便在今后的修订版中加以澄清说明。IETF广为引用的信条之一是“实用代码致胜”。 因此您可以通过创建更多的实用代码来帮助您喜欢的标准变得更加普及。 您可以从I-D开始实现(但不是部署)协议,确保作者做得不错,从而在协议变成标准之前帮助制定协议。 如果您发现有错误或遗漏之处,请根据您的实施经验提供改进建议。

撰写 — 编辑或合著您专业领域内的互联网草案。 目的是为了造福于互联网社会,而不是为了把您的姓名(更糟糕的是为了把公司名称)列在文档中。 草案作者会遭受各种各样的技术(有时是人身)批评;平静地接受并根据批评来完善草案,以便制定最好、最具互操作性的标准。

7.2 贵公司能做些什么

共享 — 避免私有标准。如果您是实现者,展现出您更倾向采用IETF标准。 如果IETF标准不如私有标准那样好,则努力使IETF标准变得更好。 如果您是买家,避免使用与IETF的开放式标准相竞争的私有标准产品,并告诉出售产品的公司您是这么做的。

开放 — 如果贵公司控制着IETF标准中所用的专利, 请说服公司允许对实现标准的每个人免收专利费。在最近几年里,专利已经给互联网标准造成了许多严重问题, 因为它们不允许一些公司自由地实现标准。幸运的是,许多公司慷慨大方地提供了某些专利的无限制许可, 以便帮助IETF标准繁荣兴旺。这些公司通常因此获得正面的宣传,因为它们不像其他专利持有人那样贪婪或短视。

加入 — 成为ISOC的会员。 更重要的是要敦促因互联网而受益的公司成为ISOC的组织会员,因为这对互联网协会来说有最大的经济效益。这自然也将造福于整个互联网。


8. IETF和外部世界

8.1 IETF和其他标准组织

正如许多IETF参与者想象的那样,IETF并不存在于标准的真空中。 有许多(或许太多)其他标准组织可做出影响互联网的决定。 也有相当数量的标准组织曾经长期忽视互联网,而现在希望从中分得一杯羹。

一般而言,IETF努力与其他标准组织建立诚挚的关系。 这并不总是一件轻松的事情,因为许多其他组织的结构与IETF截然不同, 而IETF在很大程度上是由志愿者运行的,他们可能更愿意撰写标准,而不是与来自其他组织的代表会晤。 即使如此,一些其他标准组织也尽力与IETF进行良好的互动,尽管彼此之间存在明显的文化差异。

在撰写本文时,IETF与一些大型标准组织都有联络,其中包括ITU-T(国际电信联盟的电信标准化部门)、W3C(万维网联盟)、IEEE(电气电子工程师学会) 以及统一码联盟。如IAB章程[BCP39]中所述,“尽可能地保持非正式的联络,并且联络必须在提高IETF规范质量方面具有可证明的价值”。 通常,实际上,IETF偏好在工作组这一级别上直接进行联系,而正式关系和联络文档起到支撑作用。

其中一些联络工作由IESG负责,而其他联络工作由IAB负责。 注重细节的读者将在[BCP102]《管理IETF联络关系的IAB流程》和[BCP103]《处理IETF往来联络函的程序》中 详细了解与其他标准组织打交道的正式方法。 查看IETF是否有正式联络的最佳之处是IET联络名单http://www.ietf.org/liaison。 此名单显示ISO/IEC JTC1各个子委员会有许多不同的联络人。

8.2 对IETF的媒体报道

考虑到IETF是正在帮助互联网向前发展的最著名组织之一,计算机刊物(甚至行业刊物)想报道其动态是再自然不过的事情。 近年来,有少量杂志委派记者和编辑对IETF进行长期的深度报道。 这些记者频频出错,包括颠倒事实的文章、有关互联网草案状态的不正确陈述、引述与IETF工作毫无关系的人士的语录等。

主要的报道错误分为两类:谈及IETF正在考虑什么,而事实上那只是工作组中的一个互联网草案; 以及谈及IETF已批准了什么,而实际上只是发表的信息性RFC。在这两种情况中,不能把问题完全怪罪于媒体, 因为他们通常是因为某个公司试图宣传自己制定或至少支持的某个协议而知道相关故事的。 当然,如果记者们做点调查,就可能联系上能够把事情向他们解释清楚的人士,如工作组主席或AD。 媒体寻找IETF媒体联系人的默认地点应该是<http://www.ietf.org/media.html>。

记者把情况弄错后仍然又回来报道IETF会议这一事实证明最终还是能够把事情搞清楚的。 但是,IETF会议对于完全不了解IETF流程的记者来说显然是不合适的(虽然如果您是记者并正在阅读本文档,这是一个很好的迹象!)。 而且,如果您认为自己将因为参加IETF会议而收获热门新闻,您可能会失望而归。

因此,有的IETF人士宁愿让媒体记者尽量离IETF会议远一些,也不足为奇。 对于接近完成并将在下一年具有重大行业意义的协议来说,获得一点媒体宣传报道也不失为好事。 不过,很少有记者能够抵御把萌芽状态中的协议炒作为下一个互联网救星的诱惑。 这类报道对文章的读者和IETF来说弊多利少。

记者可能希望参加IETF会议的主要原因不是报道热门技术(这可以舒服地坐在办公室里阅读邮件列表即可完成),而是与相关人士面对面接触。 不幸的是,最有趣的人士也是IETF会议上最忙碌的人,有的人往往看到媒体记者的胸卡就躲开了。 不过,IETF会议是与文档作者和工作组主席接触并交谈的好地方;对于正在报道协议进展情况的记者来说,是很有价值的。

希望弄清楚在某个话题上“IETF正在做什么”的记者最好与IETF中积极参加该话题讨论的多位人士交谈,并且尽可能尝试与工作组主席交流。 通过阅读草案或和草案作者交淡,是不可能确定草案会进展到哪一步的。 幸运的是,所有工作组都有档案可供记者查阅,以了解草案进展的最新情况; 不幸的是,很少有记者有时间或有意愿来做这样的调查研究。 由于IETF没有媒体联络人,刊载错误报道的杂志或报纸不会得到IETF的直接反馈意见, 因此常常不知道自己弄错了,以后又容易再犯错误。


9. 安全考虑事项

Section 6.4.4说明了为什么每个RFC都必须有一个“安全考虑”章节, 并提供了该章节应该和不应该包含哪些内容的一些建议。除此以外,本文档并不探讨互联网安全问题。

10. 参考文献

[BCP9] Bradner, S., “互联网标准流程 – 修订第3版”, BCP 9, RFC 2026, RFC 6410, October 1996.
[BCP10] Galvin, J., “IAB和IESG的选择、确认和恢复过程:提名和恢复委员会的运行”, BCP 10, RFC 3777, June 2004.
[BCP11] Hovey, R. and S. Bradner, “参与IETF标准流程的组织”, BCP 11, RFC 2028, October 1996.
[BCP14] Bradner, S., “RFC中用来注明要求级别的关键词”, BCP 14, RFC 2119, March 1997.
[BCP22] Scott, G., “互联网标准作者指南”, BCP 22, RFC 2360, June 1998.
[BCP25] Bradner, S., “IETF工作组准则和程序”, BCP 25, RFC 2418, September 1998.
[BCP26] Narten, T. and H. Alvestrand, “撰写RFC中IANA考虑章节的准则”, BCP 26, RFC 5226, May 2008.
[BCP39] 互联网架构委员会 and B. Carpenter, “互联网架构委员会 (IAB) 章程”, BCP 39, RFC 2850, May 2000.
[BCP45] Harris, S., “IETF讨论列表章程”, BCP 45, RFC 3005, November 2000.
[BCP72] Rescorla, E. and B. Korver, “撰写RFC文本安全考虑的准则”, BCP 72, RFC 3552, July 2003.
[BCP78] Bradner, S., “IETF的供稿权利”, BCP 78, RFC 5378, November 2008.
[BCP79] Bradner, S., “IETF技术中的知识产权”, BCP 79, RFC 3979, March 2005.
[BCP95] Alvestrand, H., “IETF的使命宣言”, BCP 95, RFC 3935, October 2004.
[BCP97] Bush, R. and T. Narten, “阐明标准系列文档何时可以规范性地引用较低级别的文档”, BCP 97, RFC 3967, December 2004.
[BCP101] Austein, R. and B. Wijnen, “IETF行政支持活动的结构 (IASA)”, BCP 101, RFC 4071, April 2005.
[BCP102] Daigle, L. and 互联网架构委员会, “管理IETF联络关系的IAB流程”, BCP 102, RFC 4052, April 2005.
[BCP103] Trowbridge, S., Bradner, S., and F. Baker, “处理IETF往来联络函的程序”, BCP 103, RFC 4053, April 2005.
[RFC1796] Huitema, C., Postel, J., and S. Crocker, “并非所有RFC都是标准”, RFC 1796, April 1995.
[RFC2223] Postel, J. and J. Reynolds, “RFC作者须知”, RFC 2223, October 1997.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, “有关互联网号码分配机构技术工作的谅解备忘录”, RFC 2860, June 2000.
[RFC6635] Kolkman, O. and J. Halpern, “RFC编辑者的工作模式(第2版)”, RFC 6635, March 2012.
[RFC4677] Hoffman, P. and S. Harris, “IETF之道 -- 互联网工程任务组新手指南”, RFC 4677, September 2006.
[RFC4858] Levkowetz, H., Meyer, D., Eggert, L., and A. Mankin, “从工作组最终审议到发表的引导性文档”, RFC 4858, May 2007.
[RFC6722] Hoffman, P., “将《IETF之道》发表为网页”, RFC 6722, August 2012.
[STD3] Braden, R., “互联网主机要求 – 应用程序和支持”, STD 3, RFC 1123, October 1989.

A. IETF指导原则

如果您已经阅读到《IETF之道》的这个部分,说明您已经对IETF的运作方式了解不少。 本附录总结的是您已经了解的多数内容并添加了几个供您思考的要点。请一定要详细阅读所有原则; 总的来说,它们会赋予您一个全新视角,来看待推动IETF工作的因素。

A.1 总则

IETF按照开放式流程和大致共识进行运作。这是根本适用于IETF运作的方方面面,包括IETF文档的创建以及有关所用流程的决定。 但IETF也有兴趣观察实验和实用代码,这应该也适用于该机构的运作流程。

IETF在它拥有或能够找到技术能力的领域开展工作。

IETF依赖于由活跃参与者组成的志愿者核心。

参与IETF或其工作组并不是以收费为基础的,也不是按组织来确定的,而是依据个人的自我认同和积极参与。

A.2 管理和领导

IETF认可领导职位并把决策权授予领导者,但可以针对决定提出上诉。

权力和职责的委派对于IETF的有效运作是至关重要的。 将鼓励尽可能多的个人承担IETF任务的领导工作。

异议、投诉和上诉是IETF性质产生的结果,应视为正常事件,但某些决定最终无法通过上诉推翻,这是无法改变的事实。

领导职务有固定任期(虽然我们没有对可担任的任期数规定了正式限制)。

在活跃的社区中培养未来的领导者是一件很重要的事情。

有一个社区流程被用来选拔领导者。

领导者有权做出展现大致共识的判断。没有正式的领导,就没有正式的共识规则。

A.3 流程

虽然IETF需要明确和公开记录的流程规则来处理正常情况,但也应该有足够的灵活性来根据常识处理异乎寻常的情况。 我们运用个人判断力,只在我们有把握时才编成法典。(但我们的确把能够做出个人判断的人视为法典。)

技术开发工作应该由具有严格章程和工作重点的工作组来进行。

经实践证明不实用的流程部分应该取消或变成可选择的项目。

A.4 工作组

工作组应该主要负责自己工作成果的质量。作为工作组领导并获得IETF领导层支持的工作组主席应该把好质量关。

工作组应该主要负责评估自己的工作对互联网整体的负面影响,因此要负责获得跨领域的审查。 IETF领导层应该成为跨领域的关卡。

对文档早审查,特别是由工作组进行的审查,在处理重大问题方面会比晚审查更有效。

领域指导 (AD) 负责引导工作组的组建和章程制定,在必要时提供指导,也负责终止工作组。 工作组主席的工作是为了让负责任的AD满意。

工作组主席负责确保工作组履行章程、实现里程碑以及产生可以发表的可交付成果。 文档编辑的工作是为了令工作组主席满意。

AD负责安排关卡式审查和最终的文档审批。

A.5 文档

IETF标准常常从个人草案开始,可能成为工作组草案,并由独立于工作组或制定草案的个人的领导机构批准后永久发表。

IETF标准属于社区,而不是作者本人。但原作者和供稿者会得到认可和重视。

技术质量和正确性是达成有关文档共识的主要标准。

IETF规范可作为信息性、实验性、标准系列、历史性或当前最佳实践来发表。

IETF标准系列系列规范不被视为令人满意的标准,直到展示了可互操作的独立实施。 (这体现了“实用代码”这一口号。)不过,IETF并不负责互操作性测试,也不认证互操作性。

IETF流程作为当前最佳实践文档发表。

既非规范也非流程的有用信息可作为信息性文档发表。

过时或废弃的规范和流程可能降级为历史性文档。

标准系列系列应该区分已证明互操作性的规范。

标准系列系列和当前最佳实践文档必须获得IETF广泛的大致共识(最终审议流程)。 工作组大致共识通常对于其他文档来说就足够了。

因IETF最终审议或IESG评估而进行的实质性更改必须重新交给工作组考虑。

IETF决定其文档的发表和存档要求。