Network Working Group                                     L. Daigle, Ed.
Request for Comments: 4844
Category: Informational                      Internet Architecture Board
                                                                   (IAB)
                                                               July 2007
        
Network Working Group                                     L. Daigle, Ed.
Request for Comments: 4844
Category: Informational                      Internet Architecture Board
                                                                   (IAB)
                                                               July 2007
        

The RFC Series and RFC Editor

RFC系列和RFC编辑器

Status of This Memo

关于下段备忘

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The IETF Trust (2007).

版权所有(C)IETF信托基金(2007年)。

Abstract

摘要

This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate.

本文件描述了RFC系列的框架和RFC编辑器功能,其中包含了随着互联网技术社区的发展而变得必要的有组织的社区参与和责任的原则,从而使RFC系列能够继续履行其任务。

Table of Contents

目录

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  RFC Series Mission . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Roles and Responsibilities . . . . . . . . . . . . . . . . . .  5
     3.1.  RFC Editor . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  IAB  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Operational Oversight  . . . . . . . . . . . . . . . . . .  5
     3.4.  Policy Oversight . . . . . . . . . . . . . . . . . . . . .  6
   4.  Framework  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Document Approval  . . . . . . . . . . . . . . . . . . . .  7
       4.1.1.  Definition . . . . . . . . . . . . . . . . . . . . . .  7
       4.1.2.  Operational Implementation . . . . . . . . . . . . . .  7
       4.1.3.  Process Change . . . . . . . . . . . . . . . . . . . .  8
       4.1.4.  Existing Approval Process Documents  . . . . . . . . .  8
     4.2.  Editing, Processing, and Publication of Documents  . . . .  8
       4.2.1.  Definition . . . . . . . . . . . . . . . . . . . . . .  8
       4.2.2.  Operational Implementation . . . . . . . . . . . . . .  8
       4.2.3.  Process Change . . . . . . . . . . . . . . . . . . . .  9
       4.2.4.  Existing Process Documents . . . . . . . . . . . . . .  9
     4.3.  Archiving, Indexing, and Accessibility . . . . . . . . . .  9
       4.3.1.  Definition . . . . . . . . . . . . . . . . . . . . . .  9
       4.3.2.  Operational Implementation . . . . . . . . . . . . . .  9
       4.3.3.  Process Change . . . . . . . . . . . . . . . . . . . . 10
       4.3.4.  Existing Process Documents . . . . . . . . . . . . . . 10
     4.4.  Series-Wide Guidelines and Rules . . . . . . . . . . . . . 10
       4.4.1.  Definition . . . . . . . . . . . . . . . . . . . . . . 10
       4.4.2.  Operational Implementation . . . . . . . . . . . . . . 10
       4.4.3.  Process Change . . . . . . . . . . . . . . . . . . . . 10
       4.4.4.  Existing Process Documents . . . . . . . . . . . . . . 10
   5.  RFC Streams  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  RFC Approval Processes . . . . . . . . . . . . . . . . . . 11
       5.1.1.  IETF Document Stream . . . . . . . . . . . . . . . . . 11
       5.1.2.  IAB Document Stream  . . . . . . . . . . . . . . . . . 12
       5.1.3.  IRTF Document Stream . . . . . . . . . . . . . . . . . 12
       5.1.4.  Independent Submission Stream  . . . . . . . . . . . . 12
     5.2.  RFC Technical Publication Requirements . . . . . . . . . . 13
       5.2.1.  IETF Documents . . . . . . . . . . . . . . . . . . . . 13
       5.2.2.  IAB Documents  . . . . . . . . . . . . . . . . . . . . 13
       5.2.3.  IRTF Documents . . . . . . . . . . . . . . . . . . . . 13
       5.2.4.  Independent Submissions  . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IAB Members at the Time of Approval  . . . . . . . . . . . . . 14
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 15
   Appendix A.  A Retrospective of IAB Charters and RFC Editor  . . . 17
     A.1.  1992 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     A.2.  1994 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     A.3.  2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
        
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  RFC Series Mission . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Roles and Responsibilities . . . . . . . . . . . . . . . . . .  5
     3.1.  RFC Editor . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  IAB  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Operational Oversight  . . . . . . . . . . . . . . . . . .  5
     3.4.  Policy Oversight . . . . . . . . . . . . . . . . . . . . .  6
   4.  Framework  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Document Approval  . . . . . . . . . . . . . . . . . . . .  7
       4.1.1.  Definition . . . . . . . . . . . . . . . . . . . . . .  7
       4.1.2.  Operational Implementation . . . . . . . . . . . . . .  7
       4.1.3.  Process Change . . . . . . . . . . . . . . . . . . . .  8
       4.1.4.  Existing Approval Process Documents  . . . . . . . . .  8
     4.2.  Editing, Processing, and Publication of Documents  . . . .  8
       4.2.1.  Definition . . . . . . . . . . . . . . . . . . . . . .  8
       4.2.2.  Operational Implementation . . . . . . . . . . . . . .  8
       4.2.3.  Process Change . . . . . . . . . . . . . . . . . . . .  9
       4.2.4.  Existing Process Documents . . . . . . . . . . . . . .  9
     4.3.  Archiving, Indexing, and Accessibility . . . . . . . . . .  9
       4.3.1.  Definition . . . . . . . . . . . . . . . . . . . . . .  9
       4.3.2.  Operational Implementation . . . . . . . . . . . . . .  9
       4.3.3.  Process Change . . . . . . . . . . . . . . . . . . . . 10
       4.3.4.  Existing Process Documents . . . . . . . . . . . . . . 10
     4.4.  Series-Wide Guidelines and Rules . . . . . . . . . . . . . 10
       4.4.1.  Definition . . . . . . . . . . . . . . . . . . . . . . 10
       4.4.2.  Operational Implementation . . . . . . . . . . . . . . 10
       4.4.3.  Process Change . . . . . . . . . . . . . . . . . . . . 10
       4.4.4.  Existing Process Documents . . . . . . . . . . . . . . 10
   5.  RFC Streams  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  RFC Approval Processes . . . . . . . . . . . . . . . . . . 11
       5.1.1.  IETF Document Stream . . . . . . . . . . . . . . . . . 11
       5.1.2.  IAB Document Stream  . . . . . . . . . . . . . . . . . 12
       5.1.3.  IRTF Document Stream . . . . . . . . . . . . . . . . . 12
       5.1.4.  Independent Submission Stream  . . . . . . . . . . . . 12
     5.2.  RFC Technical Publication Requirements . . . . . . . . . . 13
       5.2.1.  IETF Documents . . . . . . . . . . . . . . . . . . . . 13
       5.2.2.  IAB Documents  . . . . . . . . . . . . . . . . . . . . 13
       5.2.3.  IRTF Documents . . . . . . . . . . . . . . . . . . . . 13
       5.2.4.  Independent Submissions  . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IAB Members at the Time of Approval  . . . . . . . . . . . . . 14
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 15
   Appendix A.  A Retrospective of IAB Charters and RFC Editor  . . . 17
     A.1.  1992 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     A.2.  1994 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     A.3.  2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
        
