[要約] RFC 7305は、IABワークショップでのインターネット技術の採用と移行に関する報告書であり、インターネット技術の採用と移行の課題と解決策に焦点を当てています。目的は、インターネット技術の採用と移行に関する情報を提供し、関係者が効果的な戦略を策定するためのガイダンスを提供することです。
Internet Architecture Board (IAB) E. Lear, Ed.
Request for Comments: 7305 July 2014
Category: Informational
ISSN: 2070-1721
Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)
IAB Workshop for Internet Technology Adoption and Transition（ITAT）からの報告
Abstract
概要
This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Internet Technology Adoption and Transition (ITAT). The workshop was hosted by the University of Cambridge on December 4th and 5th of 2013 in Cambridge, UK. The goal of the workshop was to facilitate adoption of Internet protocols, through examination of a variety of economic models, with particular emphasis at the waist of the hourglass (e.g., the middle of the protocol stack). This report summarizes contributions and discussions. As the topics were wide ranging, there is no single set of recommendations for IETF participants to pursue at this time. Instead, in the classic sense of early research, the workshop noted areas that deserve further exploration.
このドキュメントでは、インターネットテクノロジの採用と移行（ITAT）について、インターネットアーキテクチャボード（IAB）が開催したワークショップの概要を説明します。このワークショップは、2013年12月4日および5日にケンブリッジ大学で主催されました。ワークショップの目的は、特に砂時計のくびれ部分（プロトコルスタックの真ん中など）に重点を置いて、さまざまな経済モデルの調査を通じてインターネットプロトコルの採用を促進することでした。このレポートは、貢献と議論を要約したものです。トピックは多岐にわたるため、現時点でIETF参加者が追求する推奨事項は1つだけではありません。代わりに、初期の研究という古典的な意味で、ワークショップはさらなる調査に値する領域に言及しました。
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.
なお、本資料はワークショップの議事録です。このレポートに記載されている見解と見解はワークショップ参加者のものであり、必ずしもIABの見解と見解を反映しているわけではありません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7305.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7305で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Organization of This Report . . . . . . . . . . . . . . . 5
2. Motivations and Review of Existing Work . . . . . . . . . . . 5
3. Economics of Protocol Adoption . . . . . . . . . . . . . . . 7
3.1. When can bundling help adoption of network
technologies or services? . . . . . . . . . . . . . . . . 7
3.2. Internet Protocol Adoption: Learning from Bitcoin . . . . 7
3.3. Long term strategy for a successful deployment of
DNSSEC - on all levels . . . . . . . . . . . . . . . . . 8
3.4. Framework for analyzing feasibility of Internet
protocols . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Best Effort Service as a Deployment Success Factor . . . 9
4. Innovative / Out-There Models . . . . . . . . . . . . . . . . 10
4.1. On the Complexity of Designed Systems (and its effect
on protocol deployment) . . . . . . . . . . . . . . . . . 10
4.2. Managing Diversity to Manage Technological
Transition . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. On Economic Models of Network Technology Adoption,
Design, and Viability . . . . . . . . . . . . . . . . . . 11
5. Making Standards Better . . . . . . . . . . . . . . . . . . . 11
5.1. Standards: a love/hate relationship with patents . . . . 11
5.2. Bridge Networking Research and Internet
Standardization: Case Study on Mobile Traffic
Offloading and IPv6 Transition Technologies . . . . . . . 11
5.3. An Internet Architecture for the Challenged . . . . . . . 12
6. Other Challenges and Approaches . . . . . . . . . . . . . . . 12
6.1. Resilience of the commons: routing security . . . . . . . 12
6.2. Getting to the Next Version of TLS . . . . . . . . . . . 13
7. Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Work for the IAB and the IETF . . . . . . . . . . . . . . 13
7.2. Potential for the Internet Research Task Force . . . . . 14
7.3. Opportunities for Others . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. Attendees . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Informative References . . . . . . . . . . . . . . . . . . . 15
The Internet is a complex ecosystem that encompasses all aspects of society. At its heart is a protocol stack with an hourglass shape, and IP at its center. Recent research points to possible explanations for the success of such a design and for the significant challenges that arise when trying to evolve or change its middle section, e.g., as partially evident in the difficulties encountered by IPv6. The workshop had a number of other key examples to consider, including the next generation of HTTP and real time web-browser communications (WebRTC). The eventual success of many if not all of these protocols will largely depend on our understanding of not only what features and design principles contribute lasting value, but also how deployment strategies can succeed in unlocking that value to foster protocol adoption. The latter is particularly important in that most if not all Internet protocols exhibit strong externalities that create strong barriers to adoption, especially in the presence of a well-established incumbent. That is, factors beyond the control of the end points (such as middleboxes) can limit deployment, sometimes by design.
インターネットは、社会のあらゆる側面を網羅する複雑なエコシステムです。その中心には、砂時計の形をしたプロトコルスタックがあり、その中心にIPがあります。最近の研究は、そのような設計の成功と、たとえばIPv6が直面する困難を部分的に明らかにしているように、その中間セクションを進化または変更しようとするときに生じる重大な課題についての考えられる説明を指摘しています。ワークショップには、次世代のHTTPやリアルタイムのWebブラウザー通信（WebRTC）など、検討すべき他の重要な例がいくつかありました。これらのプロトコルのすべてではないにしても多くの最終的な成功は、どの機能と設計原則が永続的な価値に貢献するかだけでなく、プロトコルの採用を促進するために展開戦略がその価値を引き出すのにどのように成功できるかについての理解に大きく依存します。後者は特に重要ですが、ほとんどのインターネットプロトコルが強力な外部性を示すため、特に確立された既存企業の存在下では、採用に対する強力な障壁が生まれます。つまり、エンドポイントの制御が及ばない要因（ミドルボックスなど）によって、場合によっては設計上、展開が制限されることがあります。
The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF), under the leadership of the Internet Engineering Steering Group (IESG) and area directorates.
インターネットアーキテクチャボード（IAB）は、インターネットの長期的な問題と戦略を検討し、インターネットアーキテクチャの将来の方向性を提案するように設計されたワークショップを時折開催します。 IABのこの長期計画機能は、インターネットエンジニアリングステアリンググループ（IESG）と地域のディレクターのリーダーシップの下で、インターネットエンジニアリングタスクフォース（IETF）のワーキンググループによって実行されているエンジニアリングの取り組みを補完します。
Taking into account [RFC5218] on what makes a protocol successful, this workshop sought to explore how the complex interactions of protocols' design and deployment affect their success. One of the workshop's goals was, therefore, to encourage discussions to develop an understanding of what makes protocol designs successful not only in meeting initial design goals but more importantly in their ability to evolve as these goals and the available technology change. Another equally important goal was to develop protocol deployment strategies that ensure that new features can rapidly gain enough of a foothold to ultimately realize broad adoption. Such strategies must be informed by both operational considerations and economic factors.
プロトコルを成功させる理由について[RFC5218]を考慮して、このワークショップでは、プロトコルの設計と展開の複雑な相互作用がその成功にどのように影響するかを探求しました。したがって、ワークショップの目標の1つは、プロトコル設計が最初の設計目標を満たすだけでなく、これらの目標や利用可能なテクノロジーの変化に応じて進化する能力においてさらに成功する理由を理解するための議論を促すことでした。同様に重要なもう1つの目標は、新しい機能が最終的に幅広い採用を実現するのに十分な基盤を迅速に獲得できるようにするプロトコル展開戦略を開発することでした。そのような戦略は、運用上の考慮事項と経済的要因の両方によって通知されなければなりません。
Participants in this workshop consisted of operators, researchers from the fields of computer science and economics, and engineers. Contributions were wide ranging. As such, this report makes few recommendations for the IETF to consider.
このワークショップの参加者は、オペレーター、コンピューターサイエンスと経済学の分野の研究者、エンジニアで構成されていました。貢献は多岐にわたりました。そのため、このレポートでは、IETFが検討すべき推奨事項はほとんどありません。
This report records the participants' discussions. At the end, workshop participants reviewed potential follow-up items. These will be highlighted at each point during the report, and a summary is given at the end.
このレポートには、参加者の議論が記録されます。最後に、ワークショップの参加者は潜在的なフォローアップ項目を確認しました。これらはレポートの各ポイントで強調表示され、最後に要約が表示されます。
Section 2 reviews the motivations and existing work, and Section 3 discusses the economics of protocol adoption. Section 4 covers innovative models for protocol adoption. Section 5 delves into an examination of recent standards issues and some success stories. Section 6 examines different views of success factors. Finally, Section 7 examines potential next steps.
セクション2では、動機と既存の作業をレビューし、セクション3では、プロトコル採用の経済性について説明します。セクション4では、プロトコル採用のための革新的なモデルについて説明します。セクション5では、最近の標準の問題といくつかの成功事例について考察します。セクション6では、成功要因のさまざまな見方を検討します。最後に、セクション7では、潜在的な次のステップを検討します。
Our workshop began with an introduction that asks the question: is the neck of the Internet hourglass closed for business? There are numerous instances where progress has been slow, the three biggest that come to mind being IPv6 [RFC2480], the Stream Control Transmission Protocol (SCTP) [RFC4960], and DNS Security (DNSSEC) [RFC4034]. The impact of DNSSEC is of particular interest, because it is relied upon for the delivery of other services, such as DNS-Based Authentication of Named Entities (DANE) [RFC6698], and it could be used for application discovery services through DNS (specifically where security properties are part of that discovery). Thus, slowdown at the neck of the glass can have an impact closer to the lip.
私たちのワークショップは、質問をする導入で始まりました：インターネット砂時計の首はビジネスのために閉じられていますか？進歩が遅い多くの例があり、IPv6 [RFC2480]、ストリーム制御伝送プロトコル（SCTP）[RFC4960]、およびDNSセキュリティ（DNSSEC）[RFC4034]の3つが頭に浮かびます。 DNSSECは、名前付きエンティティのDNSベースの認証（DANE）[RFC6698]などの他のサービスの配信に依存しており、DNSを介したアプリケーション検出サービス（特にセキュリティプロパティはその発見の一部です）。このように、ガラスのネックでの減速は、唇により近い影響を与える可能性があります。
Even when one considers the classic neck of the hourglass to be IP and transport layers, it was suggested that the hourglass might extend as high as the application layer.
砂時計の古典的なネックがIPおよびトランスポートレイヤーであると考える場合でも、砂時計はアプリケーションレイヤーと同じくらい高い可能性があることが示唆されました。
______________________
\ /
\ Applications /
\ /
\ /
\ /
\__________/
| HTTP(s)|
|________|
/ \
/ TCP/IP \
/______________\
/ MPLS/ \
/ Framing \
/____________________\
/ Physical \
/________________________\
HTTP(s) as the new neck?
新しいネックとしてのHTTP（s）？
This idea was rebutted by the argument that protocols do continue to evolve, that protocols like SMTP and IMAP in the applications space have continued to evolve, as has the transport layer.
このアイデアは、プロトコルが進化し続け、アプリケーションスペースにおけるSMTPやIMAPなどのプロトコルが、トランスポート層と同様に進化し続けているという議論に反論しました。
The workshop moved on to a review of RFC 5218, which discusses protocol success factors. This work was presented in the IETF 70 plenary and was the basis for this ongoing work. There were two clear outcomes from the discussion. The first was that the Internet Architecture Board should review and consider that document in the context of evaluating Birds of a Feather (BoF) session proposals at the IETF, so that any working group proposal is carefully crafted to address a specific design space and provide positive net value. Another aspect was to continue work on tracking the value-specific works in terms of success, wild success, or failure. On that last point, failure remains difficult to judge, particularly at the neck of the hourglass.
ワークショップは、プロトコルの成功要因を議論するRFC 5218のレビューに移りました。この作業はIETF 70プレナリーで発表され、この進行中の作業の基礎となりました。議論から2つの明確な結果がありました。 1つ目は、Internet Architecture BoardがIETFでBirds of a Feather（BoF）セッションの提案を評価する状況でそのドキュメントをレビューおよび検討する必要があることです。正味額。もう1つの側面は、成功、大成功、または失敗の観点から、値固有の作業を追跡する作業を継続することでした。その最後の点で、失敗は特に砂時計の首で判断するのが難しいままです。
Several papers were presented that looked at economic aspects of protocol adoption.
プロトコル採用の経済的側面を検討したいくつかの論文が発表されました。
3.1. When can bundling help adoption of network technologies or services?
3.1. バンドルは、いつネットワークテクノロジーまたはサービスの採用に役立ちますか？
Economics of bundling is a long-studied field, but not as applied to protocols. It is relevant to the IETF and inherent to two key notions: layering and "mandatory to implement". Two current examples include DANE atop DNSSEC and WebRTC atop SCTP. The workshop reviewed a model [Weber13] that explores how bundling of two technologies may lead to increased or decreased adoption of one or both. This will depend on a number of factors, including costs, benefits, and externalities associated with each technology. (Simply put, an externality is an effect or use decision by one set of parties that has either a positive or negative impact on others who did not have a choice or whose interests were not taken into account.) Bundling of capabilities may provide positive value when individual capabilities on their own do not provide sufficient critical mass to propel further adoption. Specifically, bundling can help when one technology does not provide positive value until critical mass of deployment exists, and where a second technology has low adoption cost and immediate value and hence drives initial adoption until enough of a user base exists to allow critical mass sufficient for the first technology to get positive value. One question was what happens where one technology depends on the other. That is directly tied to "mandatory to implement" discussions within the IETF. That is a matter for follow-on work. IETF participants can provide researchers anecdotal experience to help improve models in this area.
バンドリングの経済学は長い間研究されてきた分野ですが、プロトコルには適用されていません。これはIETFに関連し、2つの主要な概念に固有です：レイヤリングと「実装する必要があります」。現在の2つの例には、DNSSEC上のDANEとSCTP上のWebRTCがあります。ワークショップでは、2つのテクノロジーをバンドルすることで、どちらか一方または両方の採用が増加または減少する可能性があることを調査するモデル[Weber13]をレビューしました。これは、各テクノロジーに関連するコスト、メリット、外部性など、多くの要因に依存します。 （簡単に言えば、外部性とは、選択肢のない、または利害が考慮されなかった他者にプラスまたはマイナスの影響を与える一連の当事者による影響または使用の決定です。）機能のバンドルは、プラスの価値を提供する可能性があります。個々の機能だけでは、さらなる採用を推進するのに十分なクリティカルマスを提供できない場合。具体的には、1つのテクノロジーが展開の重要な質量が存在するまで正の値を提供しない場合、および2番目のテクノロジーの導入コストが低く、価値がすぐにあるため、十分なユーザーベースが存在するまで十分なユーザーベースが存在するまで初期導入を推進する場合、バンドルはポジティブな価値を得る最初のテクノロジー。 1つの質問は、あるテクノロジーが他のテクノロジーに依存している場合に何が起こるかということでした。これは、IETF内での「実装が必須」の議論に直接関連しています。それは後続作業の問題です。 IETFの参加者は、研究者に逸話的な体験を提供して、この領域のモデルの改善に役立てることができます。
The workshop considered an examination of protocol success factors in the context of Bitcoin [Boehme13]. Here, there were any number of barriers to success, including adverse press, legal uncertainties, glitches and breaches, previous failed attempts, and speculative attacks. Bitcoin has thus far overcome these barriers thanks to several key factors:
ワークショップでは、ビットコイン[Boehme13]のコンテキストでのプロトコル成功要因の検討について検討しました。ここでは、不利な報道、法的な不確実性、グリッチや違反、以前の失敗した試み、投機的な攻撃など、成功への障壁がいくつもありました。ビットコインはこれまで、いくつかの重要な要因のおかげでこれらの障壁を克服しています。
o First, there is a built-in reward system for early adopters. Participants are monetarily rewarded at an exponentially declining rate.
o まず、アーリーアダプター向けの組み込みの報酬システムがあります。参加者は、指数関数的に減少するレートで金銭的に報われます。
o There exist exchanges or conversion mechanisms to directly convert Bitcoin to other currencies.
o ビットコインを他の通貨に直接変換する交換または変換メカニズムが存在します。
o Finally, there is some store of value in the currency itself, e.g., people find intrinsic value in it.
o 最後に、通貨自体にいくつかの値のストアがあります。たとえば、人々はそれに本質的な価値を見出します。
The first two of these factors may be transferable to other approaches. One key protocol success factor is direct benefit to the participant. Another key protocol success factor is the ability to interface with other systems for mutual benefit. In the context of Bitcoin, there has to be a way to exchange the coins for other currencies. The Internet email system had simpler adaption mechanisms to allow interchange with non-Internet email systems; this facilitated its success. Another more simply stated approach is "IP over everything".
これらの要素の最初の2つは、他のアプローチに転用できます。プロトコルの成功要因の1つは、参加者にとっての直接的なメリットです。もう1つの重要なプロトコルの成功要因は、相互の利益のために他のシステムとインターフェースする機能です。ビットコインのコンテキストでは、コインを他の通貨に交換する方法が必要です。インターネット電子メールシステムには、インターネット以外の電子メールシステムとの交換を可能にする、より単純な適応メカニズムがありました。これはその成功を促進しました。より簡単に述べられたもう1つのアプローチは、「すべてを超えるIP」です。
A key message from this presentation is that if a protocol imposes externalities or costs on other systems, find a means to establish incentives for those other players for implementation. As it happens, there is a limited example that is directly relevant to the IETF.
このプレゼンテーションからの重要なメッセージは、プロトコルが他のシステムに外部性またはコストを課す場合、実装のために他のプレーヤーにインセンティブを確立する手段を見つけることです。たまたま、IETFに直接関連する限定的な例があります。
3.3. Long term strategy for a successful deployment of DNSSEC - on all levels
3.3. DNSSECの展開を成功させるための長期的な戦略-すべてのレベル
The workshop reviewed the approach Sweden's .SE registry has taken to improving deployment of DNSSEC [Lowinder13]. .SE has roughly 1.5 million domains. IIS (<https://www.iis.se>) manages the ccTLD (Country Code Top Level Domain). They made the decision to encourage deployment of DNSSEC within .SE. They began by understanding what the full ecosystem looked like, who their stakeholders were, and the financial, legal, and technical aspects to deployment. As they began their rollout, they charged extra for DNSSEC. As they put it, this didn't work very well.
ワークショップでは、スウェーデンの.SEレジストリがDNSSECの展開を改善するために取ったアプローチを検討しました[Lowinder13]。 .SEには約150万のドメインがあります。 IIS（<https://www.iis.se>）はccTLD（国コードトップレベルドメイン）を管理します。彼らは、.SE内でDNSSECの導入を奨励することを決定しました。最初に、エコシステム全体の外観、利害関係者は誰か、導入の財務、法的、技術的側面を理解しました。彼らがロールアウトを開始したとき、彼らはDNSSECに追加料金を請求しました。彼らが言ったように、これはあまりうまくいきませんでした。
They went on to fund development of OpenDNSSEC to remove technical barriers to deployment at end sites, noting that tooling was lacking in this area. Even with this development, more tooling is necessary, as they point out a need for APIs between the signing zone and the registrar.
彼らは、OpenDNSSECの開発に資金を提供し、エンドサイトでの展開に対する技術的な障壁を取り除き、ツールがこの領域に欠けていることに注目しました。この開発でも、署名ゾーンとレジストラ間のAPIの必要性を指摘しているため、より多くのツールが必要です。
To further encourage deployment, the government of Sweden provided financial incentives to communities to see that their domains were signed. .SE further provided an incentive to registrars to see that their domains were signed. In summary, .SE examined all the players and provided incentives for each to participate.
展開をさらに促進するために、スウェーデン政府はコミュニティにドメインが署名されたことを確認するための金銭的インセンティブを提供しました。 .SEはさらに、ドメインが署名されたことを確認するためにレジストラにインセンティブを提供しました。要約すると、.SEはすべてのプレーヤーを調査し、各プレーヤーが参加するインセンティブを提供しました。
The workshop discussed whether or not this model could be applied to other domains. .SE was in a position to effectively subsidize DNS deployment because of their ability to set prices. This may be appropriate for certain other top-level domains, but it was pointed out that the margins of other domains do not allow for a cost reduction to be passed on at this point in time.
ワークショップでは、このモデルを他のドメインに適用できるかどうかについて議論しました。 .SEは、価格を設定できるため、DNSの展開を効果的に助成できる立場にありました。これは他の特定のトップレベルドメインに適している可能性がありますが、他のドメインのマージンでは、現時点でコスト削減を引き継ぐことができないことが指摘されました。
One of the goals of the workshop was to provide ways to determine when work in the IETF was likely to lead to adoption. The workshop considered an interactive approach that combines value net analysis, deployment environment analysis, and technical architecture analysis that leads to feasibility and solution analysis [Leva13]. This work provided an alternative to RFC 5218 that had many points in common. The case study examined was that of Multipath TCP (MPTCP). Various deployment challenges were observed. First and foremost, increasing bandwidth within the network seems to decrease the attractiveness of MPTCP. Second, the benefit/cost tradeoff by vendors was not considered attractive. Third, not all parties may agree on the benefits.
ワークショップの目標の1つは、IETFでの作業が採用につながる可能性が高い時期を判断する方法を提供することでした。ワークショップでは、バリューネット分析、展開環境分析、および実現可能性とソリューション分析につながる技術アーキテクチャ分析を組み合わせたインタラクティブなアプローチについて検討しました[Leva13]。この作業は、多くの共通点を持つRFC 5218の代替手段を提供しました。調査したケーススタディは、マルチパスTCP（MPTCP）のケーススタディでした。さまざまな展開の課題が確認されました。何よりもまず、ネットワーク内の帯域幅を増やすと、MPTCPの魅力が低下するようです。第二に、ベンダーによる利益/コストのトレードオフは魅力的とは見なされませんでした。第三に、すべての当事者が利益に同意するわけではありません。
Solutions analysis suggested several approaches to improve deployment, including using open-source software, lobbying various implementers, deploying proxies, and completing implementations by parties that own both ends of a connection.
ソリューション分析では、オープンソースソフトウェアの使用、さまざまな実装者へのロビー活動、プロキシの配備、接続の両端を所有する当事者による実装の完了など、配備を改善するいくつかのアプローチが示唆されました。
When given the choice between vanilla and chocolate, why not choose both? The workshop considered an approach that became a recurring theme throughout the workshop -- to not examine when it was necessary to make a choice between technologies, but rather to implement multiple mechanisms to achieve adoption [Welzl13]. The workshop discussed the case of Skype, where it will use the best available transport mechanism to improve communication between clients, rather than tie fate to any specific transport. The argument goes that such an approach provides a means to introduce new transports such as SCTP. This would be an adaptation of "Happy Eyeballs" [RFC6555].
バニラとチョコレートのどちらかを選択したら、両方を選択してみませんか？ワークショップでは、ワークショップ全体で繰り返しテーマとなるアプローチについて検討しました。テクノロジー間の選択を行う必要がある場合を検討するのではなく、採用を達成するために複数のメカニズムを実装することです[Welzl13]。ワークショップでは、特定のトランスポートに運命を結びつけるのではなく、クライアント間の通信を改善するために利用可能な最良のトランスポートメカニズムを使用するSkypeのケースについて説明しました。そのようなアプローチは、SCTPなどの新しいトランスポートを導入する手段を提供するとの議論は続きます。これは「Happy Eyeballs」[RFC6555]の改作です。
There were several approaches presented that examined how we look at protocol adoption.
プロトコルの採用をどのように検討するかを検討するいくつかのアプローチが提示されました。
4.1. On the Complexity of Designed Systems (and its effect on protocol deployment)
4.1. 設計されたシステムの複雑さ（およびプロトコル展開への影響）
The workshop reviewed a comparison between the hourglass model and what systems biologists might call the bow tie model [Meyer13]. The crux of this comparison is that both rely on certain building blocks to accomplish a certain end. In the case of our hourglass model, IP sits notably in the center, whereas in the case of systems biology, adenosine triphosphate (ATP) is the means by which all organisms convert nutrients to usable energy, and thus resides centrally within the biological system.
ワークショップでは、砂時計モデルと、生物学者が蝶ネクタイモデルと呼ぶシステム[Meyer13]との比較について検討しました。この比較の要点は、どちらも特定のビルディングブロックに依存して特定の目的を達成することです。私たちの砂時計モデルの場合、IPは特に中心にありますが、システム生物学の場合、アデノシン三リン酸（ATP）は、すべての生物が栄養素を使用可能なエネルギーに変換する手段であり、したがって、生物系の中心に存在します。
The workshop also examined the notion of "robust yet fragile", which examines the balance between the cost of implementing robust systems versus their value. That is, highly efficient systems can prove fragile in the face of failure or may prove hard to evolve.
ワークショップでは、「堅牢でありながら壊れやすい」という概念についても検討しました。これは、堅牢なシステムを実装するコストとその価値のバランスを検討するものです。つまり、非常に効率的なシステムは、障害に直面しても壊れやすいことが判明したり、進化が困難になったりする場合があります。
The key question asked during this presentation was how we could apply what has been learned in systems biology or what do the findings reduce to for engineers? The answer was that more work is needed. The discussion highlighted the complexity of the Internet in terms of predicting network behavior. As such, one promising area to examine may be that of network management.
このプレゼンテーション中に尋ねられた主な質問は、システム生物学で学んだことをどのように適用できるか、またはエンジニアが調査結果をどのように削減できるかということでした。答えはより多くの仕事が必要であるということでした。議論では、ネットワークの動作を予測するという点で、インターネットの複雑さが強調されました。そのため、検討すべき1つの有望な分野は、ネットワーク管理の分野かもしれません。
The workshop considered the difference between planned versus unplanned technology transitions [Kohno13]. They examined several transitions at the link, IP, and application layers in Japan. One key claim in the study is that there is a phase difference in the diversity trend between each layer. The statistics presented show that indeed HTTP is the predominant substrate for other applications. Another point made was that "natural selection" is a strong means to determine technology.
ワークショップでは、計画されたテクノロジ移行と計画外のテクノロジ移行の違いについて検討しました[Kohno13]。彼らは、日本のリンク、IP、およびアプリケーション層でのいくつかの遷移を調査しました。この研究における重要な主張の1つは、各層の多様性の傾向に位相差があることです。提示された統計は、実際にHTTPが他のアプリケーションの主要な基盤であることを示しています。もう1つのポイントは、「自然選択」はテクノロジーを決定する強力な手段であるということです。
Along these lines, there were two papers submitted that examined the formation and changes to the hourglass in the context of evolutionary economics. Unfortunately, the presenter was unable to attend due to illness. The work was discussed at the workshop, and there were different points of view as to the approach.
これらの線に沿って、進化経済学の文脈で砂時計の形成と変化を検討した2つの論文が提出されました。残念ながら、プレゼンターは病気のため出席できませんでした。このワークショップではワークショップについて議論が行われ、アプローチについてはさまざまな見方がありました。
4.3. On Economic Models of Network Technology Adoption, Design, and Viability
4.3. ネットワーク技術の採用、設計、および実行可能性の経済モデルについて
The workshop considered how network protocol capabilities enable certain sorts of services that are beneficial to consumers and service providers. This model looks at smart data pricing (SDP) in which some behavior is desired and rewarded through a pricing model [Sen13]. The example given was use of time-dependent pricing (TDP) and demonstrated how a service provider was able to load shift traffic to off-peak periods. Explicit Congestion Notification (ECN) and RADIUS were used by the project alongside a simple GUI. This sort of work may prove useful to service providers as caching models evolve over time. The question within the room was how will protocol developers consider these sorts of requirements.
ワークショップでは、ネットワークプロトコル機能が、消費者やサービスプロバイダーにとって有益な特定の種類のサービスをどのように実現するかを検討しました。このモデルは、価格設定モデル[Sen13]を通じて何らかの行動が望まれ、報われるスマートデータ価格設定（SDP）を検討します。与えられた例は時間依存価格設定（TDP）の使用であり、サービスプロバイダーがシフトトラフィックをオフピーク期間にロードする方法を示しました。明示的な輻輳通知（ECN）とRADIUSは、シンプルなGUIとともにプロジェクトで使用されました。この種の作業は、キャッシングモデルが時間の経過とともに進化するにつれて、サービスプロバイダーにとって有用な場合があります。部屋の中での問題は、プロトコル開発者がこれらの種類の要件をどのように考慮するかでした。
There were several papers that focused on how standards are produced.
規格の作成方法に焦点を当てた論文がいくつかありました。
One of the biggest barriers to deployment is that of the unseen patent by the non-practicing entity (NPE) [Lear13]. While this problem is relatively well understood by the industry, the discussion looked at patents as a means to improve interoperability. Those who hold patents have the ability to license them in such a way that a single approach towards standardization is the result (e.g., they get to decide the venue for their work).
展開への最大の障壁の1つは、非実務主体（NPE）による目に見えない特許の障壁です[Lear13]。この問題は業界では比較的よく理解されていますが、議論では、相互運用性を向上させる手段として特許を取り上げました。特許を保有する人は、標準化への単一のアプローチが結果となるような方法でそれらをライセンスする能力を持っています（たとえば、彼らは彼らの仕事の場を決めることができます）。
5.2. Bridge Networking Research and Internet Standardization: Case Study on Mobile Traffic Offloading and IPv6 Transition Technologies
5.2. Bridge Networking Research and Internet Standardization：Case Study on Mobile Traffic Offloading and IPv6 Transition Technologies
There was a presentation and discussion about the gap between the research community and standards organizations. Two cases were examined: mobile offloading and IPv6 transition technologies [Ding13]. In the case of mobile offloading, a mechanism was examined that required understanding of both 3GPP (Third Generation Partnership Project) and IETF standards. Resistance in both organizations was encountered. In the 3GPP, the problem was that the organization already had an offloading model in play. In the IETF, the problem was a lack of understanding of the interdisciplinary space. The researchers noted that in the case of the IETF, they may have taken the wrong tack by having jumped into the solution without having fully explained the problem they were trying to solve. In the case of IPv6 transition technologies, researchers encountered a crowded field and not much appetite for new transition technologies.
研究コミュニティと標準化組織の間のギャップについてのプレゼンテーションと議論がありました。 2つのケースが検討されました：モバイルオフロードとIPv6移行テクノロジ[Ding13]。モバイルオフロードの場合、3GPP（第3世代パートナーシッププロジェクト）とIETF標準の両方を理解する必要があるメカニズムが検討されました。両方の組織で抵抗が発生しました。 3GPPでの問題は、組織がすでにオフロードモデルを使用していたことでした。 IETFでの問題は、学際的な空間に対する理解の欠如でした。研究者たちは、IETFの場合、解決しようとしている問題を完全に説明せずにソリューションに飛び込んだため、間違った方法をとった可能性があると指摘しました。 IPv6移行テクノロジーの場合、研究者は混雑した分野に出会い、新しい移行テクノロジーへの欲求はあまりありませんでした。
The workshop discussed whether the standards arena is the best venue or measurement of success for researchers. The IRTF is meant to bridge academic research and the IETF. As we will discuss below, several avenues for continued dialog are contemplated.
ワークショップでは、標準アリーナが研究者にとって最高の場所であるか、成功の尺度であるかについて議論しました。 IRTFは、学術研究とIETFをつなぐことを目的としています。以下で説明するように、継続的な対話にはいくつかの方法が考えられます。
The workshop engaged in a very provocative discussion about whether the existing Internet architecture serves the broadest set of needs. Three specific aspects were examined: geographic, technical, and socioeconomic. Researchers presented an alternative hourglass or protocol architecture known as Lowest Common Denominator Networking (LCDNet) that re-examines some of the base assumptions of the existing architecture, including its "always on" nature [Sathiaseelan13].
ワークショップでは、既存のインターネットアーキテクチャが幅広いニーズに対応できるかどうかについて非常に挑発的な議論が行われました。地理的、技術的、社会経済的な3つの特定の側面が検討されました。研究者は、「常にオン」の性質を含む既存のアーキテクチャの基本的な仮定の一部を再検討する、Lowest Common Denominator Networking（LCDNet）として知られる代替の砂時計またはプロトコルアーキテクチャを提示しました[Sathiaseelan13]。
The workshop questioned many of the baseline assumptions of the researchers. In part, this may have been due to constrained discussion time on the topic, where a fuller explanation was warranted.
ワークショップは、研究者のベースラインの仮定の多くに質問しました。部分的には、これは、より完全な説明が必要とされたトピックに関する制約されたディスカッション時間が原因であった可能性があります。
The workshop held a number of other discussions about different approaches to technology adoption. We should highlight that a number of papers were submitted to the workshop on routing security, two of which were not possible to present.
ワークショップでは、テクノロジー採用へのさまざまなアプローチについて、他にも多くの議論が行われました。ルーティングセキュリティに関するワークショップに多数の論文が提出されたことを強調する必要がありますが、そのうち2つは提示できませんでした。
The workshop discussed a presentation on the tragedy of the commons in the context of global inter-domain routing [Robachevsky13]. The "Internet Commons" is a collection of networks that we depend on but do not control. The main threat to the commons in the context of BGP is routing pollution, or unwanted or unnecessary routing entries. The Internet Society has been working with service providers to improve resiliency by driving a common understanding of both problem and solution space and by developing a shared view with regard to risk and benefits, with the idea being that there would be those who would engage in reciprocal cooperation with the hopes that others would do similarly in order to break the tragedy.
ワークショップでは、グローバルなドメイン間ルーティングのコンテキストでのコモンズの悲劇に関するプレゼンテーションについて議論しました[Robachevsky13]。 「インターネットコモンズ」は、私たちが依存しているが制御していないネットワークの集まりです。 BGPのコンテキストでのコモンズへの主な脅威は、ルーティング汚染、または不要または不要なルーティングエントリです。インターネットソサエティは、サービスプロバイダーと協力して、問題とソリューションの両方の領域について共通の理解を深め、リスクとメリットに関する共通の見解を発展させることで、耐障害性を向上させ、相互に関与する人々がいると考えています他の人が悲劇を打破するために同様に行うことを期待して協力。
What was notable in discussion was that there was no magic bullet to addressing the resiliency issue, and that this was a matter of clearly identifying the key players and convincing them that their incentives were aligned. It also involved developing approaches to measure resiliency.
議論で注目に値するのは、回復力の問題に対処するための特効薬はなく、これは主要なプレーヤーを明確に特定し、彼らのインセンティブが一致していることを彼らに納得させることでした。また、回復力を測定するためのアプローチの開発も必要でした。
Originally, the workshop had planned to look at the question of whether the IETF could mandate stronger security. This evolved into a discussion about getting to the next version of Transport Layer Security (TLS) and what challenges lie ahead. It was pointed out that there were still many old versions of TLS in existence today, due to many old implementations. In particular, it was pointed out that a substantial amount of traffic is still encrypted using Triple DES.
当初、ワークショップは、IETFがより強力なセキュリティを義務付けることができるかどうかの問題を検討することを計画していました。これは、トランスポート層セキュリティ（TLS）の次のバージョンへの移行と、今後の課題についての議論に発展しました。多くの古い実装が原因で、今日でも多くの古いバージョンのTLSが存在していることが指摘されました。特に、かなりの量のトラフィックがトリプルDESを使用して暗号化されていることが指摘されました。
One concern about the next generation is that perfect could become the enemy of good. Another point that was made was that perhaps a testing platform might help interoperability. Finally, there was some discussion about how new versions of TLS get promoted.
次世代についての1つの懸念は、完璧が善の敵になる可能性があるということです。もう1つのポイントは、おそらくテストプラットフォームが相互運用性に役立つ可能性があるということです。最後に、TLSの新しいバージョンがどのように昇格されるかについての議論がありました。
This wide-ranging workshop discussed many aspects that go to the success or failure of the work of the IETF. While there is no single silver bullet that we can point to for making a protocol successful, the workshop did discuss a number of outcomes and potential next steps.
この幅広いワークショップでは、IETFの作業の成功または失敗に至る多くの側面について議論しました。プロトコルを成功させるために私たちが指摘できる単一の特効薬はありませんが、ワークショップは多くの結果と潜在的な次のステップについて話し合いました。
The IAB's role in working group formation consists of providing guidance to the IESG on which Birds of a Feather sessions should be held, reviewing proposed working group charters, and shepherding some work so that it can reach a suitable stage for standardization. In each of these stages, the IAB has an opportunity to apply the lessons of RFC 5218, as well as other work such as the notion of bundling choices, when members give advice.
ワーキンググループの形成におけるIABの役割は、Birds of the Featherセッションを開催する必要があるIESGにガイダンスを提供し、提案されたワーキンググループチャーターをレビューし、標準化に適した段階に到達できるようにいくつかの作業を導くことです。これらの各段階で、IABは、RFC 5218のレッスン、およびメンバーがアドバイスを提供するときに、バンドルの選択の概念などの他の作業を適用する機会があります。
In addition to working group creation, the IAB has an opportunity to track and present protocol success stories, either through wikis or through discussion at plenary sessions. For instance, at the time of writing, there is much interest in Bitcoin, its success, and what parallels and lessons can be drawn. Specifically, it would be useful to track examples of first-mover advantages.
ワーキンググループの作成に加えて、IABは、Wikiまたは全体会議での議論を通じて、プロトコルの成功事例を追跡して提示する機会があります。たとえば、執筆時点では、ビットコイン、その成功、および類似点と教訓を何に引き出すことができるかに大きな関心があります。特に、先発者の利点の例を追跡することは有用です。
Finally, one area that the IETF may wish to consider, relating specifically to DNSSEC, as raised by our speakers was standardization of the provisioning interface of DNSSEC (DS keys) between parent and child zone. Contributions in this area would be welcome.
最後に、スピーカーが提起した、特にDNSSECに関連してIETFが検討する可能性がある1つの領域は、親ゾーンと子ゾーン間のDNSSEC（DSキー）のプロビジョニングインターフェイスの標準化でした。この分野での貢献は大歓迎です。
There are at least two possible activities that the IRTF might wish to consider. The first would be a research group that considers protocol alternatives and recommendations that might be useful in areas where environments are constrained, due to bandwidth or other resources. Such a group has already been proposed, in fact.
IRTFが検討したいと思う可能性のある活動が少なくとも2つあります。 1つ目は、帯域幅やその他のリソースが原因で環境が制約されている領域で役立つ可能性のあるプロトコルの選択肢と推奨事項を検討する研究グループです。実際、そのようなグループはすでに提案されています。
The second possibility is a more general group that focuses on economic considerations relating to Internet protocol design. In particular, there were a number of areas that were presented to the working group that deserve further investigation and could use collaboration between researchers, engineers, and operators. Two examples are work on bundling and systems biology.
2番目の可能性は、インターネットプロトコル設計に関連する経済的な考慮事項に焦点を当てたより一般的なグループです。特に、ワーキンググループに提示された、調査に値する多くの領域があり、研究者、エンジニア、およびオペレーター間のコラボレーションを使用することができました。 2つの例は、バンドル化とシステム生物学に関する作業です。
Incentive models often involve many different players. As we considered work in the workshop, our partners such as ICANN and the Regional Internet Registries (RIRs) can continue to play a role in encouraging deployment of protocols through their policies. Their members can also participate in any activity of the IRTF that is related to this work.
インセンティブモデルには多くの場合、さまざまなプレーヤーが関与します。ワークショップでの作業を検討したため、ICANNや地域インターネットレジストリ（RIR）などのパートナーは、ポリシーを通じてプロトコルの展開を促進する上で引き続き役割を果たすことができます。メンバーは、この作業に関連するIRTFのアクティビティにも参加できます。
Specifically, RIRs have a specific role to play in encouraging security of the routing system, and ICANN has a specific role to play in securing the domain name service.
具体的には、RIRはルーティングシステムのセキュリティを促進するために果たす特定の役割を持ち、ICANNはドメインネームサービスを保護するために果たす特定の役割を果たします。
The suggestion was made that the IETF working groups could leverage graduate students in many universities around the world in helping review documents (Internet-Drafts, RFCs, etc.). This would serve as a source of education in real-world processes to students and would engage the research community in IETF processes more thoroughly; it would also provide a scale-out resource for handling the IETF review workload. Several attendees who have such students were prepared to try this out.
IETFワーキンググループが世界中の多くの大学の大学院生を活用してドキュメント（インターネットドラフト、RFCなど）のレビューを支援できるという提案がなされました。これは、学生に対する現実世界のプロセスにおける教育の源として役立ち、IETFプロセスに研究コミュニティをより徹底的に関与させることになります。また、IETFレビューワークロードを処理するためのスケールアウトリソースも提供します。そのような学生がいる数人の参加者はこれを試す準備ができていました。
This document does not discuss a protocol. Security for the workshop itself was excellent.
このドキュメントではプロトコルについては説明しません。ワークショップ自体のセキュリティは優れていました。
The IAB would like to thank the program committee, who consisted of Roch Guerin, Constantine Dovrolis, Hannes Tschofenig, Joel Halpern, Eliot Lear, and Richard Clayton, as well as Bernard Aboba and Dave Thaler. Their earlier work provided a strong basis for this workshop.
IABは、プログラム委員会に感謝します。プログラム委員会は、ゲリン湖、コンスタンティンドヴロリス、ハネスチョフェニグ、ジョエルハルパーン、エリオットリア、リチャードクレイトン、およびバーナードアボバとデイブターラーで構成されています。彼らの以前の仕事は、このワークショップの強力な基礎を提供しました。
A special debt of gratitude is owed to our hosts, Ross Anderson and Richard Clayton, for arranging an excellent venue for our discussions.
私たちの議論のための優れた会場を手配してくれたホスト、ロスアンダーソンとリチャードクレイトンには、特別な感謝の気持ちがありました。
The following people attended the ITAT workshop:
以下の人々がITATワークショップに参加しました：
Aaron Yi Ding, Adrian Farrel, Andrei Robachevsky, Andrew Sullivan, Arjuna Sathiaseelan, Bjoern Zeeb, Dave Meyer, Dave Thaler, Dongting Yu, Eliot Lear, Elwyn Davies, Erik Nordmark, Hannes Tschofenig, Joel Halpern, Jon Crowcroft, Lars Eggert, Martin Stiemerling, Michael Welzl, Michiel Leenaars, Miya Kohno, Rainer Boehme, Richard Clayton, Roch Guerin, Ross Anderson, Russ Housley, Sam Smith, Sean Turner, Soumya Sen, Spencer Dawkins, Steven Weber, Tapio Levae, Toby Moncaster, Tony Finch
アーロン・イー・ディン、エイドリアン・ファレル、アンドレイ・ロバチェフスキー、アンドリュー・サリバン、アルジュナ・サティアシーラン、ビョルン・ジーブ、デイブ・マイヤー、デイブ・ターラー、ドンティング・ユー、エリオット・リア、エルウィン・デイビス、エリック・ノードマーク、ハンネス・ショコフェニグ、ジョエル・ハルパーン、ジョン・クロウクロフト、ジョン・クロウクロフトStiemerling、Michael Welzl、Michiel Leenaars、Miya Kohno、Rainer Boehme、Richard Clayton、Roch Guerin、Ross Anderson、Russ Housley、Sam Smith、Sean Turner、Soumya Sen、Spencer Dawkins、Steven Weber、Tapio Levae、Toby Moncaster、Tony Finch
[Boehme13] Boehme, R., "Internet Protocol Adoption: Learning from Bitcoin", December 2013, <http://www.iab.org/wp-content/ IAB-uploads/2013/06/itat-2013_submission_17.pdf>.
[Boehme13] Boehme、R.、「インターネットプロトコルの採用：ビットコインから学ぶ」、2013年12月、<http://www.iab.org/wp-content/ IAB-uploads / 2013/06 / itat-2013_submission_17.pdf> 。
[Ding13] Yi Ding, A., Korhonen, J., Savolainen, T., Kojo, M., Tarkoma, S., and J. Crowcroft, "Bridge Networking Research and Internet Standardization: Case Study on Mobile Traffic Offloading and IPv6 Transition Technologies", December 2013, <http://www.iab.org/wp-content/IAB-uploads/2013/06/ itat-2013_submission_6.pdf>.
[Ding13] Yi Ding、A.、Korhonen、J.、Savolainen、T.、Kojo、M.、Tarkoma、S。、およびJ. Crowcroft、「Bridge Networking Research and Internet Standardization：Case Study on Mobile Traffic Offloading and IPv6 Transition Technologies」、2013年12月、<http://www.iab.org/wp-content/IAB-uploads/2013/06/ itat-2013_submission_6.pdf>。
[Kohno13] Kohno, M., Asaba, T., and F. Baker, "Managing Diversity to Manage Technological Transition", December 2013, <http://www.iab.org/wp-content/IAB-uploads/2013/06/ itat-2013_submission_7.pdf>.
[Kohno13]河野雅夫、浅葉敏夫、Fベイカー、「多様性の管理による技術移行の管理」、2013年12月、<http://www.iab.org/wp-content/IAB-uploads/2013 / 06 / itat-2013_submission_7.pdf>。
[Lear13] Lear, E. and D. Mohlenhoff, "Standards: a love/hate relationship with patents", December 2013, <http://www.iab.org/wp-content/IAB-uploads/2013/06/ itat-2013_submission_11.docx>.
[Lear13] Lear、E。およびD. Mohlenhoff、「標準：特許との愛/憎しみの関係」、2013年12月、<http://www.iab.org/wp-content/IAB-uploads/2013/06/ itat-2013_submission_11.docx>。
[Leva13] Leva, T. and H. Soumi, "Framework for analyzing feasibility of Internet protocols", December 2013, <http://www.iab.org/wp-content/IAB-uploads/2013/06/ itat-2013_submission_4.pdf>.
[Leva13] Leva、T。およびH. Soumi、「インターネットプロトコルの実現可能性を分析するためのフレームワーク」、2013年12月、<http://www.iab.org/wp-content/IAB-uploads/2013/06/ itat- 2013_submission_4.pdf>。
[Lowinder13] Eklund Lowinder, A. and P. Wallstrom, "Long term strategy for a successful deployment of DNSSEC - on all levels", December 2013, <http://www.iab.org/wp-content/ IAB-uploads/2013/06/itat-2013_submission_5.docx>.
[Lowinder13] Eklund Lowinder、A。およびP. Wallstrom、「DNSSECの展開を成功させるための長期戦略-すべてのレベルで」、2013年12月、<http://www.iab.org/wp-content/ IAB-uploads /2013/06/itat-2013_submission_5.docx>。
[Meyer13] Meyer, D., "On the Complexity of Engineered Systems (and its effect on protocol deployment)", December 2013, <http://www.iab.org/wp-content/IAB-uploads/2013/06/ itat-2013_submission_9.pdf>.
[Meyer13] Meyer、D。、「エンジニアドシステムの複雑さ（およびプロトコルデプロイメントへの影響）」、2013年12月、<http://www.iab.org/wp-content/IAB-uploads/2013/06 / itat-2013_submission_9.pdf>。
[RFC2480] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480, January 1999.
[RFC2480] Freed、N。、「Gateway and MIME Security Multiparts」、RFC 2480、1999年1月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、2005年3月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful Protocol?", RFC 5218, July 2008.
[RFC5218] Thaler、D。、およびB. Aboba、「成功するプロトコルを作るもの」、RFC 5218、2008年7月。
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6555] Wing、D。、およびA. Yourtchenko、「Happy Eyeballs：Success with Dual-Stack Hosts」、RFC 6555、2012年4月。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012.
[RFC6698] Hoffman、P。およびJ. Schlyter、「DNSベースの名前付きエンティティの認証（DANE）トランスポート層セキュリティ（TLS）プロトコル：TLSA」、RFC 6698、2012年8月。
[Robachevsky13] Robachevsky, A., "Resilience of the commons: routing security", December 2013, <http://www.iab.org/wp-content/ IAB-uploads/2013/06/itat-2013_submission_12.pdf>.
[Robachevsky13] Robachevsky、A。、「コモンズの回復力：ルーティングセキュリティ」、2013年12月、<http://www.iab.org/wp-content/ IAB-uploads / 2013/06 / itat-2013_submission_12.pdf> 。
[Sathiaseelan13] Sathiaseelan, A., Trossen, D., Komnios, I., Ott, J., and J. Crowcroft, "An Internet Architecture for the Challenged", December 2013, <http://www.iab.org/wp-content/IAB-uploads/2013/06/ itat-2013_submission_3.pdf>.
[Sathiaseelan13] Sathiaseelan、A.、Trossen、D.、Komnios、I.、Ott、J。、およびJ. Crowcroft、「An Internet Architecture for the Challenged」、2013年12月、<http://www.iab.org / wp-content / IAB-uploads / 2013/06 / itat-2013_submission_3.pdf>。
[Sen13] Sen, S., "On Economic Models of Network Technology Adoption, Design, and Viability", December 2013, <http://www.iab.org/wp-content/IAB-uploads/2013/06/ itat-2013_submission_101.pdf>.
[Sen13] Sen、S。、「ネットワーク技術の採用、設計、および実行可能性の経済モデルについて」、2013年12月、<http://www.iab.org/wp-content/IAB-uploads/2013/06/ itat -2013_submission_101.pdf>。
[Weber13] Weber, S., Guerin, R., and J. Oliveira, "When can bundling help adoption of network technologies or services?", December 2013, <http://www.iab.org/wp-content/ IAB-uploads/2013/06/itat-2013_submission_2.pdf>.
[Weber13] Weber、S.、Guerin、R。、およびJ. Oliveira、「バンドルはいつネットワークテクノロジーまたはサービスの採用に役立つのか？」、2013年12月、<http://www.iab.org/wp-content/ IAB-uploads / 2013/06 / itat-2013_submission_2.pdf>。
[Welzl13] Welzl, M., "The "best effort" service as a deployment success factor", December 2013, <http://www.iab.org/wp-content/IAB-uploads/2013/06/ itat-2013_submission_8.pdf>.
[Welzl13] Welzl、M。、「展開成功要因としての「ベストエフォート」サービス」、2013年12月、<http://www.iab.org/wp-content/IAB-uploads/2013/06/ itat- 2013_submission_8.pdf>。
Author's Address
著者のアドレス
Eliot Lear (editor) Richtistrasse 7 Wallisellen, ZH CH-8304 Switzerland
Eliot Lear（編集者）Richtistrasse 7 Wallisellen、ZH CH-8304スイス
Phone: +41 44 878 9200
EMail: lear@cisco.com