Independent Submission P. Eardley
Request for Comments: 6417 BT
Category: Informational L. Eggert
ISSN: 2070-1721 Nokia
M. Bagnulo
UC3M
R. Winter
NEC Europe
November 2011
Independent Submission P. Eardley
Request for Comments: 6417 BT
Category: Informational L. Eggert
ISSN: 2070-1721 Nokia
M. Bagnulo
UC3M
R. Winter
NEC Europe
November 2011
How to Contribute Research Results to Internet Standardization
如何为互联网标准化贡献研究成果
Abstract
摘要
The development of new technology is driven by scientific research. The Internet, with its roots in the ARPANET and NSFNet, is no exception. Many of the fundamental, long-term improvements to the architecture, security, end-to-end protocols and management of the Internet originate in the related academic research communities. Even shorter-term, more commercially driven extensions are oftentimes derived from academic research. When interoperability is required, the IETF standardizes such new technology. Timely and relevant standardization benefits from continuous input and review from the academic research community.
科学研究推动了新技术的发展。起源于ARPANET和NSFNet的互联网也不例外。互联网的体系结构、安全性、端到端协议和管理方面的许多根本性、长期性改进源自相关的学术研究社区。更短期、更商业化的扩展往往来自学术研究。当需要互操作性时，IETF将这种新技术标准化。及时和相关的标准化得益于学术研究界的持续投入和审查。
For an individual researcher, it can however be quite puzzling how to begin to most effectively participate in the IETF and arguably to a much lesser degree, the IRTF. The interactions in the IETF are much different than those in academic conferences, and effective participation follows different rules. The goal of this document is to highlight such differences and provide a rough guideline that will hopefully enable researchers new to the IETF to become successful contributors more quickly.
然而，对于个人研究人员来说，如何开始最有效地参与IETF，以及可以说是参与程度要小得多的IRTF，是一个相当令人费解的问题。IETF中的互动与学术会议中的互动大不相同，有效参与遵循不同的规则。本文件的目的是强调这些差异，并提供一个粗略的指南，希望使新加入IETF的研究人员能够更快地成为成功的贡献者。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6417.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6417.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
2. Is the IETF the Right Venue? ....................................4
3. How to Get the IETF to Start Work on Your Proposal? .............6
3.1. Identify the Right Part of the IETF ........................6
3.2. Build a Community ..........................................6
3.3. Outline Your Protocol ......................................7
3.4. Establish a New Working Group ..............................8
4. How to Increase the Chances that the IETF Successfully
Standardizes Your Proposal ......................................8
4.1. Commit Enough Time, Energy, and Perseverance ...............8
4.2. Be Open and Focus Out ......................................9
4.3. Seek Resolution, Not Perfection ...........................10
4.4. Implement .................................................10
5. Examples .......................................................11
5.1. Multipath TCP .............................................11
5.2. Congestion Exposure .......................................12
6. Security Considerations ........................................13
7. Acknowledgments ................................................13
8. Informative References .........................................13
1. Introduction ....................................................3
2. Is the IETF the Right Venue? ....................................4
3. How to Get the IETF to Start Work on Your Proposal? .............6
3.1. Identify the Right Part of the IETF ........................6
3.2. Build a Community ..........................................6
3.3. Outline Your Protocol ......................................7
3.4. Establish a New Working Group ..............................8
4. How to Increase the Chances that the IETF Successfully
Standardizes Your Proposal ......................................8
4.1. Commit Enough Time, Energy, and Perseverance ...............8
4.2. Be Open and Focus Out ......................................9
4.3. Seek Resolution, Not Perfection ...........................10
4.4. Implement .................................................10
5. Examples .......................................................11
5.1. Multipath TCP .............................................11
5.2. Congestion Exposure .......................................12
6. Security Considerations ........................................13
7. Acknowledgments ................................................13
8. Informative References .........................................13
In telecommunications, standards are essential. More often than not, technology interoperability requires an agreement on a single standard for a given problem. However, unlike most research, standards developments are driven by particular real-world problems and require solutions that are not only theoretically correct, but need to be implementable with state-of-the-art technology in a cost-effective manner, and must be incrementally deployable in the actual Internet by the involved stakeholders. In other words, standards should be both theoretically correct and practically applicable. In the academic world, the former is often more important than the latter!
在电信领域，标准至关重要。通常情况下，技术互操作性需要就给定问题的单一标准达成一致。然而，与大多数研究不同，标准开发是由特定的现实世界问题驱动的，需要的解决方案不仅在理论上是正确的，而且需要以经济高效的方式使用最先进的技术来实施，并且必须由相关的利益相关者在实际的互联网上逐步部署。换句话说，标准在理论上应该是正确的，在实践上也应该是适用的。在学术界，前者往往比后者更重要！
In the IETF, a practically applicable solution that has some well-defined and acceptable deficiencies trumps a theoretically complete and optimal solution that cannot be deployed. Likewise, a solution to an interesting theoretical problem that does not exist in the deployed Internet at large does not require urgent standardization. Finally, standardization oftentimes focuses on piecemeal improvements to existing technology in order to enhance secondary aspects, which does not excite an academic researcher looking to solve juicy problems.
在IETF中，具有明确定义和可接受缺陷的实际适用解决方案胜过无法部署的理论完整和最佳解决方案。同样，一个有趣的理论问题的解决方案并不存在于部署的互联网中，也不需要迫切的标准化。最后，标准化通常侧重于对现有技术的零碎改进，以增强次要方面，而这并不会激发寻求解决有趣问题的学术研究人员的兴趣。
These differences between academic research and Internet standardization are the main reason why many researchers initially struggle when they begin to participate in the IETF. Symptoms of this struggle occur, for example:
学术研究和互联网标准化之间的这些差异是许多研究人员开始参与IETF时遇到困难的主要原因。出现这种斗争的症状，例如：
o for ideas that are too far outside the IETF's areas of current work
o 对于那些远远超出IETF当前工作范围的想法
o for ideas that are too high-level for the IETF to begin protocol-level work on
o 对于IETF无法开始协议级工作的太高级别的想法
o for proposals that solve problems that are not expected to arise for a very long time
o 对于解决预计在很长时间内不会出现的问题的建议
o if there is a reluctance to give others a say in how a research idea is being made concrete, or giving over change control entirely
o 如果不愿意让他人对研究想法如何具体化发表意见，或者完全放弃对变化的控制
o if there is a feeling that the IETF "does not listen" to them or does not have "the right people"
o 如果感觉IETF“不听”他们的或没有“合适的人”
o if there seems to be no working group or other venue to bring the work to
o 如果似乎没有工作组或其他场所将工作带到
o if the researchers are not interested in topics such as security, performance, and operational management -- topics that the IETF will consider carefully
o 如果研究人员对安全、绩效和运营管理等议题不感兴趣，IETF将认真考虑的议题。
o when the process seems too time consuming
o 当这个过程似乎太耗时时
o when the researchers do not have the resources to keep the IETF effort active for an extended period of time
o 当研究人员没有资源使IETF工作在较长时间内保持活跃时
o if there is not a convincing enough argument for the IETF to start working on something, despite great simulation results
o 如果没有足够令人信服的理由让IETF开始工作，尽管仿真结果很好
o if the research idea is just not implementable in today's Internet
o 如果这个研究理念在今天的互联网上无法实现
This document attempts to give some basic advice that researchers might want to take into account when deciding to approach the IETF with their ideas, in order to improve their success probability. It is intended to complement the more general advice in [RFC4144] about "How to Gain Prominence and Influence in Standards Organizations". Other, more general advice and detailed explanations of the structure and inner workings of the IETF can be found in "The Tao of IETF" [RFC4677].
本文件试图给出一些基本建议，研究人员在决定使用他们的想法接近IETF时可能需要考虑这些建议，以提高他们的成功概率。它旨在补充[RFC4144]中关于“如何在标准组织中获得突出地位和影响力”的更一般性建议。关于IETF结构和内部工作原理的其他更一般的建议和详细解释，请参见“IETF之道”[RFC4677]。
The authors have been involved in several research projects, including collaborative ones, which have sought to standardize some of their results at the IETF, and we hope to pass on some advice (sometimes that we have learned the hard way!). The advice is split into three groups: before you approach the IETF; how to get the IETF to start work on your proposal; and finally how to increase the chances of success once work has begun.
作者参与了多个研究项目，包括合作项目，这些项目试图在IETF中标准化他们的一些结果，我们希望能传递一些建议（有时我们已经学到了艰苦的方法！）。建议分为三组：在你接触IETF之前；如何让IETF就您的提案开始工作；最后是如何在工作开始后增加成功的机会。
A researcher should consider whether the IETF is the right venue before bringing a proposal to it. A way to do so is to imagine that the IETF has standardized your proposal and it has been deployed, and ask yourself two questions:
一个研究者应该考虑IETF是否在提出建议之前是正确的地点。这样做的一种方式是想象IETF已经标准化了您的提案，并且已经部署，然后问自己两个问题：
1. How would the Internet be better?
1. 互联网将如何变得更好？
2. What Internet nodes would have been upgraded?
2. 哪些Internet节点会升级？
It is very important to have a clear explanation about the motivation for your proposal: what would its benefits be? What problem does it solve? Many ideas do not bring a clear benefit to the Internet in the near term (of course they may still be fine pieces of research!). In the past, the IETF has often developed protocols that ended up not being used, so it now thinks harder about the benefits before
对你的提议的动机有一个清晰的解释是非常重要的：它的好处是什么？它解决了什么问题？许多想法在短期内不会给互联网带来明显的好处（当然，它们可能仍然是很好的研究成果！）。在过去，IETF经常开发出最终未被使用的协议，因此它现在更仔细地考虑以前的好处
starting new work and makes sure that it solves a current, significant problem rather than one that may theoretically arise in the future. It is best to be specific about what improvement your proposal would make and the use cases in which this would be seen.
开始新的工作，确保它解决了当前的重大问题，而不是理论上可能在未来出现的问题。最好具体说明您的提案将做出哪些改进，以及在哪些用例中可以看到这些改进。
It is also important to have a simple description of what additions or changes are needed and to which nodes (be they end-hosts, routers, middleboxes, etc.). Is it substituting for an existing IETF protocol or supplementing one? Again, it is best to be specific: Do both ends need to adopt the new protocol? Can it fall back or interoperate with the existing IETF protocol? Do the "first movers" (the first nodes that include your protocol) get an improvement, or do the "last movers" gain most? What assumptions do you make about the network or host (perhaps that the host is multi-homed or there are no middleboxes on the path)? While thinking about these things, it is also worthwhile considering operational practices and business models. If you will likely break some of these, you will inevitably face some opposition in the IETF.
对需要添加或更改的内容以及节点（终端主机、路由器、中间盒等）进行简单描述也很重要。它是替代现有的IETF协议还是补充协议？同样，最好是具体一点：双方是否都需要通过新的协议？它是否可以回退或与现有IETF协议互操作？“第一个移动者”（包括您的协议的第一个节点）得到了改进，还是“最后一个移动者”得到了最多的改进？您对网络或主机做了哪些假设（可能主机是多主机的，或者路径上没有中间盒）？在考虑这些问题的同时，考虑运营实践和业务模型也是值得的。如果您可能会打破其中一些，您将不可避免地面临IETF中的一些反对意见。
If it is hard to answer these questions, it may indicate that the idea is too high-level or abstract for the IETF. Then it may be better to approach the IRTF (the research arm of the IETF); the IETF needs a specific protocol-level proposal before it can begin work, while the IRTF considers work that is not yet mature enough for standardization. Another danger is that the IETF is the wrong standards body, as a different one would need to standardize your proposal.
如果很难回答这些问题，则可能表明该想法对于IETF来说太高层次或抽象。那么最好是接近IRTF（IETF的研究部门）；IETF在开始工作之前需要一个特定的协议级提案，而IRTF则认为工作还不够成熟，无法实现标准化。另一个危险是IETF是错误的标准机构，因为需要另一个标准机构来标准化您的提案。
If your idea involves replacing several IETF protocols and/or upgrading several types of nodes simultaneously, it is probably best to rethink: the IETF finds it almost impossible to handle radical, "clean slate" proposals that change lots of things at once. Perhaps you can trim off a subset of your idea that's a smaller initial step requiring only an incremental change to an existing protocol, but you need to consider whether it is still useful.
如果您的想法涉及更换多个IETF协议和/或同时升级几种类型的节点，那么最好重新思考一下：IETF发现几乎不可能处理一次性改变很多事情的激进的“一板一眼”方案。也许您可以修剪一下您的想法的子集，这是一个较小的初始步骤，只需要对现有协议进行增量更改，但您需要考虑它是否仍然有用。
Finally, before bringing a proposal to the IETF, you need to be aware that there are intellectual property implications. For example, it will affect any patents you want to file. Less obviously, you grant the IETF the right to publish your contribution and you should inform the IETF if your proposal is covered by a patent. For more information about the rights you grant to the IETF, the best thing to read is the IETF's "Note Well" [NoteWell] and the documents linked to from there.
最后，在向IETF提交提案之前，您需要意识到存在知识产权方面的影响。例如，它将影响您想要申请的任何专利。不太明显的是，您授予IETF发布您的贡献的权利，并且如果您的提案包含在专利范围内，您应该通知IETF。有关您授予IETF的权利的更多信息，最好阅读IETF的“Note Well”[Note Well]及其链接的文档。
Having decided that the IETF is the right venue, you now need to persuade the IETF to start work on your idea. We discuss three steps that should help; they can be done in parallel. We then briefly discuss how to form a new working group (WG), if that is necessary.
在确定IETF是正确的地点之后，您现在需要说服IETF开始实施您的想法。我们讨论三个应该有帮助的步骤；它们可以并行进行。然后，如果有必要，我们将简要讨论如何组建一个新的工作组（WG）。
The IETF is a large organization; therefore, you need to communicate with the right part of it. The IETF is organized in areas such as routing, security, or transport. Within those areas, working groups are responsible for a specific topic. The IETF consists of over 100 WGs. So, a good step is to identify whether there is already a WG suitable for your work.
IETF是一个大型组织；因此，您需要与它的正确部分进行沟通。IETF是在路由、安全或运输等领域组织的。在这些领域内，工作组负责一个具体专题。IETF由100多个工作组组成。因此，一个好的步骤是确定是否已经有一个工作组适合您的工作。
If yes, then join the WG's mailing list and send email and perhaps write an Internet-Draft. A WG's current set of specific items is defined in its "Charter"; be aware that if your proposal falls outside the WG's current charter, then it would have to be extended before formal work could begin. Most WGs think about re-chartering every year or two, although most allow for some limited discussion on items outside their current charter.
如果是的话，那么加入工作组的邮件列表，发送电子邮件，或许还可以写一份网络草稿。工作组当前的一组具体项目在其“章程”中有定义；请注意，如果您的提案不在工作组当前章程的范围内，则必须在正式工作开始之前延长。大多数工作组考虑每一两年重新包租一次，尽管大多数工作组允许对当前包租之外的项目进行有限的讨论。
If no suitable WG exists, then you should identify the right Area. The WGs are clustered into "Areas" with a common theme such as security, with one or two Area Directors in charge of each Area. You may have to get a new WG created within the most relevant Area; this is a significantly difficult step (see below).
如果没有合适的工作组，那么您应该确定正确的区域。工作组分为具有共同主题（如安全）的“区域”，每个区域由一名或两名区域主管负责。你可能需要在最相关的领域内创建一个新的工作组；这是一个非常困难的步骤（见下文）。
Finding the right WG is akin to finding the right conference or journal to submit to. While a poor choice of conference will get your paper rejected as irrelevant, the IETF is friendlier, as most WG Chairs and Area Directors will try to redirect your work to a better WG, if you choose poorly. However, ending up with the right "venue" is critical, as only then will you collaborate with the right group of people.
找到合适的工作组类似于找到合适的会议或期刊提交。如果你选择的会议不好，你的论文会被视为无关紧要，而IETF则会更友好，因为如果你选择的不好，大多数工作组主席和区域主管都会尝试将你的工作重定向到一个更好的工作组。然而，找到合适的“场所”至关重要，因为只有这样，你才能与合适的人群合作。
Standards require agreement and approval by a wide range of people. Therefore you need to persuade others of the merits of your idea. In practice you need to go further and persuade others to do work. At a minimum, this will be to thoroughly review your proposal and preferably it will be to develop and test it with you. The IETF community needs to see evidence of wider support, interest, and commitment. A lack of reaction means work will not go forward (silence is not consent!). At an early stage, support could be
标准需要广泛的人的同意和批准。因此，你需要说服别人你的想法的优点。在实践中，你需要更进一步，说服别人去做这项工作。至少，这将是彻底审查您的提案，最好是与您一起开发和测试。IETF社区需要看到更广泛支持、兴趣和承诺的证据。缺乏反应意味着工作无法进行（沉默不是同意！）。在早期阶段，可以提供支持
demonstrated through comments on the mailing list. It is a very good idea to have some Internet-Drafts jointly authored with people from beyond your research team, perhaps an industry player. For example, you could develop a "use cases" document with a "user", such as an operator.
通过邮件列表上的评论进行演示。这是一个非常好的主意，有一些互联网草案共同编写的人从您的研究团队以外，也许是一个行业的玩家。例如，您可以使用“用户”（如操作员）开发“用例”文档。
Working with others has the extra benefit that it will help to clarify your idea and explain better its benefits and how it works. There are many experts in the IETF who can help stress test the idea technically and advise about process and culture. You need to get some of them involved as early as possible.
与他人合作还有一个额外的好处，那就是它将有助于澄清你的想法，更好地解释它的好处以及它是如何工作的。IETF中有许多专家可以帮助从技术上对想法进行压力测试，并就过程和文化提出建议。你需要尽早让他们中的一些人参与进来。
It may well be worth trying to hold an informal session at an IETF meeting. This can help build a community of interest for your idea; see the advice in [BAR-BOF].
在IETF会议上举行一次非正式会议可能是值得的。这有助于为您的想法建立一个感兴趣的社区；参见[BAR-BOF]中的建议。
You also need to describe your proposal in a way that others can understand. Your initial document should outline the protocol. It is counter-productive to detail every aspect, unless the protocol is incredibly simple. Firstly, too much detail swamps people with information that they cannot process. Most people understand things by learning about them several times at increasing levels of detail. Secondly, providing only an outline makes people feel that they have a chance of making worthwhile suggestions and changes, so they are more likely to actively engage with you. Thirdly, working out details is generally something that a wider group of people is better at than an isolated individual. Fourthly, in order for the IETF to start work, it is more important to convince the IETF that there is a problem that it needs to solve than to convince it about the merits of your solution.
您还需要以其他人能够理解的方式描述您的提案。您的初始文档应概述协议。除非协议非常简单，否则详细说明每个方面会适得其反。首先，太多的细节让人们无法处理信息。大多数人都是通过不断增加细节来了解事物的。第二，只提供大纲会让人们觉得他们有机会提出有价值的建议和改变，因此他们更有可能积极地与你接触。第三，制定细节通常是更广泛的人群比孤立的个人更擅长的事情。第四，为了让IETF开始工作，说服IETF它需要解决一个问题比说服它你的解决方案的优点更重要。
A good idea is to document a "protocol model", as described in [RFC4101]: "a short description of the system in overview form ... to answer three basic questions: 1. What problem is the protocol trying to achieve? 2. What messages are being transmitted and what do they mean? 3. What are the important, but unobvious, features of the protocol?"
一个好主意是记录一个“协议模型”，如[RFC4101]中所述：“以概述的形式对系统进行简要描述……回答三个基本问题：1.协议试图实现什么问题？2.传输什么消息及其含义？3.协议的重要但不明显的功能是什么？”
It is best to send your contributions in the form of an Internet-Draft (I-D). While it may seem a burden to convert your nice paper or slides into the idiosyncratic format of an I-D, this is the format that IETF people are used to reading. Also, extracting the IETF-relevant parts of publications into an I-D will often help to identify aspects that need more work by the IETF, such as protocol details glossed over.
最好以互联网草稿（I-D）的形式发送您的贡献。虽然将漂亮的论文或幻灯片转换成I-D的特殊格式似乎是一种负担，但IETF人员习惯于阅读这种格式。此外，将出版物中与IETF相关的部分提取到I-D中通常有助于识别需要IETF进行更多工作的方面，例如掩盖的协议细节。
You only need to establish a new WG if the idea falls outside the scope of existing WGs. Establishing a new WG nearly always requires a specific session, called a "BoF" (Birds of a Feather), at one of the IETF's face-to-face meetings. Here the pros and cons of the proposed WG are debated. As part of the preparation for the BoF, you need to:
你只需要建立一个新的工作组，如果这个想法超出了现有工作组的范围。建立一个新的工作组几乎总是需要在IETF的一次面对面会议上召开一次特定的会议，称为“BoF”（羽毛之鸟）。这里讨论了拟议工作组的利弊。作为BoF准备工作的一部分，您需要：
o Build a community (see above)
o 建立一个社区（见上文）
o Document the benefits: for example, a problem statement and/or use cases
o 记录优点：例如，问题陈述和/或用例
o Document the architecture: for example covering assumptions and requirements on a solution
o 记录体系结构：例如，涵盖解决方案的假设和需求
o Suggest specific work items for the proposed WG, typically the protocol to be standardized and the supporting informational documents
o 建议拟定工作组的具体工作项目，通常是待标准化的协议和支持性信息文件
Getting approval to hold a BoF and running a successful BoF meeting are both quite difficult. Working with someone experienced and reading the guidance in [RFC5434] are highly recommended.
获得批准召开BoF和成功召开BoF会议都非常困难。强烈建议与有经验的人员一起工作并阅读[RFC5434]中的指南。
4. How to Increase the Chances that the IETF Successfully Standardizes Your Proposal
4. 如何增加IETF成功标准化您的提案的机会
Congratulations, you got the IETF to agree to start working on your proposal. Now it only remains to do the actual work! In this section, we give some advice about ways of working that will increase the chances that the standardization runs smoothly.
恭喜你，你得到了IETF同意开始着手你的提案。现在只剩下做实际工作了！在本节中，我们将提供一些关于工作方式的建议，以增加标准化顺利运行的机会。
Those new to standards bodies may be surprised how long and how much effort it takes to standardize something.
那些新加入标准化组织的人可能会惊讶于标准化工作需要多长时间和付出多少努力。
Success at the IETF requires active participation: to convince others your idea is worthwhile, to build momentum, to gain consensus. Although IETF work is done mainly through mailing lists, in practice, face-to-face time is critical, especially for new or substantial work. If possible, go to the three IETF meetings a year.
IETF的成功需要积极参与：说服他人你的想法是值得的，建立动力，获得共识。尽管IETF的工作主要通过邮件列表完成，但在实践中，面对面的时间至关重要，尤其是对于新的或实质性的工作。如果可能，每年参加三次IETF会议。
It takes quite a long time for a proposal to turn into an IETF standard, even if the proposal is mature when it is first presented. There are many steps: building a community of interest, convincing
即使提案在首次提出时已经成熟，提案也需要相当长的时间才能变成IETF标准。有很多步骤：建立一个感兴趣、令人信服的社区
the IETF to start work, working through suggestions from technical experts and incorporating their improvements, gaining consensus, getting detailed reviews (any IETF publication gets significantly more reviews than an academic publication), going through the formal IETF approval process, and so on. Even if you can work full time on the proposal, effort is required from other people who can't. Also, the IETF tends to work in intensive bursts, with activity concentrated in the run-up to and then at the IETF meetings, with lulls of low activity in between.
IETF开始工作，根据技术专家的建议进行工作并纳入其改进，获得共识，获得详细审查（任何IETF出版物获得的审查明显多于学术出版物），通过正式的IETF批准流程，等等。即使你可以全职工作，也需要其他人的努力。此外，IETF往往以密集的突发方式工作，活动集中在IETF会议的准备阶段，然后在IETF会议上进行，中间是低活动的间歇。
The IETF proceeds by "rough consensus". Unlike some other standards bodies, there is no voting and no top-down process from requirements to architecture to protocol. The downside of this is that the IETF is not good at making decisions. Hence you need to persevere and guard against decisions unwinding. On the other hand, if the consensus is to reject your proposal or there is little interest in it, persevering is likely to be a waste of time -- you should probably give up or restart at Section 2.
IETF以“大致一致”的方式进行。与其他一些标准机构不同，从需求到架构再到协议，没有投票权，也没有自上而下的过程。这样做的缺点是IETF不善于做出决策。因此，你需要持之以恒，防止决策失控。另一方面，如果共识是拒绝你的提议，或者对此没有什么兴趣，那么坚持下去很可能是浪费时间——你可能应该放弃或者重新开始第2节。
All this means that it takes a considerable length of time to complete something at the IETF. Two years is probably a minimum. So, although a typical three-year research project sounds like plenty of time to do standardization, if you haven't already raised the idea within the first year, you're probably too late to complete standardization before your project ends. Since it's quite likely that IETF standardization won't be finished when your project ends, it is particularly important to convince others to help, so that the work is more likely to be completed afterwards.
所有这些都意味着在IETF上完成某件事情需要相当长的时间。两年可能是最短的。因此，虽然一个典型的三年研究项目听上去有足够的时间来进行标准化，但如果你在第一年内还没有提出这个想法，那么在项目结束之前完成标准化可能就太晚了。由于IETF标准化很可能在项目结束时无法完成，因此说服其他人提供帮助尤为重要，这样工作就更有可能在项目结束后完成。
It is helpful to come to the IETF with an open mind-set.
以开放的心态参加IETF是很有帮助的。
Co-authorship is good. Some standards bodies value trophy authors, who indicate their support but don't actually do any work. In the IETF, it is much better if co-authors are actually investing cycles on developing the proposal, whereas simple indications of support can be made on the mailing list or at the meetings.
合著是好的。一些标准机构重视奖杯作者，他们表示支持，但实际上不做任何工作。在IETF中，如果合著者实际投资开发提案的周期，则更好，而支持的简单指示可以在邮件列表或会议上做出。
In particular, if the IETF is going to standardize something, then in effect, it takes ownership; it is no longer "yours". Indeed, a good milestone of success is when your individual document becomes a WG draft, as then it is owned by the WG. The research mentality is a bit different, as it prizes authorship and confidentiality until publication.
特别是，如果IETF要标准化某些东西，那么实际上，它拥有所有权；它不再是“你的”。事实上，成功的一个好里程碑是当您的个人文档成为工作组草稿时，因为它是由工作组拥有的。研究思路有点不同，因为它在出版前重视作者身份和保密性。
It is very important to be open to working with others. One specific reason is to get help on aspects beyond your expertise or beyond what
开放地与他人合作是非常重要的。一个具体的原因是在你的专业知识之外或在什么方面获得帮助
you've had time to think about -- perhaps how to make your protocol more secure, or how to ensure it is congestion-friendly, or how it impacts network management. The IETF ensures that any protocol it standardizes has thought carefully about such aspects.
您已经有时间考虑了--可能是如何使您的协议更安全，或者如何确保它对拥塞友好，或者它如何影响网络管理。IETF确保其标准化的任何协议都仔细考虑了这些方面。
Also, the IETF works by collaboration. For example, there may be two proposals to solve a problem. In academia their proponents may treat each other as rivals and for example write "related work" sections that point out flaws and shortcomings of the opposition. At the IETF, they will soon work together on a common document, typically a synthesis of the competing proposals, and be sensitive to each other in order to help build consensus. You will also have to get support, or at least not vehement opposition, from IETF people working on other topics. So you need to be aware of what else the IETF is doing (in case your proposal conflicts) and what other problems exist in the Internet today (in case your proposal exacerbates them).
此外，IETF通过协作工作。例如，可能有两个解决问题的方案。在学术界，他们的支持者可能会将彼此视为竞争对手，例如撰写“相关工作”章节，指出反对派的缺陷和不足。在IETF上，他们将很快共同编写一份共同的文件，通常是竞争提案的综合，并相互敏感，以帮助建立共识。你还必须得到IETF其他主题工作人员的支持，或者至少不要强烈反对。因此，您需要了解IETF正在做什么（以防您的提案冲突），以及当前互联网上存在哪些其他问题（以防您的提案加剧这些问题）。
Finally, collaborative research projects sometimes find it difficult to be open to working with others. Firstly, such projects typically have a consortium agreement about confidentiality -- it must not prevent you from engaging properly day-to-day with people outside the project. Secondly, you may have to spend considerable effort on intra-project coordination -- but, an individual researcher only has so much energy and enthusiasm for collaborating, so if you spend a lot of time liaising between different groups within your project, then you have little left for working with the IETF.
最后，合作研究项目有时发现很难与他人合作。首先，此类项目通常有一个关于保密性的联合体协议——它不能阻止您与项目外的人员进行正常的日常接触。第二，您可能需要在项目内协调上花费大量精力——但是，一个研究人员在合作上只有如此多的精力和热情，因此如果您在项目内的不同小组之间花费大量时间进行联络，那么您就没有多少时间与IETF合作了。
The research mind-set is often to investigate very thoroughly all possible details about an idea -- to seek perfection -- sometimes with no particular deadline. The IETF mind-set is to get something done and out there that works, albeit imperfectly; if people find it useful, then there will be another iteration to improve it, probably to meet needs that only become apparent on widescale deployment. The philosophy is to find a reasonable solution to the problem that currently exists. Time spent over-optimizing may simply mean that the solution has been superseded (perhaps the problem has been solved in some other way, or perhaps the problem was so significant that a different approach had to be found to avoid the problem).
研究心态通常是非常彻底地调查一个想法的所有可能细节——寻求完美——有时没有特定的截止日期。IETF的思维定势是完成一些工作，并在那里工作，尽管不完美；如果人们发现它有用，那么将有另一次迭代来改进它，可能是为了满足只有在大规模部署中才会出现的需求。其理念是为目前存在的问题找到合理的解决方案。过度优化所花费的时间可能仅仅意味着解决方案已被取代（可能问题已通过其他方式解决，或者问题太严重，必须找到不同的方法来避免问题）。
The IETF is very impressed by actual implementations: "running code". It helps smooth the standards process, it helps people believe it really works, and it helps you and others discover any issues. An implementation that others can download and try is extremely helpful in getting your protocol actually deployed -- presumably, that is
IETF对实际实现印象深刻：“运行代码”。它有助于标准过程的顺利进行，有助于人们相信它确实有效，并有助于您和其他人发现任何问题。其他人可以下载并尝试的实现对于实际部署您的协议非常有帮助——大概是这样的
your real objective, not simply to get an IETF standard! In the longer term, you may need to think about how to get it incorporated in the Linux kernel, for instance.
您真正的目标，不仅仅是获得IETF标准！从长远来看，例如，您可能需要考虑如何将其整合到Linux内核中。
Overall, it is very hard to get a protocol in actual widespread use. There are far more IETF protocols on paper than in use.
总的来说，很难得到一个实际广泛使用的协议。纸上的IETF协议比使用中的多得多。
In this section, we include some examples in which the authors have been deeply involved and have managed (we believe) to bring the research output of a collaborative research project successfully into the IETF.
在本节中，我们列举了一些作者深入参与并成功（我们相信）将合作研究项目的研究成果纳入IETF的例子。
Multipath TCP (MPTCP) enables a regular TCP connection to use multiple paths simultaneously. It extends TCP to allow the use of multiple IP addresses by each endpoint. This work is one output of the Trilogy research project which was brought to the IETF for standardization, and it is currently making good progress. We provide a brief overview of the steps taken.
多路径TCP（MPTCP）允许常规TCP连接同时使用多条路径。它扩展了TCP，允许每个端点使用多个IP地址。这项工作是三部曲研究项目的成果之一，该项目已提交IETF进行标准化，目前正在取得良好进展。我们简要概述了所采取的步骤。
The first stage was doing some early socialization of the main ideas of MPTCP. Presentations were made in several relevant WGs: the Routing Research Group (July 2008) and the Transport Area Open meeting (July 2008 and March 2009). In addition, a mailing list was created, open to anyone who was interested in discussing Multipath-TCP-related issues in the IETF context, and a public Web page was created containing Multipath-TCP-related material, including papers, Internet-Drafts, presentations, and code. The feedback received was encouraging enough to continue with the effort of bringing the work to the IETF.
第一阶段是对MPTCP的主要思想进行早期社会化。在几个相关工作组中作了专题介绍：路线研究小组（2008年7月）和运输领域公开会议（2008年7月和2009年3月）。此外，还创建了一个邮件列表，对任何有兴趣在IETF上下文中讨论多路径TCP相关问题的人开放，并创建了一个包含多路径TCP相关材料的公共网页，包括论文、互联网草稿、演示和代码。收到的反馈足够令人鼓舞，可以继续努力将工作提交给IETF。
Once we verified that the proposed ideas had potential traction in the IETF, the next step was to identify the proper venue for the proposed work. There were two choices, namely, to go for a BoF, with a view to a new WG, or to try to add additional work items to an existing WG, in particular TCPM seemed a good candidate. After talking to the Area Directors, it seemed that having a BoF was the right approach, at least for the initial discussion stage. So, a BoF proposal was submitted to the Transport ADs for the IETF 75 meeting held in Stockholm in July 2009. The initial BoF proposal was crafted by Trilogy people, but was sent to the open mailing list for discussion and modification from the rest of the community. The BoF request was approved and the MPTCP BoF was held at the IETF 75 meeting.
一旦我们验证了提议的想法在IETF中具有潜在的吸引力，下一步就是为提议的工作确定合适的地点。有两种选择，即选择BoF，以期建立一个新的工作组，或者尝试向现有工作组添加额外的工作项，特别是TCPM似乎是一个很好的候选者。在与区域主管交谈后，似乎有一个BoF是正确的方法，至少在最初的讨论阶段是这样。因此，在2009年7月于斯德哥尔摩举行的IETF 75会议上，向交通ADs提交了BoF提案。最初的BoF提案由Trilogy people起草，但被发送到开放邮件列表，供社区其他人讨论和修改。BoF请求获得批准，MPTCP BoF在IETF 75会议上举行。
The general feedback received during the BoF was that there was enough interest and energy in the community to do this work within the IETF. A first charter draft was posted on the mailing list for comments a couple of months after the BoF. After a month or so of charter discussion on the mailing list, the MPTCP working group was created in October 2009. The charter includes deliverables due to March 2011.
BoF期间收到的总体反馈是，社区中有足够的兴趣和精力在IETF内开展这项工作。BoF后几个月，第一份章程草案被张贴在邮件列表上征求意见。经过一个月左右的邮件列表宪章讨论，MPTCP工作组于2009年10月成立。该章程包括2011年3月到期的可交付成果。
The MPTCP working group has, so far, made significant progress and most of the milestones have been delivered on schedule [MPTCP].
迄今为止，MPTCP工作组取得了重大进展，大部分里程碑都已如期交付[MPTCP]。
Congestion Exposure enables sending end-hosts to inform the network about the congestion encountered by previous packets on the same flow. This allows the network devices to act upon the congestion information and the perceived user behavior. Like the MPTCP work, it is an output of the Trilogy research project and has been successfully brought to the IETF. We next describe the steps followed to do so.
拥塞暴露使发送端主机能够向网络通知相同流上以前的数据包遇到的拥塞。这允许网络设备根据拥塞信息和感知的用户行为进行操作。与MPTCP工作一样，它也是三部曲研究项目的成果，并已成功地引入IETF。接下来，我们将描述执行此操作所遵循的步骤。
In this case, early socialization included presentations at the Internet Congestion Control Research Group and the Internet Area meeting at the IETF 75 meeting in July 2009, the creation of an open mailing list to discuss Congestion Exposure related issues in the IETF, and posting the related materials such as papers, Internet drafts, and code in a public web page. In addition, an informal, open meeting (sometimes called a Bar-BoF in IETF parlance) was held during the IETF 75 meeting.
在这种情况下，早期社会化包括在互联网拥塞控制研究小组和2009年7月IETF 75会议上的互联网区域会议上的演讲，创建一个开放的邮件列表，以讨论IETF中与拥塞暴露相关的问题，并发布相关材料，如论文、互联网草稿，和公共网页中的代码。此外，在IETF 75会议期间，还举行了一次非正式的公开会议（IETF术语中有时称为Bar BoF）。
After processing the feedback received in the Bar-BoF, a BoF proposal was submitted to the Internet Area ADs for the IETF 76 meeting in November 2009. The BoF was accepted and was held as planned. While the feedback received in the BoF was positive, the IESG was uncertain about chartering a working group on this topic. (The IESG is the IETF's management body and consists of all the Area Directors.) In order to address the remaining concerns of the IESG, another BoF was held at the following IETF meeting.
在处理了Bar BoF中收到的反馈后，BoF提案被提交给互联网区域ADs，用于2009年11月的IETF 76会议。转炉被接受并按计划举行。虽然在BoF中收到的反馈是积极的，但IESG不确定是否就此主题成立一个工作组。（IESG是IETF的管理机构，由所有区域主管组成。）为了解决IESG的剩余问题，在下一次IETF会议上召开了另一个BoF。
After much debate, the CONEX WG was approved by the IESG, but the scope of its charter was limited compared with the original proposal. This was due to some concerns regarding the proposed allocation of the last bit in the IPv4 header. The CONEX WG serves as a good example to illustrate the kind of compromise that is necessary when research aspiration meets Internet standardization. The CONEX WG [CONEX] held its first meeting at the IETF 78 meeting in July 2010. Its charter contains deliverables through November 2011.
经过多次辩论，CONEX工作组获得了IESG的批准，但其章程的范围与最初的提案相比是有限的。这是由于对IPv4报头中最后一位的拟议分配存在一些担忧。CONEX工作组是一个很好的例子，可以说明当研究愿望满足互联网标准化时，需要何种折衷。CONEX工作组[CONEX]于2010年7月在IETF 78会议上举行了第一次会议。其章程包含截至2011年11月的可交付成果。
This document has no known security implications.
此文档没有已知的安全含义。
Part of this work was funded by the Trilogy Project [TRILOGY], a research project supported by the European Commission under its Seventh Framework Program.
这项工作的一部分由Trilogy项目（Trilogy）资助，Trilogy项目是由欧盟委员会在其第七个框架计划下支持的一个研究项目。
Similar material was accepted for publication in ACM CCR, July 2011 [CCR].
2011年7月，ACM CCR[CCR]接受了类似材料的出版。
[BAR-BOF] Eggert, L. and G. Camarillo, "Considerations for Having a Successful "Bar BOF" Side Meeting", Work in Progress, August 2011.
[BAR-BOF]Eggert，L.和G.Camarillo，“成功召开“BAR-BOF”会外会议的考虑因素”，正在进行的工作，2011年8月。
[CCR] "How to Contribute Research Results to Internet Standardization". Marcelo Bagnulo, Philip Eardley, Lars Eggert and Rolf Winter. ACM Computer Communication Review (CCR), Vol. 41, No. 3, July 2011.
[CCR]“如何为互联网标准化贡献研究成果”。马塞洛·巴格鲁、菲利普·埃尔德利、拉尔斯·艾格特和罗尔夫·温特。ACM计算机通信评论（CCR），第41卷，第3期，2011年7月。
[CONEX] "Congestion Exposure working group", http://tools.ietf.org/wg/conex/.
[CONEX]“拥堵风险工作组”，http://tools.ietf.org/wg/conex/.
[MPTCP] "Multipath TCP working group", http://tools.ietf.org/wg/mptcp/.
[MPTCP]“多路径TCP工作组”，http://tools.ietf.org/wg/mptcp/.
[NoteWell] "Note Well", http://www.ietf.org/about/note-well.html.
[NoteWell]“NoteWell”，http://www.ietf.org/about/note-well.html.
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.
[RFC4101]Rescorla，E.和IAB，“编写协议模型”，RFC 41012005年6月。
[RFC4144] Eastlake, D., "How to Gain Prominence and Influence in Standards Organizations", RFC 4144, September 2005.
[RFC4144]Eastlake，D.，“如何在标准组织中获得突出地位和影响力”，RFC 41442005年9月。
[RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force", RFC 4677, September 2006.
[RFC4677]Hoffman，P.和S.Harris，“IETF之道-互联网工程任务组新手指南”，RFC 4677，2006年9月。
[RFC5434] Narten, T., "Considerations for Having a Successful Birds-of-a-Feather (BOF) Session", RFC 5434, February 2009.
[RFC5434]Narten，T.，“成功举行羽鸟（BOF）会议的考虑因素”，RFC 5434，2009年2月。
[TRILOGY] "Trilogy Project", http://www.trilogy-project.org/.
[三部曲]“三部曲项目”，http://www.trilogy-project.org/.
Authors' Addresses
作者地址
Philip Eardley BT Adastral Park, Martlesham Heath Ipswich England
菲利普·埃尔德利英国电信公司阿达斯特拉尔公园，马特勒沙姆希思伊普斯维奇英格兰
EMail: philip.eardley@bt.com
EMail: philip.eardley@bt.com
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
芬兰诺基亚集团00045诺基亚研究中心邮政信箱407
Phone: +358 50 48 24461
EMail: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/
Phone: +358 50 48 24461
EMail: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Madrid Spain
马德里卡洛斯三世大学。西班牙马德里30大学
EMail: marcelo@it.uc3m.es
EMail: marcelo@it.uc3m.es
Rolf Winter NEC Europe Heidelberg Germany
Rolf Winter NEC欧洲海德堡德国
EMail: rolf.winter@neclab.eu
EMail: rolf.winter@neclab.eu