1. Introduction
1. 介绍

The first Request for Comments (RFC) document was published in April of 1969 as part of the effort to design and build what we now know of as the Internet. Since then, the RFC Series has been the archival series dedicated to documenting Internet technical specifications, including both general contributions from the Internet research and engineering community as well as standards documents.

第一份征求意见(RFC)文件于1969年4月发布,作为我们现在所知的互联网设计和建设工作的一部分。从那时起,RFC系列一直是一个档案系列,专门记录互联网技术规范,包括互联网研究和工程界的一般贡献以及标准文件。

As described in the history of the first 30 years of RFCs ([RFC2555]), the RFC Series was created for the purpose of capturing the research and engineering thought that underlie the design of (what we now know of as) the Internet. As the Internet Engineering Task Force (IETF) was formalized to carry out the discussion and documentation of Internet standards, IETF documents have become a large part (but not the entirety) of the RFC Series.

正如RFC最初30年的历史([RFC2555])中所述,创建RFC系列的目的是为了捕捉互联网(我们现在所知)设计背后的研究和工程思想。随着互联网工程任务组(IETF)正式成立,以进行互联网标准的讨论和记录,IETF文件已成为RFC系列的一大部分(但不是全部)。

As the IETF has grown up and celebrated its own 20 years of history, its requirements for archival publication of its output have changed and become more rigorous. Perhaps most significantly, the IETF must be able to define (based on its own open consensus discussion processes and leadership directions) and implement adjustments to its publication processes.

随着IETF的成长和庆祝其20年的历史,其对其输出的档案出版的要求也发生了变化,变得更加严格。也许最重要的是,IETF必须能够定义(基于其自身的开放共识讨论过程和领导方向)并对其出版过程进行调整。

At the same time, the Internet engineering and research community as a whole has grown and come to require more openness and accountability in all organizations supporting it. More than ever, this community needs an RFC Series that is supported (operationally and in terms of its principles) such that there is a balance of:

与此同时,互联网工程和研究界作为一个整体已经发展壮大,并要求所有支持它的组织更加开放和负责。这个社区比以往任何时候都更需要一个得到支持的RFC系列(在操作上和原则上),以便平衡:

o expert implementation;

o 专家执行;

o clear management and direction -- for operations and evolution across the whole RFC Series (whether originating in the IETF or not); and

o 明确的管理和方向——用于整个RFC系列(无论是否源自IETF)的操作和演变;和

o appropriate community input into and review of activities.

o 社区对活动的适当投入和审查。

Today, there is confusion and therefore sometimes tension over where and how to address RFC issues that are particular to contributing groups (e.g., the IETF, the Internet Architecture Board (IAB), or independent individuals). It isn't clear where there should be community involvement versus RFC Editor control; depending on the issue, there might be more or less involvement from the IAB, the Internet Engineering Steering Group (IESG), or the community at large. There are similar issues with handling RFC Series-wide issues -- where to discuss and resolve them in a way that is balanced across the whole series.

如今,对于贡献群体(如IETF、互联网体系结构委员会(IAB)或独立个人)特有的RFC问题,在何处以及如何解决这些问题上存在着困惑,因此有时会出现紧张。与RFC编辑器控制相比,社区参与在哪里还不清楚;根据问题的不同,IAB、互联网工程指导小组(IESG)或整个社区可能或多或少地参与其中。在处理RFC系列范围内的问题时也存在类似的问题——以一种在整个系列中平衡的方式讨论和解决这些问题。

For example, there are current discussions about Intellectual Property Rights (IPR) for IETF-generated documents, but it's not clear when or how to abstract the portions of those discussions that are relevant to the rest of the RFC Series. Discussions of labeling (of RFCs in general, IETF documents in particular, or some combination thereof) generally must be applied on an RFC Series-wide basis or not at all. Without an agreed-on framework for managing the RFC Series, it is difficult to have those discussions in a non-polarized fashion -- either the IETF dictating the reality of the rest of the RFC Series, or the RFC Series imposing undue restrictions on the IETF document series.

例如,目前有关于IETF生成文档的知识产权(IPR)的讨论,但不清楚何时或如何抽象这些讨论中与RFC系列其余部分相关的部分。标签讨论(一般是RFC,特别是IETF文件,或其某些组合)通常必须在RFC系列的基础上应用,或者根本不应用。如果没有一个管理RFC系列的商定框架,就很难以非两极分化的方式进行这些讨论——要么是IETF指令RFC系列其余部分的实际情况,要么是RFC系列对IETF文件系列施加不适当的限制。

As part of its charter (see Appendix A), the IAB has a responsibility for the RFC Editor. Acknowledging the IETF's and the general Internet engineering and research community's evolving needs, the IAB would like to see a future for the RFC Series that continues to meet its original mandate of providing the archival series for the technical research and engineering documentation that describes the Internet.

作为其章程的一部分(见附录A),IAB对RFC编辑负责。IAB承认IETF和一般互联网工程和研究界不断发展的需求,希望看到RFC系列的未来,继续满足其最初的任务,即为描述互联网的技术研究和工程文档提供归档系列。

