[要約] RFC 6417は、研究結果をインターネット標準化に貢献する方法についてのガイドラインです。その目的は、研究者が自身の成果をインターネットの標準化プロセスに有効に参加できるようにすることです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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
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のTAO」[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で結果の一部を標準化しようとしている共同プロジェクトを含むいくつかの研究プロジェクトに関与しており、いくつかのアドバイスを伝えたいと考えています（時には難しい方法を学んだことがあります！）。アドバイスは3つのグループに分割されます。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が提案を標準化し、展開されていることを想像することです。2つの質問を自問してください。
1. How would the Internet be better?
1. インターネットはどのように良くなるでしょうか？
2. What Internet nodes would have been upgraded?
2. どのようなインターネットノードがアップグレードされたでしょうか？
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」[Notewell]とそこからリンクされているドキュメントです。
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を説得してアイデアの作業を開始する必要があります。役立つはずの3つのステップについて説明します。それらは並行して行うことができます。次に、それが必要な場合は、新しいワーキンググループ（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 WGを超えるWGで構成されています。したがって、良いステップは、あなたの仕事にすでに適したWGがすでにあるかどうかを特定することです。
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.
はいの場合は、WGのメーリングリストに参加して電子メールを送信し、おそらくインターネットドラフトを書いてください。WGの特定のアイテムの現在のセットは、その「チャーター」で定義されています。提案がWGの現在の憲章の外にある場合、正式な作業が開始される前に延長する必要があることに注意してください。ほとんどのWGSは、毎年1〜2回の再請求について考えていますが、ほとんどの場合、現在の憲章以外のアイテムに関するいくつかの限定的な議論が可能です。
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).
適切なWGが存在しない場合は、適切な領域を特定する必要があります。WGSは、セキュリティなどの共通のテーマを持つ「エリア」にクラスター化され、各エリアを担当する1つまたは2つのエリアディレクターがいます。最も関連性の高いエリア内で作成された新しいWGを取得する必要がある場合があります。これは非常に難しいステップです（以下を参照）。
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.
適切なWGを見つけることは、提出する正しい会議や日記を見つけることに似ています。会議の選択が不十分な場合、論文は無関係であると拒否されますが、IETFは友好的です。ほとんどのWGの椅子とエリアディレクターは、あなたがより貧弱に選択した場合、より良いWGにあなたの作品をリダイレクトしようとするので、より友好的です。ただし、適切な「会場」で終わることは重要です。そのためだけ、適切なグループと協力することになります。
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.
また、他の人が理解できる方法で提案を説明する必要があります。最初のドキュメントはプロトコルの概要を説明する必要があります。プロトコルが非常に簡単でない限り、あらゆる側面を詳細に詳細にすることは逆効果です。第一に、詳細が多すぎると、処理できない情報を人々に襲います。ほとんどの人は、詳細レベルの増加で数回それらについて学ぶことで物事を理解しています。第二に、アウトラインのみを提供することで、人々は価値のある提案や変更を行う可能性があると感じるため、積極的にあなたと関わり合う可能性が高くなります。第三に、詳細を解決することは、一般に、より広い人々のグループが孤立した個人よりも優れているものです。第4に、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]で説明されている「プロトコルモデル」を文書化することです。。どのようなメッセージが送信されており、それらは何を意味しますか？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:
アイデアが既存のWGSの範囲外にある場合にのみ、新しいWGを確立する必要があります。新しいWGを確立するには、IETFの対面会議の1つで、ほぼ常に「BOF」（羽の鳥の鳥）と呼ばれる特定のセッションが必要です。ここでは、提案されたWGの長所と短所が議論されています。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 提案されたWG、通常は標準化されるプロトコルとサポート情報ドキュメントの特定の作業項目を提案する
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の作業は主にメーリングリストを通じて行われますが、実際には、特に新規または実質的な作業にとって、対面時間が重要です。可能であれば、年間3回の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ミーティングに集中しており、その間に低い活動の小康状態で活動が集中しています。
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で何かを完成させるのにかなりの時間がかかることを意味します。おそらく2年は最低です。したがって、典型的な3年間の研究プロジェクトは標準化を行うのに十分な時間のように聞こえますが、最初の年以内にアイデアをまだ提起していない場合、プロジェクトが終了する前に標準化を完了するには遅すぎるでしょう。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が何かを標準化する場合、実際には所有権が必要です。それはもはや「あなた」ではありません。確かに、成功の良いマイルストーンは、あなたの個々のドキュメントがWGドラフトになったとき、それはWGが所有するときです。研究のメンタリティは、出版まで著者と機密性を賞賛するため、少し異なります。
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
他の人と協力することにオープンであることが非常に重要です。具体的な理由の1つは、専門知識を超えて、またはそれ以上の側面について助けを得ることです
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はコラボレーションによって機能します。たとえば、問題を解決するための2つの提案がある場合があります。アカデミアでは、彼らの支持者はお互いをライバルとして扱い、例えば、野党の欠陥と欠点を指摘する「関連する仕事」セクションを書くかもしれません。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.
MultiPath TCP（MPTCP）により、通常のTCP接続が複数のパスを同時に使用できるようにします。TCPを拡張して、各エンドポイントで複数のIPアドレスを使用できるようにします。この作業は、標準化のためにIETFに持ち込まれた3部作研究プロジェクトの1つの出力であり、現在は良い進歩を遂げています。取られた手順の簡単な概要を説明します。
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の主要なアイデアの早期社会化を行うことでした。プレゼンテーションは、いくつかの関連するWGS（ルーティングリサーチグループ（2008年7月）と輸送エリアオープンミーティング（2008年7月と2009年3月）で行われました。さらに、IETFコンテキストでMultiPath-TCP関連の問題について議論することに興味がある人なら誰でも開かれたメーリングリストが作成され、Paper、Internet-DraftsなどのMultiPath-TCP関連の資料を含むパブリックWebページが作成されました。プレゼンテーション、およびコード。受け取ったフィードバックは、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で潜在的な牽引力を持っていることを確認したら、次のステップは提案された作業のための適切な会場を特定することでした。つまり、新しいWGを見るか、既存のWGに追加の作業項目を追加しようとするために、BOFに行くという2つの選択肢がありました。特に、TCPMは良い候補者のように思えました。地域のディレクターと話をした後、少なくとも最初の議論の段階では、BOFを持つことが正しいアプローチであるように思われました。したがって、2009年7月にストックホルムで開催されたIETF 75会議のBOF提案は、Transport Adsに提出されました。最初のBOF提案は3部作の人々によって作成されましたが、残りの部分からの議論と修正のためにオープンメーリングリストに送信されました。コミュニティ。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の数ヶ月後にコメントのためにメーリングリストに投稿されました。メーリングリストで1か月ほどのチャーターディスカッションの後、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会議でのインターネット渋滞管理研究グループとインターネットエリア会議でのプレゼンテーションが含まれていました。公開Webページの論文、インターネットドラフト、コードなどの資料。さらに、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の提案は2009年11月にIETF 76会議のインターネットエリア広告に提出されました。BOFは受け入れられ、計画どおりに開催されました。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 WGはIESGによって承認されましたが、その憲章の範囲は元の提案と比較して制限されていました。これは、IPv4ヘッダーの最後のビットの提案された割り当てに関するいくつかの懸念によるものでした。Conex WGは、研究の願望がインターネットの標準化を満たしているときに必要な妥協の種類を示す良い例として機能します。Conex WG [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.
この作業の一部は、第7回フレームワークプログラムの下で欧州委員会がサポートする研究プロジェクトであるThe Trilogy Project [Trilogy]によって資金提供されました。
Similar material was accepted for publication in ACM CCR, July 2011 [CCR].
2011年7月[CCR]、ACM 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。and 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）、Vol。41、No。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]「MultiPath TCPワーキンググループ」、http：//tools.ietf.org/wg/mptcp/。
[NoteWell] "Note Well", http://www.ietf.org/about/note-well.html.
[Notewell] "Note Well"、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 4101、2005年6月。
[RFC4144] Eastlake, D., "How to Gain Prominence and Influence in Standards Organizations", RFC 4144, September 2005.
[RFC4144] Eastlake、D。、「標準組織で顕著と影響力を獲得する方法」、RFC 4144、2005年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のTAO-インターネット工学タスクフォースの初心者のガイド」、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/.
[Trilogy]「Trilogy Project」、http://www.trilogy-project.org/。
Authors' Addresses
著者のアドレス
Philip Eardley BT Adastral Park, Martlesham Heath Ipswich England
フィリップ・アードリーBTアダストラルパーク、マーティルシャムヒースイプスウィッチイングランド
EMail: philip.eardley@bt.com
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
Lars Eggert Nokia Research Center P.O.ボックス407ノキアグループ00045フィンランド
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
Marcelo Bagnulo Universidad Carlos III de Madrid av。大学30マドリードスペイン
EMail: marcelo@it.uc3m.es
Rolf Winter NEC Europe Heidelberg Germany
ロルフ・ウィンターネックヨーロッパハイデルベルクドイツ
EMail: rolf.winter@neclab.eu