Network Working Group H. Alvestrand
Request for Comments: 4693 Google
Category: Experimental October 2006
Network Working Group H. Alvestrand
Request for Comments: 4693 Google
Category: Experimental October 2006
IETF Operational Notes
IETF操作说明
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes a new document series intended for use as a repository for IETF operations documents, which should be more ephemeral than RFCs, but more referenceable than Internet-Drafts, and with more clear handling procedures than a random Web page.
本文档描述了一个新的文档系列，旨在用作IETF操作文档的存储库，它应该比RFC更短暂，但比Internet草稿更具参考性，并且比随机网页具有更清晰的处理过程。
It proposes to establish this series as an RFC 3933 process experiment.
它建议将该系列建立为RFC 3933工艺试验。
Table of Contents
目录
1. Introduction ....................................................2
2. A Description of the ION Mechanism ..............................2
2.1. Properties of an ION .......................................2
2.2. ION Approval ...............................................3
2.3. Draft IONs .................................................3
2.4. The ION Store ..............................................4
3. Proposed Initial IONs ...........................................4
4. Success Criteria and Sunset Period ..............................5
5. Background and Motivation .......................................6
6. IANA Considerations .............................................7
7. Security Considerations .........................................8
8. Acknowledgements ................................................8
9. References ......................................................8
9.1. Normative References .......................................8
9.2. Informative References .....................................8
1. Introduction ....................................................2
2. A Description of the ION Mechanism ..............................2
2.1. Properties of an ION .......................................2
2.2. ION Approval ...............................................3
2.3. Draft IONs .................................................3
2.4. The ION Store ..............................................4
3. Proposed Initial IONs ...........................................4
4. Success Criteria and Sunset Period ..............................5
5. Background and Motivation .......................................6
6. IANA Considerations .............................................7
7. Security Considerations .........................................8
8. Acknowledgements ................................................8
9. References ......................................................8
9.1. Normative References .......................................8
9.2. Informative References .....................................8
This document describes a new document series, called the IETF Operational Notes, or IONs.
本文档描述了一个新的文档系列，称为IETF操作说明，或IONs。
This document series is intended to capture the set of procedures that the IETF follows, but for which the RFC process is an inappropriate documentation vehicle.
本系列文件旨在捕获IETF遵循的一组程序，但RFC过程是不合适的文件载体。
The document series defined here does not modify the IETF process rules that are defined in currently valid BCP documents.
此处定义的文档系列不会修改当前有效的BCP文档中定义的IETF过程规则。
The document series is a process experiment according to RFC 3933 [RFC3933].
本系列文件是根据RFC 3933[RFC3933]进行的工艺试验。
An ION is a document with a certain set of attributes ("front page matter"). This specification does not place any limits on what else an ION can contain.
ION是具有特定属性集的文档（“头版内容”）。本规范未对离子所能包含的其他物质进行任何限制。
An ION has the following attributes:
离子具有以下属性：
o A name, which is usable as the filename of the document
o 名称，可用作文档的文件名
o A title
o 头衔
o A date of approval
o 批准日期
o An identification of the body that approved this version
o 认证此版本的机构的标识
The format of the document is not restricted by this document. It's suggested that there be an ION that describes expectations for ION formats.
本文件不限制本文件的格式。建议有一个描述离子格式期望的离子。
An ION is a versioned document. When a new ION is issued with the same name, it obsoletes the previous version. When one desires to retire an ION, one issues an ION saying "This document name is now obsolete".
ION是一个版本化的文档。当一个新的离子以相同的名称发布时，它将淘汰以前的版本。当一个人想要退出一个ION时，他会发布一个ION，上面写着“这个文档名现在已经过时了”。
The ION name + the approval date forms a stable identifier for one particular version of an ION; once it is published, it shall never be changed, although it may be withdrawn (see below).
离子名称+批准日期构成离子特定版本的稳定标识符；一旦发布，不得更改，尽管可以撤销（见下文）。
The properties list does not include a "category"; while the set of documents that might be IONs is extremely wide, we do not know yet which categories could make sense. The question of categories might get revisited at the end of the experiment period.
属性列表不包括“类别”；虽然可能是离子的文档集非常广泛，但我们还不知道哪些类别是有意义的。在实验结束时，可能会重新讨论类别问题。
Procedurally, an ION has the formal authority of a statement from its approving body. This means that an ION cannot change those procedures of the IETF that are documented via the BCP series, since the BCP series represents a determination of IETF consensus.
从程序上讲，一个委员会拥有来自其批准机构的声明的正式授权。这意味着离子不能改变通过BCP系列记录的IETF程序，因为BCP系列代表IETF共识的确定。
An ION is always approved by some body. The IESG is granted authority by this document over the practical management of the series and the definition of detailed processes and rules associated with it.
离子总是被某个机构认可的。本文件授予IESG对系列的实际管理以及与之相关的详细流程和规则的定义的权限。
The IESG, the IAB, and IAOC are given the right to approve IONs by this document. The IESG, IAB, or IAOC may decide that other groups or roles should be given the right to approve IONs.
IESG、IAB和IAOC有权批准本文件规定的变更。IESG、IAB或IAOC可决定给予其他小组或角色批准授权。
The ION-approving groups are expected to issue IONs related to their own areas of responsibility, and to use common sense when IONs are needed where it isn't obvious who's responsible for them.
预计离子批准小组将发布与其职责范围相关的离子，并在不清楚谁对离子负责的情况下，在需要离子时使用常识。
An updated ION will normally be approved by the same body that approved the previous version, or by another body with the approval of the previously-approving body. In case of conflict, or when the previous body no longer exists, the IESG will decide who gets to approve an updated ION.
更新的ION通常由批准先前版本的同一机构批准，或由获得先前批准机构批准的另一机构批准。如果发生冲突，或当前一机构不再存在时，IESG将决定由谁批准更新的信息。
A decision by any other body than the IESG to approve an ION can be appealed to the IESG, in which case the IESG can nullify the approval. A decision of the IESG can be appealed using the common IETF appeals procedure, except that an IESG decision to nullify an IAB decision to approve an ION cannot be appealed to the IAB.
IESG以外的任何其他机构批准离子的决定可向IESG提出上诉，在这种情况下，IESG可取消批准。IESG的决定可以使用通用IETF上诉程序进行上诉，但IESG取消IAB批准ION决定的决定不能向IAB上诉。
In the case that the IESG ceases to exist, its successors or assignees will take over the tasks given to the IESG in this document.
如果IESG不复存在，其继承人或受让人将接管本文件中授予IESG的任务。
There is no requirement that an ION will be published as a draft before publication. This will, however, be desirable in many cases, and thus, this document describes the properties and procedures for handling draft IONs.
没有要求在发布之前将一个离子作为草稿发布。然而，这在许多情况下都是可取的，因此，本文件描述了处理拔模桩的特性和程序。
Draft IONs shall have, instead of an approval date and an identification of the body that approved it, information about:
草案应包含以下信息，而不是批准日期和批准机构的标识：
o The word "DRAFT", prominently displayed
o 突出显示“草稿”一词
o The publication date and time
o 出版日期和时间
o The approval date of the document it is intended to update (if any)
o 拟更新文件的批准日期（如有）
o The body that is intended to approve this version
o 旨在批准此版本的机构
o The appropriate forum for discussion of this draft (if any)
o 讨论本草案的适当论坛（如有）
All approved IONs are archived, in all their versions, and made publicly available from resources operated by the IETF secretariat. The store should be reachable by common methods like HTTP and FTP, and should offer both easy access to the "current" version of all IONs and bulk download of all IONs, all versions.
所有经批准的离子都以其所有版本存档，并从IETF秘书处运营的资源中公开提供。商店应该可以通过HTTP和FTP等常用方法访问，并且应该提供对所有离子的“当前”版本的轻松访问和所有离子、所有版本的批量下载。
This document does not constrain the form of the ION Store, but mandates that there be a public one.
本文档不限制离子存储的形式，但要求有一个公共存储。
Public draft IONs are published separately from the approved IONs. Old versions may be published in the draft store and must be kept in a version management system for the duration of the experiment. Experience will show what the best policy for draft retention is if the series is made permanent.
公开征求意见稿与批准的征求意见稿分开发布。旧版本可以在草稿库中发布，并且在实验期间必须保存在版本管理系统中。经验将表明，如果该系列是永久性的，保留草稿的最佳策略是什么。
The following IONs should be created as soon as possible after this document is published, to give the details of the maintenance of the ION series, in order to bootstrap the process:
本文件发布后，应尽快创建以下离子，以提供离子系列维护的详细信息，以便引导该过程：
o The ION Format Guide
o 离子格式指南
o The ION Store Description
o 离子存储描述
The following list of documents, some of which currently exist, provides examples of documents that could be converted to IONs. This is not a binding recommendation, but gives examples of what IONs can be good for.
以下文档列表（其中一些文档目前已存在）提供了可转换为虚拟机的文档示例。这不是一个有约束力的建议，但给出了离子的用途示例。
o The I-D publishing procedure
o I-D发布程序
o The checklist for I-D submission to the IESG (formerly known as id-nits)
o 提交给IESG的I-D检查表（以前称为id nits）
o Procedures for spam control on IETF mailing lists
o IETF邮件列表上的垃圾邮件控制程序
o Procedures for requesting a WG meeting slot
o 申请工作组会议时段的程序
o Procedures for IETF minutes
o IETF会议记录的程序
o Procedures for IESG meeting minutes
o IESG会议记录的程序
Once the ION series is permanent, the existence of the ION series may cause the following documents to be split into a "policy and principles" BCP and a "procedures and boilerplate" document published as ION:
一旦ION系列是永久性的，ION系列的存在可能会导致以下文件分为“政策和原则”BCP和作为ION发布的“程序和样板”文件：
o IETF Rights in Documents (currently BCP 78) RFC 3978 [RFC3978]
o 文件中的IETF权利（目前为BCP 78）RFC 3978[RFC3978]
o IETF Rights in Technology (currently BCP 79) RFC 3979 [RFC3979]
o IETF技术权利（目前为BCP 79）RFC 3979[RFC3979]
o IETF mailing list management (currently RFC 3005 [RFC3005], BCP 45, RFC 3683 [RFC3683], BCP 83, and RFC 3934 [RFC3934], BCP 94)
o IETF邮件列表管理（目前为RFC 3005[RFC3005]、BCP 45、RFC 3683[RFC3683]、BCP 83和RFC 3934[RFC3934]、BCP 94）
If someone wishes to do such a split while the experiment is running, the BCPs cannot refer to the "procedures" documents as IONs, since the concept of an ION may go away. In that case, any procedures removed from a BCP must either be reinstated or otherwise stored as a permanently available reference.
如果有人希望在实验进行期间进行这样的拆分，BCP不能将“程序”文件称为离子，因为离子的概念可能会消失。在这种情况下，从BCP中删除的任何过程都必须恢复或以其他方式存储为永久可用的引用。
This experiment is expected to run for a period of 12 months, starting from the date of the first ION published using this mechanism. At the end of the period, the IESG should issue a call for comments from the community, asking for people to state their agreement to one of the following statements (or a suitable reformulation thereof):
该实验预计将持续12个月，从使用该机制发布第一个离子的日期开始。在期限结束时，IESG应发出征求社区意见的呼吁，要求人们声明他们同意以下声明之一（或适当的重新表述）：
1. This document series has proved useful, and should be made permanent
1. 事实证明，本系列文件很有用，应该永久保存
2. This document series is less useful than the equivalent information in RFCs and informal Web pages, and should be abandoned
2. 本文档系列不如RFC和非正式网页中的同等信息有用，应该放弃
3. We cannot decide yet; the experiment should continue
3. 我们还不能决定；实验应该继续
The author believes that establishing objective metrics for the success or failure of this experiment is not a worthwhile exercise; the success or failure will be readily apparent in the community's attitudes towards the series.
作者认为，为这个实验的成功或失败建立客观的衡量标准是不值得的；社会人士对该系列剧的态度，很容易看出它的成败。
If the feedback reveals a community consensus for keeping the series, the IESG may choose to create a new BCP RFC containing the information herein, suitably modified by experience.
如果反馈表明社区一致同意保留该系列，IESG可以选择创建一个新的BCP RFC，其中包含本文中的信息，并根据经验进行适当修改。
If the IESG decides that the feedback warrants terminating the series, the repository will be closed for new documents, and the existing ION documents will be returned to having the same status as any other Web page or file on the IETF servers -- this situation will closely resemble the situation before the experiment started.
如果IESG认为反馈保证终止该系列，则存储库将关闭以获取新文档，现有的ION文档将恢复到与IETF服务器上的任何其他网页或文件相同的状态——这种情况与实验开始前的情况非常相似。
The IETF is an open organization, which means (among other things) that there are always newcomers coming in to learn how to perform work; this places a requirement on the organization to document its processes and procedures in an accessible manner.
IETF是一个开放的组织，这意味着（除其他外）总是有新来者来学习如何执行工作；这就要求组织以可访问的方式记录其过程和程序。
The IETF is also a large organization, which means that when procedures change, there are a number of people who will like to know of the change, to figure out what has changed, and possibly to protest or appeal the change if they disagree with it.
IETF也是一个大型组织，这意味着当程序发生变化时，有许多人希望了解变化，找出发生了什么变化，如果他们不同意，可能会抗议或上诉。
At the present time (spring 2006), there are three kinds of documents used for IETF documentation of its operations and procedures:
目前（2006年春季），有三种文件用于IETF操作和程序的文件编制：
o BCP and Informational RFCs, which require an IETF consensus call for BCP, approval by the IESG, and usually a great deal of debate and effort to change, and which bind up editing resources in the final edit stage, as well as being limited (in practice) to ASCII. The BCP number forms a means of having a stable reference for new versions of a document, but an updated Info RFC has a completely different identifier from the RFC that it updates; "updates/ obsoletes" links can give some of the same information, but can also be quite confusing to follow.
o BCP和信息RFC，需要IETF协商一致要求BCP，IESG批准，通常需要大量辩论和努力进行更改，在最终编辑阶段会占用编辑资源，并且（在实践中）限于ASCII。BCP编号形成了一种对文档新版本具有稳定参考的方式，但更新后的信息RFC与更新后的RFC具有完全不同的标识符；“更新/淘汰”链接可以提供一些相同的信息，但也可能让人很困惑。
o Web pages, which can be changed without notice, provide very little ability to track changes, and have no formal standing -- confusion is often seen about who has the right to update them, what the process for updating them is, and so on. It is hard when looking at a Web page to see whether this is a current procedure, a procedure introduced and abandoned, or a draft of a future procedure. For certain procedures, their informal documentation
o 可以不经通知而更改的网页提供的跟踪更改的能力非常小，并且没有正式的地位——人们经常会对谁有权更新网页、更新网页的过程是什么等感到困惑。在查看网页时，很难确定这是当前程序、引入和放弃的程序，还是未来程序的草案。对于某些程序，其非正式文件
in the "IESG Guide" wiki has partially clarified this situation but has no official status.
在“IESG指南”中，维基部分澄清了这种情况，但没有正式身份。
o "floating" Internet-Drafts, which are frequently updated, in a trackable manner, but have no approval mechanism, are limited (in practice) to ASCII format, and whose use as semi-permanent documents clutters up their use as 6-month temporary working documents.
o “浮动”互联网草稿经常以可跟踪的方式更新，但没有批准机制，在实践中仅限于ASCII格式，其作为半永久性文件的使用使其作为6个月临时工作文件的使用变得杂乱无章。
This note introduces a new series that seems to fulfil the requirements for "something in between":
本说明介绍了一个新系列，该系列似乎满足“介于两者之间”的要求：
o Unlike RFCs, they can be produced without a post-editing stage, they can be in any format the controllers of the series choose (allowing web pages with hyperlinks, which is an advantage for newcomers).
o 与RFC不同的是，它们可以不经过后期编辑阶段就制作出来，可以是该系列控制器选择的任何格式（允许带有超链接的网页，这对新手来说是一个优势）。
o Also unlike RFCs, they can be produced by any body that the IESG gives the right to use the mechanism; this allows certain procedures to be updated without having to wait for the IESG approval cycle.
o 与RFC不同的是，IESG授予使用该机制权利的任何机构都可以生产RFC；这允许在不必等待IESG批准周期的情况下更新某些程序。
o Unlike Internet-Drafts, they have an explicit approval step -- this allows a reader to easily see the difference between an idea and an operational procedure.
o 与互联网不同的是，他们可以很容易地看到草案和操作步骤之间的差异。
o Unlike Web pages, there is an explicit mechanism for finding "all current versions", and a mechanism for tracking the history of a document.
o 与网页不同，有一种查找“所有当前版本”的显式机制，以及一种跟踪文档历史记录的机制。
The "author" attribute has quite deliberately been omitted from the required property list. While there may be many cases where identifying an author is a Good Thing, the responsibility for an approved ION rests with the approving body.
“author”属性被故意从所需的属性列表中省略。虽然在许多情况下，确认作者是件好事，但批准机构对批准的授权负有责任。
Note: This proposal is NOT intended to affect the standards track in any way -- a side effect may be to reduce the number of "process BCPs" emitted, but this has no direct bearing on the IETF's technical specifications. It is therefore not within the scope of the NEWTRK working group.
注：本提案无意以任何方式影响标准轨道——副作用可能是减少排放的“过程BCP”数量，但这与IETF的技术规范没有直接关系。因此，它不在NEWTRK工作组的范围之内。
IONs will not include protocol specifications, so IONs will make no requests for IANA actions. IANA will not need to review all IONs.
IONs将不包括协议规范，因此IONs不会请求IANA操作。IANA将不需要审查所有离子。
This document makes no requests of IANA either.
本文件也未向IANA提出任何要求。
IONs will not include protocol specifications, so shouldn't have much need to talk about security the way RFCs do.
离子将不包括协议规范，因此不需要像RFC那样谈论安全性。
Many people have contributed over the years to the ideas that I have tried to express here.
多年来，许多人对我在这里试图表达的观点做出了贡献。
I'm in particular indebted to John Klensin for his work on trying to find a balance between formalism and flexibility in the IETF process, and for his earlier attempts at creating such a document series as an adjunct to the "ISD" effort, and for his many valuable comments on this document.
在约翰·克莱姆的早期作品中，他试图在形式主义和附加主义之间找到一个平衡点。
In addition, Dave Crocker, Spencer Dawkins, Jeff Hutzelman, Sam Hartman, and David Black (gen-ART reviewer) provided valuable comments at Last Call time.
此外，戴夫·克罗克、斯宾塞·道金斯、杰夫·哈泽尔曼、山姆·哈特曼和大卫·布莱克（gen ART reviewer）在最后一次通话时提供了宝贵的意见。
[RFC3933] Klensin, J. and S. Dawkins, "A Model for IETF Process Experiments", BCP 93, RFC 3933, November 2004.
[RFC3933]Klensin，J.和S.Dawkins，“IETF过程实验的模型”，BCP 93，RFC 3933，2004年11月。
[RFC3005] Harris, S., "IETF Discussion List Charter", BCP 45, RFC 3005, November 2000.
[RFC3005]Harris，S.，“IETF讨论列表章程”，BCP 45，RFC 3005，2000年11月。
[RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF mailing lists", BCP 83, RFC 3683, February 2004.
[RFC3683]Rose，M.，“撤销IETF邮件列表发布权的实践”，BCP 83，RFC 3683，2004年2月。
[RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the Management of IETF Mailing Lists", BCP 94, RFC 3934, October 2004.
[RFC3934]Wasserman，M.，“关于IETF邮件列表管理的RFC 2418更新”，BCP 94，RFC 3934，2004年10月。
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[RFC3978]Bradner，S.，“IETF在贡献中的权利”，BCP 78，RFC 3978，2005年3月。
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[RFC3979]Bradner，S.，“IETF技术中的知识产权”，BCP 79，RFC 3979，2005年3月。
Author's Address
作者地址
Harald Tveit Alvestrand Google Beddingen 10 N-7014 Trondheim Norway
挪威特隆赫姆哈拉尔德·特维特·阿尔韦斯特兰德谷歌贝丁根10 N-7014
EMail: harald@alvestrand.no
EMail: harald@alvestrand.no
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。