With this document, the IAB provides the framework for the RFC Series and an RFC Editor function with the specific purpose of ensuring that the RFC Series is maintained and supported in ways that are consistent with the stated purpose of the RFC Series and the realities of today's Internet research and engineering community. The framework describes the existing "streams" of RFCs, draws a roadmap of existing process documents already defining the implementation, and provides clear direction of how to evolve this framework and its supporting pieces through discussion and future document revision.

通过本文件,IAB为RFC系列提供了框架和RFC编辑器功能,其具体目的是确保RFC系列的维护和支持方式符合RFC系列的既定目的以及当今互联网研究和工程界的现实。该框架描述了RFC的现有“流程”,绘制了已定义实施的现有流程文件的路线图,并通过讨论和未来的文件修订,为如何发展该框架及其支持部分提供了明确的方向。

Specifically, this document provides a brief charter for the RFC Series, describes the role of the RFC Editor, the IAB, and the IETF Administrative Support Activity (IASA) in a framework for managing the RFC Series, and discusses the streams of input to the RFC Series from the various constituencies it serves.

具体而言,本文件提供了RFC系列的简要章程,描述了RFC编辑器、IAB和IETF管理支持活动(IASA)在管理RFC系列的框架中的作用,并讨论了RFC系列从其服务的各个用户群获得的输入流。

2. RFC Series Mission
2. RFC系列任务

The RFC Series is the archival series dedicated to documenting Internet technical specifications, including general contributions from the Internet research and engineering community as well as standards documents.

RFC系列是一个档案系列,专门用于记录互联网技术规范,包括互联网研究和工程界的一般贡献以及标准文件。

RFCs are available free of charge to anyone via the Internet.

任何人都可以通过互联网免费获得RFC。

3. Roles and Responsibilities
3. 角色和责任

As this document sets out a revised framework for supporting the RFC Series mission, this section reviews the updated roles and responsibilities of the entities that have had, and will have, involvement in continued support of the mission.

由于本文件规定了支持RFC系列任务的修订框架,本节审查了已经和将要参与持续支持任务的实体的最新角色和责任。

3.1. RFC Editor
3.1. RFC编辑

Originally, there was a single person acting as editor of the RFC Series (the RFC Editor). The task has grown, and the work now requires the organized activity of several experts, so there are RFC Editors, or an RFC Editor organization. In time, there may be multiple organizations working together to undertake the work required by the RFC Series. For simplicity's sake, and without attempting to predict how the role might be subdivided among them, this document refers to this collection of experts and organizations as the "RFC Editor".

最初,只有一个人担任RFC系列的编辑(RFC编辑)。这项任务已经增加,现在这项工作需要几位专家的有组织的活动,因此有了RFC编辑器或RFC编辑器组织。随着时间的推移,可能会有多个组织共同承担RFC系列所需的工作。为了简单起见,本文件将专家和组织的集合称为“RFC编辑器”,而不是试图预测角色如何在他们之间细分。

The RFC Editor is an expert technical editor and series editor, acting to support the mission of the RFC Series. As such, the RFC Editor is the implementer handling the editorial management of the RFC Series, in accordance with the defined processes. In addition, the RFC Editor is expected to be the expert and prime mover in discussions about policies for editing, publishing, and archiving RFCs.

RFC编辑器是一名专家技术编辑器和系列编辑器,负责支持RFC系列的任务。因此,RFC编辑器是根据定义的流程处理RFC系列编辑管理的实现者。此外,RFC编辑有望成为有关RFC编辑、发布和归档政策讨论的专家和主要推动者。

3.2. IAB
3.2. IAB

In this model, the role of the IAB is to ensure that the RFC Series mission is being appropriately fulfilled for the whole community for which it was created. The IAB does not, organizationally, have comprehensive publishing or editorial expertise. Therefore, the role of the IAB as put forward in this document is focused on ensuring that principles are met, the appropriate bodies and communities are duly informed and consulted, and the RFC Editor has what it needs in order to execute on the material that is in their mandate.

在这个模型中,IAB的作用是确保RFC系列任务在为其创建的整个社区中得到适当的完成。IAB在组织上不具备全面的出版或编辑专业知识。因此,本文件中提出的IAB的作用集中于确保满足原则,适当的机构和社区得到适当的通知和咨询,RFC编辑拥有其所需的内容,以便执行其任务规定的材料。

It is the responsibility of the IAB to approve the appointment of the RFC Editor and to approve the general policy followed by the RFC Editor.

IAB负责批准RFC编辑的任命,并批准RFC编辑遵循的一般政策。

3.3. Operational Oversight
3.3. 运作监督

The IETF Administrative Support Activity (BCP 101, [BCP101]) was created to provide administrative support for the IETF, the IAB, and the Internet Research Task Force (IRTF). In its role of supporting

IETF行政支持活动(BCP 101,[BCP101])旨在为IETF、IAB和互联网研究工作队(IRTF)提供行政支持。以其支持的作用

the IAB, the IASA is tasked with providing the funding for and operational oversight of the RFC Editor.

IAB、IASA的任务是为RFC编辑提供资金和运营监督。

The IAOC (IETF Administrative Oversight Committee) is the oversight board of the IASA, and the IAD (IETF Administrative Director) is the chief actor for the IASA.

IAOC(IETF行政监督委员会)是IASA的监督委员会,IAD(IETF行政总监)是IASA的主要参与者。

The IAOC works with the IAB to identify suitable persons or entities to fulfill the mandate of the RFC Editor.

IAOC与IAB合作,确定合适的人员或实体,以履行RFC编辑的任务。

The IAOC establishes appropriate contractual agreements with the selected persons or entities to carry out the work that will satisfy the technical publication requirements defined for the various RFC input streams (see Section 5.2). The IAOC may define additional operational requirements and policies for management purposes to meet the requirements defined by the various communities.

IAOC与选定的人员或实体签订适当的合同协议,以开展满足各种RFC输入流技术出版物要求的工作(见第5.2节)。IAOC可为管理目的定义额外的运营要求和政策,以满足各社区定义的要求。

In accordance with BCP 101, the IAOC provides oversight of the operation of the RFC Editor activity based on the established agreements.

根据BCP 101,IAOC根据既定协议对RFC编辑活动的运作进行监督。

