本节书摘来自华章出版社《无线网络：理解和应对互联网环境下网络互连所带来的挑战》一书中的第2章，第2.3节，作者：（美）杰克L.伯班克（Jack L. Burbank）等著，更多章节内容可以访问云栖社区“华章计算机”公众号查看
2.3 IETF
IETF是一个为互联网和相关网络开发技术标准的大型开放社区，其任务如下[57]：
确定互联网中存在的迫切运营和技术问题，并提出解决方案；
规定协议和近期架构的开发或使用，来解决互联网的这些问题；
向互联网工程指导组（Internet Engineering Steering Group，IESG）提出关于互联网协议标准化和协议使用的建议；
促进技术从互联网研究任务组（Internet Research Task Force，IRTF）移植到更广泛的互联网社区；
为厂商、用户、研究人员、机构承包商和网络管理人员之间的社区内信息交换提供一个论坛。
IETF每年召开三次会议，然而，许多参与者并不参加会议，这和IEEE 802 LMSC有些类似，即标准的推进不是依靠正式的投票过程决定的。通常，只要工作组成员能达成大致共识，标准推进即被认为是可接收的。大致的共识是从主观上得到的，因此工作组主席在决定是否达到大致共识时有比较大的回旋余地。此外，IETF里没有明确的参与会员，参考文献[58]讨论了IETF标准化过程所涉及的组织。除了IETF之外，其他组织包括：
IETF秘书处：作为行政机关支持IETF的活动。这个组织由IETF执行理事和相关工作人员组成，其中，执行理事是互联网标准过程中各个方面的正式联络人。
互联网协会（Internet Society，ISOC）：一个关注互联网的演进和发展以及互联网使用带来的社会和技术问题的国际组织。标准化是ISOC中的一个有组织的活动。
IESG：作为ISOC中负责管理IETF技术活动的部门，这个小组负责保障“标准跟踪”（standards track）技术规范的顺利实施，包括工作组的最初认证和互联网标准的最终认证。
互联网架构委员会（Internet Architecture Board，IAB）：经ISOC理事特许负责监督互联网的架构和相关协议。该委员会负责任命IETF主席，并批准IETF任名委员会所推荐的其他IESG候选人。
IESG由若干个领域负责人（Area Director，AD）组成，这些AD由IETF任命委员会（Nominations Committee，NomCom）选举产生，任期两年。一个AD负责某个特定领域以及该领域下的工作组。目前有如下几个领域：
应用（Applications，APP）：用户程序涉及的协议（聊天、Web）
通用（General，GEN）：不归类到其他任何类别的工作组
互联网（Internet，INT）：关注IP数据包移动和DNS信息
运营和管理（Operations and Management，OPS）：互联网系统的运营方面，包括网络的监控和配置
实时应用和基础设施（Real-Time Applications and Infrastructure，RAI）：专注于对延迟敏感的人际通信（例如语音、视频聊天）
路由（Routing，RTG）：关注将数据包移动到预期目的地
安全（Security，SEC）：认证、保密、授权
传输（Transport，TSV）：特殊数据包的特殊服务
IETF中大部分工作都是由工作组完成的，工作组有专门的章程文件规定工作组的研究范围和相关目标。工作组主席决定工作组的目标和里程碑，并负责跟进最新章程，保证工作组输出的技术和非技术工作的质量。在工作组会议期间，主席设置并掌控会议议程，管理在讨论期间产生的难以处理的争论。工作组完成其制定的章程后，就被停止运行。
如果个人或团队想要针对互联网相关问题开发一个协议或标准方法，他们可以写一个细述其方法思想的互联网草案文档并申请在一个工作组内进行展示，或者在下一次IETF会议中以它作为基础产生一个“兴趣小组”（Birds-of-a-Feather，BOF）。由于特殊会议空间有限，兴趣小组的成立需要得到事先批准。然而，IETF中，参加会议不是提出方法唯一的途径，互联网草案也可以提交到工作组的邮件列表进行讨论。
一旦互联网草案被工作组接收，作为一个工作项目或者一个有望成为工作组的兴趣小组，如果工作组或者AD认为其研究是相关的并且是有用的，该互联网草案将变成请求注解（Request for Comments，RFC）文档。RFC发布时，会被分配一个编号（例如RFC 2028）。然而，RFC名字具有误导性：通常，文档在由RFC编辑分配一个编号之前，已经经历了多轮的意见和辩论。IETF按名字保存RFC系统，虽然当前一些特定用语在过去并不一定适用。其中有6种类型的RFC：
建议标准
标准草案
互联网标准
信息文档
实验协议
历史文档
前三种类型被认为是IETF官方标准。通常情况下，不管文档来源如何，标准跟踪文件均可由IETF社区进行改变。
当互联网草案经过讨论并被认为是一个潜在的有用标准时，草案就被提交到IESG。如果草案是由工作组发起的（即它是一个官方工作组草案），在它被提交到工作组最新公告后，工作组主席将它发送给相应的AD。最新公告过程给了工作组中的参与者最后的机会来发表意见、讨论互联网草案细节。如果草案是由个人而不是一个特定的工作组提交的，作者需要将文件提交到合适的AD以供考虑。一旦草案提交到IESG，IESG将会为草案发布一个IETF最新公告。完成这个过程后，如果IESG批准草案成为一个互联网的标准，他们会让RFC编辑将其作为一个建议标准进行发布。6个月后，草案作者或工作组主席可以要求将该草案转移到标准草案状态，但条件是该草案必须至少完成两项独立、互操作的实现并由AD鉴定过。在该过程中，对于测试实现的这个要求能提高文档的质量，因为独立的实现可能会对标准中的文本有不同的解释。几年后，一个标准的草案可以成为互联网的标准，但这种情况很少发生，因为互联网标准被认为是互联网必不可少的功能，例如原来的互联网协议RFC 791。图2-2是潜在的RFC由互联网草案成为RFC形式的图解。
图2-2 IETF互联网草案到RFC的过程
