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 Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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
現在の仕事のIETFのエリア外すぎているのアイデアのためのO
o for ideas that are too high-level for the IETF to begin protocol-level work on
上のプロトコルレベルの作業を開始するIETFには高すぎるレベルですアイデアのためのO
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
偉大なシミュレーション結果にもかかわらず、何かの作業を開始するIETFのための説得力の十分な引数がない場合はO
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があなたの提案を標準化しており、それが展開されていることを想像し、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 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.
その利点は何でしょう：あなたの提案の動機について明確な説明を持っていることは非常に重要なのですか？それは何の問題を解決できますか？多くのアイデアが（もちろん彼らはまだ研究の細かい部分もあり！）短期的にインターネットに明確な利益をもたらすことはありません。過去には、IETFは、しばしば使用されていないことになったプロトコルを開発しましたので、今、新しい仕事を始める前に、利点について難しく考えていると、それは理論的には、将来的に発生する可能性があるというよりも、現在、重大な問題を解決することを確認します。それはあなたの提案が作成し、これを見られるしたユースケースだろうか改善について具体的にするのがベストです。
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プロトコルの代わりに、または1つを補足されていますか？ここでも、それは具体的には最高です：両端が新しいプロトコルを採用する必要がありますか？それはフォールバックしたり、既存の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の「まあ注」[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があるかどうかを識別することです。
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.
yesの場合は、WGのメーリングリストに参加し、電子メールを送信すると、おそらくインターネットドラフトを作成します。特定の項目のWGの現在のセットは、その「憲章」に定義されています。あなたの提案はWGの現在のチャーター外にある場合、それは正式な仕事を始めることができる前に延長されなければならないことに注意してください。ほとんどは彼らの現在のチャーター外の項目にいくつかの限られた議論を可能とするものの、ほとんどのWGは、再チャーター毎年または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が存在しない場合は、右のエリアを特定する必要があります。 WGは、各エリアの担当中の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 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.
規格は、人々の広い範囲での合意と承認を必要とします。したがって、あなたは、あなたのアイデアのメリットの他の人を説得する必要があります。実際には、あなたはさらに行くと仕事をするために他人を説得する必要があります。最低でも、これは徹底的にあなたの提案を検討するために、好ましくは、それはあなたとそれを開発し、テストすることになりますでしょう。 IETFコミュニティは、より広いサポート、金利、およびコミットメントの証拠を確認する必要があります。反応の欠如は、（沈黙が同意されていません！）仕事が進まないことを意味します。初期の段階では、サポートはメーリングリストへのコメントを通じて証明することができました。いくつかのインターネットドラフトは共同で、あなたの研究チームを越えた人と、おそらく業界のプレーヤーを執筆持っていることは非常に良いアイデアです。たとえば、あなたは、演算子として、「ユーザー」と「ユースケース」ドキュメントを開発することもできます。
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の人が読んでために使用されている形式です。また、I-Dに出版物のIETF-関連する部分を抽出し、多くの場合、オーバー練りプロトコルの詳細など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:
あなただけのアイデアは既存のWGの範囲外であれば、新たなWGを確立する必要があります。新しいWGはほぼ常に特定のセッションを必要と確立、IETFの対面会議の一つで、「このBoF」（フェザーの鳥）と呼ばれます。ここで提案されたWGの長所と短所が議論されています。このBoFの準備の一環として、以下を行う必要があります。
o Build a community (see above)
コミュニティを構築するために（上記参照）
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 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の間における低活性のlullsと、にランアップおよびその後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で何かを完了するのに相当な時間がかかることを意味します。二年はおそらく最小です。典型的な3年間の研究プロジェクトは、標準化を行うために多くの時間のように聞こえるが、あなたはすでに1年以内にアイデアを提起していないのであれば、あなたはおそらく、あなたのプロジェクトが終了する前に標準化を完了するには遅すぎます。あなたのプロジェクトが終了したとき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 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の心セットは、何かを成し遂げることであり、そこに不完全ではあるが、動作します。人々はそれが役に立つなら、おそらく唯一のwidescale展開に明らかになるのニーズを満たすために、それを改善するための別の反復があるでしょう。哲学は、現在存在している問題への合理的な解決策を見つけることです。過最適化に費やされる時間は、単純に解決策は（おそらく問題は、他の方法で解決されている、または多分問題は異なるアプローチが問題を回避することが判明されなければならなかったように有意であった）取って代わられていることを意味するかもしれません。
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 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は、実際の実装によって、非常に感銘を受けています。それは、人々はそれが実際に動作すると考えているのに役立ちます、それはあなたや他の人がどんな問題を発見に役立ち、標準化プロセスをスムーズに役立ちます。おそらく、それはあなたの本当の目的である、ない単に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接続を可能にします。これは、各エンドポイントによって、複数のIPアドレスの使用を許可するようにTCPを拡張します。この作品は、標準化のために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の主なアイデアのいくつかの初期の社会化をしていました。プレゼンテーションは、いくつかの関連のWGで行われた：ルーティング研究グループ（2008年7月）とトランスポートエリアのオープンミーティング（2008年7月と2009年3月）。また、メーリングリストは、IETF文脈でマルチパス-TCP関連の問題を議論に興味を持った人にオープンに作成し、パブリックWebページがペーパー、インターネットドラフトを含むマルチパス-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で潜在的な牽引力を持っていたことを確認したら、次のステップでは、提案された仕事のための適切な会場を同定することでした。すなわち、2つの選択肢が、新しいWGを視野に入れ、このBoFのために行く、あるいは特定のTCPMに良い候補者を見えた、既存のWGに追加の作業項目を追加しようとするために、ありました。エリアディレクターに話をした後、のBoFを有する少なくとも初期の議論の段階のために、正しいアプローチだったようです。だから、このBoFの提案は、初期のBoFの提案はトリロジーの人々によって作られたが、残りのから議論と修正のためのオープンなメーリングリストに送信されました2009年7月にストックホルムで開催されたIETF 75会議の交通広告に提出されましたコミュニティ。この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における輻輳露出関連の問題を議論するためのオープンメーリングリストの作成、および関連する投稿こうした公共のWebページの論文、インターネットドラフト、およびコードなどの材料。また、（時にはIETF用語でバー-のBoFと呼ばれる）非公式、オープンミーティングは、IETF 75会議中に開催されました。
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.
バー-のBoFで受け取ったフィードバックを処理した後、このBoFの提案は、2009年11月のBoFでのIETF 76会議のためのインターネットエリア広告に提出して受理されたと予定通り開催されました。このBoFで受信されたフィードバックはポジティブだったが、IESGはこのトピックに関するワーキンググループをチャーターについての不確実でした。 （IESGは、IETFの経営体であり、全エリアの取締役で構成されている。）IESGの残りの懸念に対処するために、別のBoFは、次のIETF会議で開催されました。
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 [コーネックス]はその憲章は、2011年11月を通じて成果物が含まれている2010年7月にIETF 78会議でその最初の会議を開催しました。
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]、その第七次フレームワーク計画の下で、欧州委員会でサポートされている研究プロジェクトによって資金を供給されました。
Similar material was accepted for publication in ACM CCR, July 2011 [CCR].
同様の材料はACM CCR、2011年7月[CCR]で出版のために受理されました。
[BAR-BOF] Eggert, L. and G. Camarillo, "Considerations for Having a Successful "Bar BOF" Side Meeting", Work in Progress, August 2011.
[BAR-BOF]エッゲルト、L.とG.カマリロ、進歩、2011年8月中にバーBOF "サイド会議 "ワーク" の成功を持つための考慮事項"。
[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]「どのようにインターネット標準化への研究成果に貢献します」。マルセロBagnulo、フィリップEardley、ラースエッゲルトとロルフ冬。 ACMコンピュータコミュニケーションレビュー（CCR）、巻。 41、第3号、2011年7月。
[CONEX] "Congestion Exposure working group", http://tools.ietf.org/wg/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]、http://www.ietf.org/about/note-well.htmlを "よく注意してください"。
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.
[RFC4101]レスコラ、E.およびIAB、 "ライティング・プロトコル・モデル"、RFC 4101、2005年6月。
[RFC4144] Eastlake, D., "How to Gain Prominence and Influence in Standards Organizations", RFC 4144, September 2005.
[RFC4144]イーストレイク、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]ホフマン、P.とS.・ハリス、「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.、RFC 5434、2009年2月、 "成功した鳥の - フェザー（BOF）セッションを持つための考慮事項"。
[TRILOGY] "Trilogy Project", http://www.trilogy-project.org/.
[TRILOGY] "トリロジープロジェクト"、http://www.trilogy-project.org/。
Authors' Addresses
著者のアドレス
Philip Eardley BT Adastral Park, Martlesham Heath Ipswich England
フィリップEardley BT Adastral公園、Martleshamヒースイプスウィッチイングランド
EMail: philip.eardley@bt.com
メールアドレス：philip.eardley@bt.com
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
ラースEggertのノキア・リサーチセンター私書箱ボックス407ノキアグループ00045フィンランド
Phone: +358 50 48 24461 EMail: lars.eggert@nokia.com URI: http://research.nokia.com/people/lars_eggert/
電話番号：+358 50 48 24461電子メール：lars.eggert@nokia.com URI：http://research.nokia.com/people/lars_eggert/
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Madrid Spain
マドリードのマルセロBagnuloチャールズIII大学のAv。大学30マドリードスペイン
EMail: marcelo@it.uc3m.es
メールアドレス：marcelo@it.uc3m.es
Rolf Winter NEC Europe Heidelberg Germany
ロルフ・冬NECヨーロッパハイデルベルクドイツ
EMail: rolf.winter@neclab.eu
メールアドレス：rolf.winter@neclab.eu