3.4. Policy Oversight
3.4. 政策监督

The IAB monitors the effectiveness of the policies in force and their implementation to ensure that the RFC Editor activity meets the editorial management and document publication needs as referenced in this document. In the event of serious non-conformance, the IAB, either on its own initiative or at the request of the IAOC, may require the IAOC to vary or terminate and renegotiate the arrangements for the RFC Editor activity.

IAB监控现行政策及其实施的有效性,以确保RFC编辑活动满足本文件中提及的编辑管理和文件出版需求。如果出现严重不符合项,IAB可主动或应IAOC的请求,要求IAOC更改或终止RFC编辑活动的安排,并重新协商。

4. Framework
4. 框架

With the RFC Series mission outlined above, this document describes a framework for supporting

对于上面概述的RFC系列任务,本文档描述了一个支持

o the operational implementation of the RFC Series,

o RFC系列的操作实施,

based on

基于

o public process and definition documents,

o 公共流程和定义文件,

for which there are

其中有

o clear responsibilities and mechanisms for update and change.

o 明确更新和更改的责任和机制。

Generally speaking, the RFC Editor is responsible for the operational implementation of the RFC Series. As outlined in Section 3.3, the IAD provides the oversight of this operational role.

一般来说,RFC编辑器负责RFC系列的操作实现。如第3.3节所述,IAD负责监督这一业务角色。

The process and definition documents are detailed below, including responsibility for the individual process documents (maintenance and update). The RFC Editor works with the appropriate community to ensure that the process documents reflect current requirements. The IAB is charged with the role of verifying that appropriate community input has been sought and that any changes appropriately account for community requirements.

以下详细说明了过程和定义文件,包括各个过程文件的责任(维护和更新)。RFC编辑器与适当的社区合作,以确保流程文档反映当前的需求。IAB负责验证是否已寻求适当的社区投入,以及任何变更是否适当考虑了社区需求。

There are 3 categories of activity, and a 4th category of series-wide rules and guidelines, described for implementing the RFC Series to support its mission:

为实施RFC系列以支持其任务,有3类活动和系列范围内的第4类规则和指南:

o Approval of documents.

o 批准文件。

o Editing, processing, and publication of documents.

o 文档的编辑、处理和发布。

o Archiving and indexing the documents and making them accessible.

o 归档和索引文档并使其可访问。

o Series rules and guidelines.

o 系列规则和指南。

4.1. Document Approval
4.1. 文件批准

The RFC Series mission implicitly requires that documents be reviewed and approved for acceptance into the series.

RFC系列任务含蓄地要求对文件进行审查和批准,以便纳入该系列。

4.1.1. Definition
4.1.1. 释义

Section 5.1 describes the different streams of documents that are put to the RFC Editor for publication as RFCs today. While there may be general policies for approval of documents as RFCs (to ensure the coherence of the RFC Series), there are also policies defined for the approval of documents in each stream. Generally speaking, there is a different approving body for each stream. The current definitions are catalogued in Section 5.1.

第5.1节描述了放在RFC编辑器中作为RFC发布的不同文档流。虽然可能存在将文件批准为RFC的一般政策(以确保RFC系列的一致性),但也有为每个流中的文件批准定义的政策。一般来说,每个流程都有不同的审批机构。第5.1节对当前定义进行了分类。

4.1.2. Operational Implementation
4.1.2. 业务执行

Each stream has its own documented approval process. The RFC Editor is responsible for the approval of documents in one of the streams (Independent Submission stream, see Section 5.1.4) and works with the other approving bodies to ensure smooth passage of approved documents into the next phases, ultimately to publication and archiving as an RFC.

每个流程都有自己的文件化批准流程。RFC编辑负责审批其中一个流程中的文件(独立提交流程,见第5.1.4节),并与其他审批机构合作,确保批准的文件顺利进入下一个阶段,最终作为RFC发布和归档。

4.1.3. Process Change
4.1.3. 过程变更

From time to time, it may be necessary to change the approval processes for any given stream, or even add or remove streams. This may occur when the RFC Editor, the IAB, the body responsible for a given stream of documents, or the community determines that there are issues to be resolved in general for RFC approval or for per-stream approval processes.

有时,可能需要更改任何给定流的批准流程,甚至添加或删除流。当RFC编辑器、IAB、负责给定文档流的机构或社区确定RFC审批或每流审批流程通常存在需要解决的问题时,可能会发生这种情况。

In this framework, the general approach is that the IAB will work with the RFC Editor and other parties to get community input and it will verify that any changes appropriately account for community requirements.

在这个框架中,一般的方法是IAB将与RFC编辑器和其他各方合作,以获得社区的投入,并验证任何更改是否适当地考虑了社区的需求。

4.1.4. Existing Approval Process Documents
4.1.4. 现有审批流程文件

The existing documents describing the approval processes for each stream are detailed in Section 5.1.

第5.1节详述了描述各流程审批流程的现有文件。

4.2. Editing, Processing, and Publication of Documents
4.2. 文档的编辑、处理和发布

Producing and maintaining a coherent, well-edited document series requires specialized skills and subject matter expertise. This is the domain of the RFC Editor. Nevertheless, the community served by the RFC Series and the communities served by the individual streams of RFCs have requirements that help define the nature of the series.

制作和维护一个连贯、编辑良好的文档系列需要专业技能和主题专业知识。这是RFC编辑器的域。然而,由RFC系列服务的社区和由RFC的各个流服务的社区有助于定义系列性质的需求。

4.2.1. Definition
4.2.1. 释义

General and stream-specific requirements for the RFC Series are documented in community-approved documents (catalogued in Section 5.2 below).

RFC系列的一般要求和特定于流的要求记录在社区批准的文件中(见下文第5.2节)。

Any specific interfaces, numbers, or concrete values required to make the requirements operational are the subject of agreements between the IASA and the RFC Editor (e.g., contracts, statements of work, service level agreements, etc).

IASA与RFC编辑之间的协议(如合同、工作说明书、服务水平协议等)涉及使需求可操作所需的任何特定接口、编号或具体值。

4.2.2. Operational Implementation
4.2.2. 业务执行

The RFC Editor is responsible for ensuring that editing, processing, and publication of RFCs are carried out in a way that is consistent with the requirements laid out in the appropriate documents. The RFC Editor works with the IASA to provide regular reporting and feedback on these operations.

RFC编辑负责确保RFC的编辑、处理和发布方式符合相关文件中规定的要求。RFC编辑与IASA合作,定期报告和反馈这些操作。

4.2.3. Process Change
4.2.3. 过程变更

From time to time, it may be necessary to change the requirements for any given stream, or the RFC Series in general. This may occur when the RFC Editor, the IAB, the approval body for a given stream of documents, or the community determines that there are issues to be resolved in general for RFCs or for per-stream requirements.

有时,可能需要更改任何给定流或RFC系列的一般要求。当RFC编辑器、IAB、给定文档流的审批机构或社区确定RFC或每个流的需求通常存在需要解决的问题时,可能会发生这种情况。

In this model, the general approach is that the IAB will work with the RFC Editor to get community input and it will approve changes by validating appropriate consideration of community requirements.

在该模型中,一般的方法是IAB将与RFC编辑器合作,以获取社区输入,并通过验证对社区需求的适当考虑来批准更改。

4.2.4. Existing Process Documents
4.2.4. 现有工艺文件

Documents describing existing requirements for the streams are detailed in Section 5.2.

第5.2节详细说明了流的现有要求。

4.3. Archiving, Indexing, and Accessibility
4.3. 归档、索引和可访问性

The activities of archiving, indexing, and making accessible the RFC Series can be informed by specific subject matter expertise in general document series editing. It is also important that they are informed by requirements from the whole community. As long as the RFC Series is to remain coherent, there should be uniform archiving and indexing of RFCs across all streams and a common method of accessing the resulting documents.

RFC系列的归档、索引和访问活动可以通过一般文档系列编辑中的特定主题专业知识来了解。让他们了解整个社区的需求也很重要。只要RFC系列保持一致,就应该对所有流中的RFC进行统一的归档和索引,并提供访问结果文档的通用方法。

4.3.1. Definition
4.3.1. 释义

In principle, there should be a community consensus document describing the archiving, indexing, and accessibility requirements for the RFC Series. In practice, we continue with the archive as built by the capable RFC Editors since the series' inception.

原则上,应该有一个社区共识文档,描述RFC系列的归档、索引和可访问性要求。在实践中,我们继续使用自本系列开始以来由有能力的RFC编辑器构建的归档。

Any specific concrete requirements for the archive, index, and accessibility operations are the subject of agreements between the IASA and the RFC Editor (e.g., contracts, statements of work, service level agreements, etc).

存档、索引和可访问性操作的任何具体要求都是IASA和RFC编辑器之间协议的主题(例如,合同、工作说明书、服务级别协议等)。

4.3.2. Operational Implementation
4.3.2. 业务执行

The RFC Editor is responsible for ensuring that the RFC archive and index are maintained appropriately and that the resulting documents are made available to anybody wishing to access them via the Internet. The RFC Editor works with the IASA for regular reporting and feedback.

RFC编辑器负责确保RFC存档和索引得到适当维护,并且生成的文档可供希望通过Internet访问它们的任何人使用。RFC编辑与IASA合作定期报告和反馈。

4.3.3. Process Change
4.3.3. 过程变更

Should there be a community move to propose changes to the requirements for the RFC archive and index or accessibility, the IAB will work with the RFC Editor to get community input and it will approve changes by validating appropriate consideration of community requirements.

如果社区提出变更RFC存档和索引或可访问性要求的建议,IAB将与RFC编辑器合作,获取社区意见,并通过验证对社区要求的适当考虑来批准变更。

4.3.4. Existing Process Documents
4.3.4. 现有工艺文件

There are no applicable process documents.

没有适用的工艺文件。

4.4. Series-Wide Guidelines and Rules
4.4. 全系列指南和规则

The RFC Series style and content can be shaped by subject matter expertise in document series editing. They are also informed by requirements by the using community. As long as the RFC Series is to remain coherent, there should be uniform style and content for RFCs across all streams. This includes, but is not limited to, acceptable language, use of references, and copyright rules.

RFC系列的风格和内容可以通过文档系列编辑中的主题专业知识形成。他们还可以了解使用社区的需求。只要RFC系列保持一致,所有流中的RFC都应该有统一的风格和内容。这包括但不限于可接受的语言、引用的使用和版权规则。

4.4.1. Definition
4.4.1. 释义

In principle, there should be a community consensus document (or set of documents) describing the content requirements for the RFC Series. In practice, some do exist, though some need reviewing and more may be needed over time.

原则上,应该有一个社区共识文件(或一组文件)来描述RFC系列的内容要求。在实践中,有些确实存在,但有些需要审查,随着时间的推移可能需要更多。

4.4.2. Operational Implementation
4.4.2. 业务执行

The RFC Editor is responsible for ensuring that the RFC Series guidelines are upheld within the RFC Series.

RFC编辑负责确保RFC系列指南在RFC系列中得到支持。

4.4.3. Process Change
4.4.3. 过程变更

When additions or changes are needed to series-wide definitions, the IAB will work with the RFC Editor and stream stakeholders to get community input and review. The IAB will approve changes by validating appropriate consideration of community requirements.

当需要添加或更改系列范围的定义时,IAB将与RFC编辑器和流涉众合作,以获取社区输入和审查。IAB将通过验证对社区要求的适当考虑来批准变更。

4.4.4. Existing Process Documents
4.4.4. 现有工艺文件

Existing series-wide rules and guidelines documents include:

现有系列范围的规则和指南文件包括:

o Instructions to RFC Authors (RFC 2223 [RFC2223], [RFC2223BIS])

o RFC作者须知(RFC22223[RFC2223],[RFC2223BIS])

o Copyright and intellectual property rules (RFC 3978 [RFC3978] and RFC 4748 [RFC4748])

o 版权和知识产权规则(RFC 3978[RFC3978]和RFC 4748[RFC4748])

o Normative references (RFC 3967 [RFC3967] and RFC 4897 [RFC4897])

o 规范性参考文件(RFC 3967[RFC3967]和RFC 4897[RFC4897])

5. RFC Streams
5. RFC流

Various contributors provide input to the RFC Series. These contributors come from several different communities, each with its own defined process for approving documents that will be published by the RFC Editor. This is nothing new; however, over time the various communities and document requirements have grown and separated. In order to promote harmony in discussing the collective set of requirements, it is useful to recognize each in their own space -- and they are referred to here as "streams".

各种贡献者为RFC系列提供输入。这些贡献者来自几个不同的社区,每个社区都有自己定义的流程,用于批准将由RFC编辑器发布的文档。这并不是什么新鲜事;然而,随着时间的推移,不同的需求和文档社区也在增长。为了在讨论集体需求时促进和谐,在各自的空间中识别每个需求是很有用的,在这里它们被称为“流”。

Note that by identifying separate streams, there is no intention of dividing them or undermining their management as one series. Rather, the opposite is true -- by clarifying the constituent parts, it is easier to make them work together without the friction that sometimes arises when discussing various requirements.

请注意,通过识别单独的流,并不打算将它们分割或破坏它们作为一个系列的管理。相反,事实正好相反——通过澄清组成部分,可以更容易地使它们协同工作,而不会出现讨论各种需求时有时会出现的摩擦。

The subsections below identify the streams that exist today. There is no immediate expectation of new streams being created and it is preferable that new streams NOT be created. Creation of streams and all policies surrounding general changes to the RFC Series are discussed above in Section 4.

下面的小节确定了当前存在的流。没有立即创建新流的预期,最好不要创建新流。上文第4节讨论了围绕RFC系列的一般更改创建流和所有策略。

5.1. RFC Approval Processes
5.1. RFC批准流程

Processes for approval of documents (or requirements) for each stream are defined by the community that defines the stream. The IAB is charged with the role of verifying that appropriate community input has been sought and that the changes are consistent with the RFC Series mission and this overall framework.

每个流的文档(或需求)审批流程由定义该流的社区定义。IAB负责验证是否已寻求适当的社区投入,以及变更是否符合RFC系列任务和该总体框架。

The RFC Editor is expected to publish all documents passed to it after appropriate review and approval in one of the identified streams.

RFC编辑器应在经过适当审查和批准后,在其中一个确定的流中发布传递给它的所有文档。

5.1.1. IETF Document Stream
5.1.1. IETF文件流

The IETF document stream includes IETF WG documents as well as "individual submissions" sponsored by an IESG area director. Any document being published as part of the IETF standards process must follow this stream -- no other stream can approve Standards-Track or Best Current Practice (BCP) RFCs.

IETF文件流包括IETF工作组文件以及IESG区域主管赞助的“个人提交”。作为IETF标准过程的一部分发布的任何文件都必须遵循此流程——任何其他流程都不能批准标准跟踪或最佳现行做法(BCP)RFC。

Approval of documents in the IETF stream is defined by

IETF流中文件的批准由

o the IETF standards process (RFC 2026 [RFC2026] and its successors).

o IETF标准流程(RFC 2026[RFC2026]及其后续版本)。

o the IESG process for sponsoring individual submissions [SPONSOR]).

o IESG赞助个人提交的流程[赞助商])。

Changes to the approval process for this stream are made by updating the IETF standards process documents.

通过更新IETF标准流程文件对该流程的批准流程进行更改。

5.1.2. IAB Document Stream
5.1.2. 文件流

The IAB defines the processes by which it approves documents in its stream. Consistent with the above, any documents that the IAB wishes to publish as part of the IETF Standards Track (Standards or BCPs) are subject to the approval processes referred to in Section 5.1.1.

IAB定义了审批流中文档的流程。与上述内容一致,IAB希望作为IETF标准跟踪(标准或BCP)的一部分发布的任何文件均应遵守第5.1.1节中提及的批准流程。

The review and approval process for documents in the IAB stream is described in

IAB流中文件的审查和批准流程如中所述

o the IAB process for review and approval of its documents (RFC 4845 [RFC4845]).

o IAB文件审查和批准流程(RFC 4845[RFC4845])。

5.1.3. IRTF Document Stream
5.1.3. 文件流

The IRTF is chartered as an activity of the IAB. With the approval of the IAB, the IRTF may publish and update a process for publication of its own, non-IETF Standards-Track, documents.

IRTF被特许作为IAB的一项活动。经IAB批准,IRTF可发布和更新其自身非IETF标准跟踪文件的发布流程。

The review and approval process for documents in the IRTF stream is described in

IRTF流中文件的审查和批准流程如中所述

o IRTF Research Group RFCs [IRTF-DOCS].

o IRTF研究小组RFCs[IRTF-DOCS]。

5.1.4. Independent Submission Stream
5.1.4. 独立提交流

The RFC Series has always served a broader Internet technical community than the IETF. The "Independent Submission" stream is defined to provide review and (possible) approval of documents that are outside the scope of the streams identified above.

RFC系列始终服务于比IETF更广泛的互联网技术社区。“独立提交”流程的定义是对上述流程范围之外的文件进行审查和(可能的)批准。

Generally speaking, approval of documents in this stream falls under the purview of the RFC Editor, and the RFC Editor seeks input to its review from the IESG.

一般来说,此流程中文档的批准属于RFC编辑器的权限,RFC编辑器寻求IESG对其审查的输入。

The process for reviewing and approving documents in the Independent Submission stream is defined by

审查和批准独立提交流中文件的流程由

o Independent Submissions to the RFC Editor (RFC 4846 [RFC4846]).

o 独立提交给RFC编辑(RFC 4846[RFC4846])。

o The IESG and RFC Editor Documents: Procedures (RFC 3932 [RFC3932]).

o IESG和RFC编辑器文档:程序(RFC 3932[RFC3932])。

5.2. RFC Technical Publication Requirements
5.2. RFC技术出版物要求

The Internet engineering and research community has not only grown, it has become more diverse, and sometimes more demanding. The IETF, as a standards-developing organization, has publication requirements that extend beyond those of an academic journal. The IAB does not have the same interdependence with IANA assignments as the IETF stream does. Therefore, there is the need to both codify the publishing requirements of each stream, and endeavor to harmonize them to the extent that is reasonable.

互联网工程和研究界不仅发展壮大,而且变得更加多样化,有时甚至要求更高。IETF作为一个标准开发组织,其出版要求超出了学术期刊的要求。IAB与IANA分配的相互依赖性不同于IETF流。因此,有必要对每个流的发布需求进行编码,并努力在合理的范围内协调它们。

Therefore, it is expected that the community of effort behind each document stream will outline their technical publication requirements.

因此,预计每个文件流背后的工作社区将概述其技术出版要求。

As part of the RFC Editor oversight, the IAB must agree that the requirements are consistent with and implementable as part of the RFC Editor activity.

作为RFC编辑器监督的一部分,IAB必须同意这些要求与RFC编辑器活动一致,并可作为RFC编辑器活动的一部分实施。

5.2.1. IETF Documents
5.2.1. IETF文件

The requirements for this stream are defined in RFC 4714 [RFC4714].

RFC 4714[RFC4714]中定义了该流的要求。

5.2.2. IAB Documents
5.2.2. IAB文件

Although they were developed for the IETF standards process, the IAB will identify the applicable requirements in RFC 4714 for its stream.

尽管它们是为IETF标准过程开发的,但IAB将在RFC 4714中确定其流的适用要求。

If the IAB elects to define other requirements, they should deviate minimally from those (in an effort to keep the collective technical publication requirements reasonably managed by one technical publisher).

如果IAB选择定义其他要求,则应尽量减少与这些要求的偏差(努力使集体技术出版物要求由一家技术出版商合理管理)。

5.2.3. IRTF Documents
5.2.3. IRTF文件

Although they were developed for the IETF standards process, the IRTF will identify the applicable requirements in RFC 4714 for its stream.

尽管它们是为IETF标准过程开发的,但IRTF将在RFC 4714中确定其流的适用要求。

If the IRTF elects to define other requirements, they should deviate minimally from those (in an effort to keep the collective technical

如果IRTF选择定义其他要求,则应尽量减少与这些要求的偏差(以保持集体技术要求)

publication requirements reasonably managed by one technical publisher).

由一家技术出版商合理管理的出版要求)。

5.2.4. Independent Submissions
5.2.4. 独立意见书

Although they were developed for the IETF standards process, the RFC Editor will identify the applicable requirements in RFC 4714 for its stream.

尽管它们是为IETF标准过程开发的,但RFC编辑器将在RFC 4714中确定其流的适用需求。

If the RFC Editor elects to define other requirements, they should deviate minimally from those (in an effort to keep the collective technical publication requirements reasonably managed by one technical publisher).

如果RFC编辑选择定义其他要求,他们应尽量少偏离这些要求(努力使集体技术出版物要求由一家技术出版商合理管理)。

6. Security Considerations
6. 安全考虑

The processes for the publication of documents must prevent the introduction of unapproved changes. Since the RFC Editor maintains the index of publications, sufficient security must be in place to prevent these published documents from being changed by external parties. The archive of RFC documents, any source documents needed to recreate the RFC documents, and any associated original documents (such as lists of errata, tools, and, for some early items, non-machine readable originals) need to be secured against failure of the storage medium and other similar disasters.

文件发布流程必须防止引入未经批准的更改。由于RFC编辑器维护出版物的索引,因此必须有足够的安全性,以防止外部各方更改这些已发布的文档。RFC文档的存档、重新创建RFC文档所需的任何源文档以及任何相关的原始文档(例如勘误表、工具列表,对于某些早期项目,还有非机器可读的原始文档)都需要进行保护,以防存储介质故障和其他类似灾难。

7. IAB Members at the Time of Approval
7. 批准时的IAB成员

Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang

Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang

8. Informative References
8. 资料性引用

[BCP101] Austein, R. and B. Wijnen, "Structure of the IETF Administrative Support Activity (IASA)", RFC 4071, BCP 101, April 2005.

[BCP101]Austein,R.和B.Wijnen,“IETF行政支持活动(IASA)的结构”,RFC 4071,BCP 101,2005年4月。

[IABCHARTER] Carpenter, B., "Charter of the Internet Architecture Board (IAB)", RFC 2850, May 2000.

[IABCHARTER]Carpenter,B.,“互联网架构委员会(IAB)章程”,RFC 28502000年5月。

[IRTF-DOCS] Falk, A., "IRTF Research Group RFCs", Work in Progress, February 2006.

[IRTF-DOCS]Falk,A.,“IRTF研究小组RFCs”,进展中的工作,2006年2月。

[RFC1358] Chapin, L., "Charter of the Internet Architecture Board (IAB)", RFC 1358, August 1992.

[RFC1358]Chapin,L.“互联网架构委员会(IAB)章程”,RFC13581992年8月。

[RFC1601] Huitema, C., "Charter of the Internet Architecture Board (IAB)", RFC 1601, March 1994.

[RFC1601]Huitema,C.,“互联网架构委员会(IAB)章程”,RFC1601,1994年3月。

[RFC2026] Bradner, S., Ed., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996.

[RFC2026]Bradner,S.,Ed.“互联网标准过程——第3版”,RFC 2026,1996年10月。

[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.

[RFC2223]Postel,J.和J.Reynolds,“RFC作者须知”,RFC 2223,1997年10月。

[RFC2223BIS] Reynolds, J., Ed. and R. Braden, Ed., "Instructions to Request for Comments (RFC) Authors", Work in Progress, August 2004.

[RFC2223BIS]Reynolds,J.,Ed.和R.Braden,Ed.,“征求意见(RFC)作者的说明”,正在进行的工作,2004年8月。

[RFC2555] Editor, RFC., "30 Years of RFCs", RFC 2555, April 1999.

[RFC2555]RFC.编辑,“RFC的30年”,RFC2551999年4月。

[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", RFC 3932, October 2004.

[RFC3932]Alvestrand,H.,“IESG和RFC编辑文件:程序”,RFC 3932,2004年10月。

[RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level", RFC 3967, December 2004.

[RFC3967]Bush,R.和T.Narten,“澄清标准跟踪文件何时可以规范地引用较低级别的文件”,RFC 3967,2004年12月。

[RFC3978] Bradner, S., Ed., "IETF Rights in Contributions", RFC 3978, March 2005.

[RFC3978]Bradner,S.,编辑,“IETF在贡献中的权利”,RFC 3978,2005年3月。

[RFC4693] Alvestrand, H., "IETF Operational Notes", RFC 4693, October 2006.

[RFC4693]Alvestrand,H.,“IETF操作说明”,RFC4693,2006年10月。

[RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical Publication Service", RFC 4714, October 2006.

[RFC4714]Mankin,A.和S.Hayes,“IETF技术出版服务的要求”,RFC 4714,2006年10月。

[RFC4748] Bradner, S., Ed., "RFC 3978 Update to Recognize the IETF Trust", RFC 4748, October 2006.

[RFC4748]Bradner,S.,Ed.,“RFC 3978更新以识别IETF信任”,RFC 4748,2006年10月。

[RFC4845] Daigle, L., "Process for Publication of IAB RFCs", RFC 4845, July 2007.

[RFC4845]Daigle,L.,“IAB RFC的出版过程”,RFC 48452007年7月。

[RFC4846] Klensin, J. and D. Thaler, "Independent Submissions to the RFC Editor", RFC 4846, July 2007.

[RFC4846]Klensin,J.和D.Thaler,“向RFC编辑提交的独立意见”,RFC 48462007年7月。

[RFC4897] Klensin, J., "Handling Normative References to Standards Track Documents", BCP 97, RFC 4897, June 2007.

[RFC4897]Klensin,J.,“处理标准跟踪文件的规范性引用”,BCP 97,RFC 4897,2007年6月。

[SPONSOR] Arkko, J., "Guidance on Area Director Sponsoring of Documents", ION, October 2006.

[发起人]Arkko,J.,“关于区域主管赞助文件的指导”,ION,2006年10月。

Appendix A. A Retrospective of IAB Charters and RFC Editor
附录A.IAB章程和RFC编辑回顾

With this document, the IAB's role with respect to the RFC Series and the RFC Editor is being adjusted to work more directly with the RFC Editor and provide oversight to ensure the RFC Series mission principles and communities' input are addressed appropriately.

通过本文件,IAB在RFC系列和RFC编辑方面的角色正在调整,以更直接地与RFC编辑合作,并提供监督,以确保适当处理RFC系列任务原则和社区的输入。

This section provides an overview of the role of the IAB with respect to the RFC Editor as it has been presented in IAB Charter RFCs dating back to 1992. The point of this section is that the IAB's role has historically been substantive -- whether it is supposed to be directly responsible for the RFC Series' editorial management (circa 1992, Appendix A.1), or appointment of the RFC Editor organization and approval of general policy (circa 2000, Appendix A.3).

本节概述了IAB在RFC编辑方面的作用,正如1992年IAB特许RFC中所述。本节的要点是,IAB的角色在历史上一直是实质性的——无论是直接负责RFC系列的编辑管理(约1992年,附录A.1),还是任命RFC编辑组织和批准一般政策(约2000年,附录A.3)。

A.1. 1992
A.1. 1992

[RFC1358] says:

[RFC1358]表示:

[The IAB's] responsibilities shall include: [...] (2) The editorial management and publication of the Request for Comments (RFC) document series, which constitutes the archival publication series for Internet Standards and related contributions by the Internet research and engineering community.

[IAB]的职责应包括:[……](2)编辑管理和出版征求意见(RFC)文件系列,该系列文件构成互联网标准和互联网研究与工程界相关贡献的档案出版物系列。

A.2. 1994
A.2. 1994

[RFC1601] says:

[RFC1601]表示:

[The IAB's] responsibilities under this charter include:

【IAB】在本章程下的责任包括:

(d) RFC Series and IANA

(d) RFC系列与IANA

The IAB is responsible for editorial management and publication of the Request for Comments (RFC) document series, and for administration of the various Internet assigned numbers.

IAB负责编辑管理和发布征求意见(RFC)文件系列,并负责管理各种互联网分配编号。

which it elaborates as

它解释为

2.4 RFC Series and Assigned Numbers

2.4 RFC系列和指定编号

The RFC Series constitutes the archival publication channel for Internet Standards and for other contributions by the Internet research and engineering community. The IAB shall select an RFC Editor, who shall be responsible for the editorial management and publication of the RFC Series.

RFC系列构成了互联网标准和互联网研究与工程界其他贡献的档案出版渠道。IAB应选择一名RFC编辑,负责RFC系列的编辑管理和出版。

A.3. 2000
A.3. 2000

[IABCHARTER], which is the most recent IAB Charter document, says:

【IAB章程】是IAB最新的章程文件,其中规定:

(d) RFC Series and IANA

(d) RFC系列与IANA

The RFC Editor executes editorial management and publication of the IETF "Request for Comment" (RFC) document series, which is the permanent document repository of the IETF. The RFC Series constitutes the archival publication channel for Internet Standards and for other contributions by the Internet research and engineering community. RFCs are available free of charge to anyone via the Internet. The IAB must approve the appointment of an organization to act as RFC Editor and the general policy followed by the RFC Editor.

RFC编辑器执行IETF“征求意见”(RFC)文件系列的编辑管理和发布,该文件系列是IETF的永久性文件存储库。RFC系列构成了互联网标准和互联网研究与工程界其他贡献的档案出版渠道。任何人都可以通过互联网免费获得RFC。IAB必须批准任命一个组织担任RFC编辑,以及RFC编辑遵循的一般政策。

Authors' Addresses

作者地址

Leslie L. Daigle (editor)

莱斯利·戴格尔(编辑)

   EMail: ledaigle@cisco.com, leslie@thinkingcat.com
        
   EMail: ledaigle@cisco.com, leslie@thinkingcat.com
        

IAB

IAB

   EMail: iab@iab.org
   URI:   http://www.iab.org/
        
   EMail: iab@iab.org
   URI:   http://www.iab.org/
        

Full Copyright Statement

完整版权声明

Copyright (C) The IETF Trust (2007).

版权所有(C)IETF信托基金(2007年)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件及其包含的信息以“原样”为基础提供,贡献者、他/她所代表或赞助的组织(如有)、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Intellectual Property

知识产权

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。