[要約] RFC 8980は、プロトコル開発における設計期待と展開現実のギャップに焦点を当てたIABワークショップの報告書です。この文書の目的は、設計段階での期待と実際の展開時の現実との間の違いを理解し、将来のプロトコル設計に役立てることにあります。主に、プロトコル設計者や開発者が、より現実的な展開シナリオを想定し、設計を改善するために利用されます。
Internet Architecture Board (IAB) J. Arkko
Request for Comments: 8980 T. Hardie
Category: Informational February 2021
ISSN: 2070-1721
Report from the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol Development
プロトコル開発における設計期待値と展開現実感に関するIABワークショップからの報告
Abstract
概要
The Design Expectations vs. Deployment Reality in Protocol Development Workshop was convened by the Internet Architecture Board (IAB) in June 2019. This report summarizes the workshop's significant points of discussion and identifies topics that may warrant further consideration.
プロトコル開発ワークショップにおける設計期待値VS.展開現実は、2019年6月にインターネットアーキテクチャ盤（IAB）によって召集されました。この報告書は、ワークショップの重要な議論のポイントをまとめ、さらに検討を保証できるトピックを識別します。
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.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書はインターネットアーキテクチャボード（IAB）の製品であり、IABが恒久的な記録を提供するのに価値があると見なされる情報を表しています。インターネットアーキテクチャボード（IAB）のコンセンサスを表します。IABによる出版の承認済みの文書は、インターネット規格のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8980.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc8980で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。
Table of Contents
目次
1. Introduction
2. Workshop Agenda
3. Position Papers
4. Discussions
4.1. Past Experiences
4.2. Principles
4.3. Centralized Deployment Models
4.4. Security
4.5. Future
5. Conclusions
5.1. Summary of Discussions
5.2. Actions
5.2.1. Potential Architecture Actions and Outputs
5.2.2. Other Potential Actions
5.3. Other Publications
5.4. Feedback
6. Security Considerations
7. Informative References
Appendix A. Participant List
IAB Members at the Time of Approval
Acknowledgements
Authors' Addresses
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).
インターネットアーキテクチャボード（IAB）は、インターネットの長期的な問題と戦略を考慮し、インターネットアーキテクチャの将来の方向を提案するように設計された時折のワークショップを開催しています。IABのこの長期計画機能は、インターネットエンジニアリングタスクフォース（IETF）のワーキンググループによって行われる進行中のエンジニアリング努力に相補的です。
The Design Expectations vs. Deployment Reality in Protocol Development Workshop was convened by the IAB in June 2019. This report summarizes the workshop's significant points of discussion and identifies topics that may warrant further consideration.
プロトコル開発ワークショップにおける設計期待値VS.展開現実は、2019年6月のIABによって召集されました。この報告書は、ワークショップの重要な議論を要約し、さらなる検討を保証できるトピックを識別しています。
The background for the workshop was that during the development and early elaboration phase for a number of protocols, there was a presumption of specific deployment models. Actual deployments have, however, often run contrary to these early expectations when economies of scale, Distributed Denial-of-Service (DDoS) attack resilience, market consolidation, or other factors have come into play. These factors can result in the deployed reality being highly concentrated.
ワークショップの背景は、多くのプロトコルの開発と早期の段階で、特定の展開モデルの推定がありました。しかし、実際の展開は、規模の経済、サービス拒否攻撃回復力、市場の連結、またはその他の要因が発生したときに、これらの初期の期待に反することがよくあります。これらの要因は、展開された現実が非常に集中している可能性があります。
This is a serious issue for the Internet, as concentrated, centralized deployment models present risks to user choice, privacy, and future protocol evolution.
これは、集中しているように、集中型の展開モデルがユーザーの選択、プライバシー、および将来のプロトコルの進化にリスクを呈しているように、インターネットにとって深刻な問題です。
On occasion, the differences from the original expectations were almost immediate, but they also occur after significant time has passed since the protocol's initial development.
時には、元の期待との違いはほぼ即座にありましたが、プロトコルの最初の開発からかなりの時間が経過した後にも発生します。
Some examples are given below.
いくつかの例を以下に示す。
* Email standards, which presumed many providers running in a largely uncoordinated fashion but have seen both significant market consolidation and a need for coordination to defend against spam and other attacks. The coordination and centralized defense mechanisms scale better for large entities; these have fueled additional consolidation.
* 電子メールの標準は、ほとんど非コーーインなファッションで実行されていますが、重要な市場の統合とスパムやその他の攻撃に対して守るための調整の必要性を見ました。調整と集中防衛メカニズムは、大規模なエンティティにとってより良いスケールです。これらは追加の圧密化を促進しました。
* The Domain Name System (DNS), which presumed deep hierarchies but has often been deployed in large, flat zones, leading to the nameservers for those zones becoming critical infrastructure. Future developments in DNS may see concentration through the use of globally available common resolver services, which evolve rapidly and can offer better security. Paradoxically, concentration of these queries into a few services creates new security and privacy concerns.
* ドメインネームシステム（DNS）は、深い階層を推定しているが、多くの場合、大型のゾーンに展開されているため、それらのゾーンが重要なインフラストラクチャになるためのネームサーバがあります。DNSの将来の開発は、世界的に入手可能な一般的なコモンリゾルバサービスを使用することによって集中を見ることができ、それは急速に進化し、より良いセキュリティを提供することができます。逆説的に、これらのクエリのいくつかのサービスへの濃度は、新しいセキュリティとプライバシーの懸念を招きます。
* The Web, which is built on a fundamentally decentralized design but is now often delivered with the aid of Content Delivery Networks (CDNs). Their services provide scaling, distribution, and prevention of denial of service in ways that new entrants and smaller systems operators would find difficult to replicate. While truly small services and truly large services may each operate using only their own infrastructure, many others are left with the only practical choice being the use of a globally available commercial service.
* 根本的に分散したデザインに構築されているが、現在コンテンツ配信ネットワーク（CDN）を用いて提供されることが多い。彼らのサービスは、新しい参加者とより小さなシステム事業者が複製が難しいと思われる方法で、サービス拒否、配布、および予防を提供します。本当に小さなサービスと本当に大規模なサービスがそれぞれ彼ら自身のインフラストラクチャのみを使って動作するかもしれませんが、他の多くの他の人々は世界的に利用可能な商用サービスの使用である唯一の実用的な選択肢を残しました。
Similar developments may happen with future technologies and services. For instance, the growing use of Machine Learning technology presents challenges for distributing effective implementation of a service throughout a pool of many different providers.
将来の技術やサービスと同様の開発が起こる可能性があります。例えば、機械学習技術の利用の成長は、さまざまなプロバイダのプール全体にわたるサービスの効果的な実装を分配するための課題を提示しています。
In [RFC5218], the IAB tackled what made for a successful protocol. In [RFC8170], the IAB described how to handle protocol transitions. The purpose of this workshop was to explore cases where the initial system design assumptions turned out to be wrong, looking for patterns in what caused those assumptions to fail (e.g., concentration due to DDoS resilience) and in how those failures impact the security, privacy, and manageability of the resulting deployments.
[RFC5218]では、IABは正常なプロトコルのために行われたものに取り組みました。[RFC8170]では、IABはプロトコル遷移を処理する方法について説明しました。このワークショップの目的は、最初のシステム設計上の仮定が間違っていることが判明した場合に、これらの仮定が失敗したもの（たとえば、DDoSの回復力による集中）とセキュリティへの影響、プライバシーの影響を求めた場合を探していました。結果の展開の管理性と管理性。
While the eventual goals might include proposing common remediations for specific cases of confounded protocol expectations, this workshop and thus this report focused on identifying patterns.
最終的な目標は、交絡されたプロトコルの期待の特定のケースに対して共通の修復を提案することを含み、このワークショップ、したがってこのレポートはパターンの識別に焦点を当てました。
The workshop call for papers invited the submission of position papers that would:
論文のためのワークショップ呼び出しは、ポジション論文の提出を招待した。
* Describe specific cases where systems assumptions during protocol development were confounded by later deployment conditions.
* プロトコル開発中のシステムの仮定が後の展開条件によって混乱された特定のケースを説明しています。
* Survey a set of cases to identify common factors in these confounded expectations.
* これらの混乱した期待の中で共通の要因を特定する場合のセットを調査します。
* Explore remediations that foster user privacy, security, and provider diversity in the face of these changes.
* ユーザーのプライバシー、セキュリティ、およびプロバイダの多様性を促進する修復を検討してください。
A total of 21 position papers were received and are listed in Section 3. On site or remote were 30 participants; they are listed in Appendix A.
合計21の位置論文を受け取り、セクション3に記載されています。サイトまたはリモートでは30人の参加者でした。それらは付録Aに記載されています。
After opening and discussion of goals for the workshop, the discussion focused on five main topics:
ワークショップの目標の開封と議論の後、議論は5つの主なトピックに焦点を当てました。
* Past experiences. What have we learned?
* 過去の経験。私たちは何を学びましたか？
* Principles. What forces apply to deployment? What principles to take into account in design?
* 原則展開にはどの委員が適用されますか？デザインで考慮する原則は何ですか？
* Centralized deployment models. The good and the bad of centralization. Can centralization be avoided? How?
* 集中型展開モデル集中化の良いと悪い。集中化は避けることができますか？どうやって？
* Security. Are we addressing the right threats? What should we prepare ourselves for?
* セキュリティ正しい脅威に対処していますか？私たちは自分自身を準備するべきですか？
* Future. What can we do? Should we get better at predicting, or should we do different things?
* 未来。私たちは何ができる？私たちは予測で良くなるべきです、それともさまざまなことをするべきですか？
The following position papers were submitted to the workshop by the following people (listed in alphabetical order):
以下の人々によるワークショップに次の位置論文が提出されました（アルファベット順に記載されています）。
* Jari Arkko. "Changes in the Internet Threat Model" [Arkko2019]
* Jari Arkko。「インターネット脅威モデルの変化」[ARKKO2019]
* Vittorio Bertola. "How the Internet Was Won and Where It Got Us" [Bertola2019]
* Vittorio Bertola。「インターネットが勝ったところ、どこで私たちが得たのか」[Bertola2019]
* Carsten Bormann and Jan-Frederik Rieckers. "WiFi authentication: Some deployment observations from eduroam" [Bormann2019]
* Carsten BormannとJan-Frederik Rieckers。"WiFi認証：EDUROAMからの展開観測" [Bormann2019]
* Stéphane Bortzmeyer. "Encouraging better deployments" [Bortzmeyer2019]
* StéphaneBortzmeyer。「より良い展開を促進する」[Bortzmeyer2019]
* Brian Carpenter and Bing Liu. "Limited Domains and Internet Protocols" [Carpenter2019]
* ブライアン大工とビングリュー。「限定ドメインとインターネットプロトコル」[Carpenter2019]
* Alissa Cooper. "Don't Forget the Access Network" [Cooper2019]
* アリッサクーパー。「アクセスネットワークを忘れないで」[Cooper2019]
* Stephen Farrell. "We're gonna need a bigger threat model" [Farrell2019]
* スティーブンファレル。「私たちはより大きな脅威モデルが必要だ」[Farrell2019]
* Phillip Hallam-Baker. "The Devil is in the Deployment" [HallamBaker2019]
* フィリップハラムベイカー。「悪魔は展開にあります」[Hallambaker2019]
* Ted Hardie. "Instant Messaging and Presence: A Cautionary Tale" [Hardie2019]
* 丈夫です。「インスタントメッセージングとプレゼンス：注意の物語」[Hardie2019]
* Paul Hoffman. "Realities in DNSSEC Deployment" [Hoffman2019]
* ポールホフマン。「DNSSEC展開の現実」[HOFFMAN2019]
* Christian Huitema. "Concentration is a business model" [Huitema2019]
* クリスチャンハイマ。「集中はビジネスモデルです」[Huitema2019]
* Geoff Huston. "The Border Gateway Protocol, 25 years on" [Huston2019]
* Geoff Huston。「ボーダーゲートウェイプロトコル、25年」[Huston2019]
* Dirk Kutscher. "Great Expectations: Protocol Design and Socioeconomic Realities" [Kutscher2019]
* ダーククッシャー。「素晴らしい期待：プロトコルデザインと社会経済的現実」[Kutscher2019]
* Julien Maisonneuve. "DNS, side effects and concentration" [Maisonneuve2019]
* Julien Maisonneuve。「DNS、副作用と濃度」[Maisonneuve2019]
* John Mattsson. "Consolidation, Privacy, Jurisdiction, and the Health of the Internet" [Mattsson2019]
* ジョンマットソン。「連結、プライバシー、管轄区域、インターネットの健康」[Mattsson 2019]
* Moritz Müller. "Rolling Forward: An Outlook on Future Root Rollovers" [Muller2019]
* モリッツミュラー。「ローリングフォワード：将来のルートロールオーバー上の展望」[Muller2019]
* Jörg Ott. "Protocol Design Assumptions and PEPs" [Ott2019]
* JörgOtt。「プロトコル設計前提とPEPS」[OTT2019]
* Lucas Pardue. "Some challenges with IP multicast deployment" [Pardue2019]
* Lucas Pardue。「IPマルチキャスト展開に関するいくつかの課題」[PARDUE2019]
* Jim Reid. "Where/Why has DNS gone wrong?" [Reid2019]
* ジム・リード。「どこで/なぜDNSが間違っていましたか？」[REID2019]
* Mohit Sethi and Tuomas Aura. "IoT Security and the role of Manufacturers: A Story of Unrealistic Design Expectations" [Sethi2019]
* Mohit SethiとTuomas Aura。「IOTセキュリティと製造業者の役割：非現実的な設計期待の物語」[Seth2019]
* Andrew Sullivan. "Three kinds of concentration in open protocols" [Sullivan2019]
* Andrew Sullivan。「オープンプロトコルの3種類の濃度」[Sullivan2019]
These papers are available from the IAB website [CFP] [POS].
これらの論文はIABのWebサイト[CFP] [POS]から入手できます。
The workshop investigated deployment cases from certificate authorities for web connections (WebPKI) to DNS Security (DNSSEC), from the Border Gateway Protocol (BGP) to Network Address Translators (NATs), from DNS resolvers to CDNs, and from Internet of Things (IoT) systems to instant messaging and social media applications.
Workshopは、Border Gateway Protocol（BGP）からDNSのアドレス翻訳者（NAT）へのWeb接続（WebPKI）からDNSセキュリティ（DNSSEC）への認証局（DNSSEC）、およびインターネット（IoT）からの展開症例を調査しました。メッセージングおよびソーシャルメディアアプリケーションへのシステム。
In many cases, (1) there was a surprise in how technology was deployed, (2) there was a lack of sufficient adoption, or (3) the business models associated with chosen technologies were not in favor of broader interoperability.
多くの場合、（1）テクノロジーがどのように展開されたかに驚きがありました。（2）十分な採用の欠如、または（3）選択された技術に関連するビジネスモデルは、より広い相互運用性を支持していませんでした。
In general, the protocol designers cannot affect market forces but must work within them. But there are often competing technical approaches or features that are tailored for a particular deployment pattern. In some cases, it is possible to choose whether to support, for instance, a clear need for an established business, a feature designed to support collaboration among smaller players, or some kind of disruption through a more speculative new feature or technology.
一般に、プロトコル設計者は市場の力に影響を与えることはできませんが、それらの中で働く必要があります。しかし、特定の展開パターンに合わせて調整されている技術的アプローチや機能を競合することが多い。場合によっては、たとえば、確立されたビジネスの明確な必要性、より小さなプレーヤー間のコラボレーションをサポートするように設計された機能、またはより投機的な新機能または技術を介したいくつかの種類の混乱をサポートするかどうかを選択することができます。
Lessons learned include the following:
学んだ教訓は次のものを含みます：
* Feedback from those who deploy often comes too late.
* 展開する人からのフィードバックは遅すぎます。
* Building blocks get repurposed in unexpected ways.
* ビルディングブロックは予期せぬ方法で再利用されます。
* User communities come in too late.
* ユーザーコミュニティが遅すぎる。
* The Web is getting more centralized, and counteracting this trend is difficult. It is not necessarily clear what technical path leads to distributed markets and decentralized architectures, for instance.
* Webはより集中化されており、この傾向を打ち消すことは困難です。たとえば、分散型市場や分散アーキテクチャが発生するのは必ずしも明確には明らかではありません。
* There are also many forces that make it easier to pursue centralized models than other models. For instance, deployment is often easier in a centralized model. And various business and regulatory processes work best within a small, well-defined set of entities that can interact with each other. This can lead to, for instance, regulators preferring a situation with a small number of entities that they can talk to, rather than a diverse set of providers.
* 他のモデルよりも集中型モデルを追求するのが簡単になる力も多い。たとえば、展開はしばしば集中型モデルでは簡単になります。そして、様々なビジネスおよび規制プロセスは、互いに対話することができる小さくて明確に定義されたエンティティのセット内に最もよく機能します。これは、例えば、規制当局が、多様なプロバイダのセットではなく、彼らが話すことができる、多くのエンティティを持つ状況を好む、規制因子につながる可能性があります。
* It is important but hard to determine how useful new protocols are.
* 重要なのですが、有用な新しいプロトコルがどれほど有用なのかを判断するのは難しいです。
* It is difficult for the IETF community to interact with other communities, e.g., specific business sectors that need new technology (such as aviation or healthcare) or regulators.
* IETFコミュニティが他のコミュニティ、例えば、新しい技術（航空や医療など）や規制当局を必要とする特定の事業部門と対話することは困難です。
Several underlying principles can be observed in the example cases that were discussed. Deployment failures tend to be associated with cases where interdependencies make progress difficult and there's no major advantage for early deployment. Despite persistent problems in the currently used technology, it becomes difficult for the ecosystem to switch to better technology. For instance, there are a number of areas where the Internet routing protocol BGP [RFC4271] is lacking, but there has been only limited success in deploying significant improvements -- for instance, in the area of security.
議論された例の例では、いくつかの根本的な原理を観察することができます。展開障害は、相互依存関係が困難であり、早期展開に大きな利点はない場合に関連付けられています。現在使用されている技術では持続的な問題にもかかわらず、生態系がより良い技術に切り替えることは困難になる。たとえば、インターネットルーティングプロトコルBGP [RFC4271]が不足している領域はいくつかありますが、セキュリティの分野では、重要な改善点を展開する際の成功したことが限られています。
Another principle appears to be first-mover advantage. Several equally interesting technologies have fared in very different ways, depending on whether there was an earlier system that provided most of the benefits of the new system. Again, despite potential problems in an already-deployed technology, it becomes difficult to deploy improvements due to a lack of immediate incentives and due to the competing and already-deployed alternative that is proceeding forward in the ecosystem. For instance, WebPKI is very widely deployed and used, but DNSSEC [RFC4033] is not. Is this because of the earlier commercial adoption of WebPKI, the more complex interdependencies between systems that wished to deploy DNSSEC, or some other reason?
もう1つの原則は、最初の排除された利点であるようです。新しいシステムの利点のほとんどの利点を提供する以前のシステムがあるかどうかに応じて、いくつかの同様に興味深い技術が非常に異なる方法でいっぱいです。やはり、すでに展開されているテクノロジの潜在的な問題にもかかわらず、即時のインセンティブが不足しているため、およびエコシステムで進行している競合していてすでに展開されている代替案のために、改善を推進することが困難になります。たとえば、WebPKIは非常に広く展開されて使用されていますが、DNSSEC [RFC4033]はそうではありません。これはWebPKIの早期の商業的採用のため、DNSSECの展開を望んでいるシステム間のより複雑な相互依存性、またはその他の理由は、次のとおりですか？
The definition of "success" in [RFC5218] appears to be part of the problem. The only way to control deployments up front is to prevent wild success, but wild successes are actually what we want. And it seems very difficult to predict these successes.
[RFC5218]の「成功」の定義は問題の一部であるようです。展開を表す唯一の方法は、野生の成功を防ぐことですが、野生の成功は実際に私たちが望むものです。そして、これらの成功を予測するのは非常に難しいようです。
The workshop also discussed the extent to which protocol work even should be controlled by the IETF, or the IESG. It seems unproductive to attempt to constrain deployment models, as one can only offer possibilities but not force anyone to use a particular possibility.
ワークショップはまた、どのプロトコル作業がIETF、またはIESGによって制御されるべきかを議論した。展開モデルを制約しようとすることは、特定の可能性を誰かに使用することができないように、展開モデルを制約しようとするのを試みるようです。
The workshop also discussed different types of deployment patterns on the Internet:
ワークショップはまた、インターネット上のさまざまな種類の展開パターンについて議論しました。
* Delivering functionality over the Internet as a web service. The Internet is an open and standardized system, but the service on top may be closed, essentially running two components of the same service provider's software against each other over the browser and Internet infrastructure. Several large application systems have grown in the Internet in this manner, encompassing large amounts of functionality and a large fraction of Internet users. This makes it easier for web applications to grow by themselves without cross-fertilization or interoperability.
* Webサービスとしてインターネット上の機能を提供する。インターネットはオープンで標準化されたシステムですが、上のサービスは、ブラウザやインターネットインフラストラクチャを介して、同じサービスプロバイダのソフトウェアの2つのコンポーネントを基本的に実行しています。このようにして、いくつかの大規模なアプリケーションシステムがインターネットで成長しており、大量の機能性とインターネットユーザーの大部分を網羅しています。これにより、Webアプリケーションが交差施肥や相互運用性なしにWebアプリケーションが自分で成長するのが簡単になります。
* Delivering concentrated network services that offer the standard capabilities of the Internet. Examples in this category include the provisioning of some mail services, DNS resolution, and so on.
* インターネットの標準機能を提供する集中ネットワークサービスを提供します。例このカテゴリの例には、何らかのメールサービス、DNS解像度などのプロビジョニングが含まれます。
The second case is more interesting for an Internet architecture discussion. There can, however, be different underlying situations even in that case. The service may be simply a concentrated way to provide a commodity service. The market should find a natural equilibrium for such situations. This may be fine, particularly where the service does not provide any new underlying advantage to whoever is providing it (in the form of user data that can be commercialized, for instance, or as training data for an important Machine Learning service).
2番目のケースは、インターネットアーキテクチャの議論にとってより面白いです。ただし、その場合でも異なる状況ではありません。このサービスは、商品サービスを提供するための単純に集中的な方法であるかもしれません。市場はそのような状況にとって自然な平衡を見つけるべきです。これは、特に、特にサービスがそれを提供している人に新しい根本的な利点を提供していない場合があります（例えば、商品化され得るユーザーデータの形で、または重要な機械学習サービスのためのトレーニングデータとして）。
Secondly, the service may be an extension beyond standard protocols, leading to some questions about how well standards and user expectations match. But those questions could be addressed by better or newer standards. Thirdly, and potentially most disturbingly, the service may be provided in this concentrated manner due to business patterns that make it easier for particular entities to deploy such services.
第二に、サービスは標準プロトコルを超えた拡張子であり得、標準とユーザの期待がどのくらいよく一致するかについてのいくつかの質問をもたらします。しかし、それらの質問はより良いまたはより新しい標準によって対処することができます。第三に、そして潜在的に最も邪魔になるように、特定のエンティティがそのようなサービスを展開することをより容易にするビジネスパターンのために、サービスをこの集中的に提供することができる。
The group also discussed monocultures, and their negative effect on the Internet and its stability and resistance to various problems and attacks.
当グループはまた、単診断、およびインターネットへのそれらの悪影響およびその安定性および様々な問題および攻撃に対する耐性について議論した。
Regulation may affect the Internet businesses as well. Regulation can exist in multiple forms, based on economic rationale (e.g., competition law) or other factors. For instance, user privacy is a common regulatory topic.
規制はインターネット事業にも影響を与える可能性があります。規制は、経済的根拠（例えば、競技法）または他の要因に基づいて、複数の形式で存在する可能性があります。たとえば、ユーザーのプライバシーは一般的な規制トピックです。
Many of the participants have struggled with these trends and their effect on desirable characteristics of Internet systems, such as distributed, end-to-end architecture or privacy. Yet, there are many business and technical drivers causing the Internet architecture to become further and further centralized.
参加者の多くは、分散、エンドツーエンドのアーキテクチャやプライバシーなどのインターネットシステムの望ましい特性に及ぼすこれらの傾向とその影響に苦しんでいます。それでも、インターネットアーキテクチャをさらに集中化させるために多くのビジネスおよび技術的なドライバがあります。
Some observations that were made:
されたいくつかの観察
* When standardizing new technology, the parties involved in the effort may think they agree on what the goals are but in reality are often surprised in the end. For instance, with DNS (queries) over HTTPS (DoH) [RFC8484], there were very different aspirations, some around improvements in confidentiality of the queries, some around operational and latency improvements to DNS operations, and some about shifting business and deployment models. The full picture was not clear before the work was completed.
* 新しい技術を標準化するとき、努力に関わる当事者は、彼らが目標が何であるか、現実的には最終的に驚いていることに同意すると考えるかもしれません。たとえば、https（doh）上のDNS（DOH）[RFC8484]では、非常に異なる願望がありました。。完全な写真は作業が完了する前にはっきりしませんでした。
* In DNS, DDoS is a practical reality, and only a handful of providers can handle the traffic load in these attacks.
* DNSでは、DDOSは実用的な現実であり、一握りのプロバイダーだけがこれらの攻撃のトラフィック負荷を処理できます。
The hopeful side of this issue is that there are some potential answers:
この問題の希望の側面は、潜在的な答えがあることです。
* DDoS defenses do not have to come through large entities, as layered defenses and federation also help similarly.
* DDOS防御は、層状の防御や連盟も同様に役立つので、大規模な事業体を経てもらう必要はありません。
* Surveillance state data capture can be fought with data object encryption and by not storing all of the data in one place.
* 監視状態データキャプチャは、データオブジェクト暗号化と協定することができ、すべてのデータを一箇所に保存しないことによって。
* Web tracking can be combatted by browsers choosing to avoid techniques that are sensitive to tracking. Competition in the browser market may help drive some of these changes.
* Webトラッキングは、トラッキングに敏感なテクニックを回避することを選択することによって、ブラウザによってコンタクトすることができます。ブラウザ市場での競争は、これらの変更のいくつかを運転するのに役立ちます。
* Open interfaces help guard against the bundling of services in one large entity; as long as there are open, well-defined interfaces to specific functions, these functions can also be performed by other parties.
* Open Interfacesは、1つの大きなエンティティでサービスのバンドルを防ぐのに役立ちます。特定の機能に開いて明確に定義されたインタフェースがある限り、これらの機能は他の当事者によっても実行されます。
* Commercial surveillance does not seem to be curbed by current means. But there are still possibilities, such as stronger regulation, data minimization, or browsers acting on behalf of users. There are hopeful signs that at least some browsers are becoming more aggressive in this regard. But more is needed.
* 商業監視は現在の手段によって湾曲していないようです。しかし、より強い規制、データの最小化、またはユーザーに代わって行動するブラウザなどの可能性があります。この点に関して少なくともいくつかのブラウザがより積極的になっているという希望の兆候があります。しかし、もっと必要です。
One comment made in the workshop was that the Internet community needs to curb the architectural trend of centralization. Another comment was that discussing this in the abstract is not as useful as more concrete, practical actions. For instance, one might imagine different DoH deployments with widely different implications for privacy or tolerance of failures. Getting to the specifics of how a particular service can be made better is important.
ワークショップで作られた1つのコメントは、インターネットコミュニティが集中化のアーキテクチャの動向を抑える必要があるということでした。もう一つのコメントは、抽象的にこれを議論することはより具体的な実用的な行動と同じくらい有用ではないということでした。たとえば、障害のプライバシーや許容範囲に対する大きな影響を伴うさまざまなDOH展開を想像する可能性があります。特定のサービスをどのように良くするかの詳細に取得することが重要です。
This part of the discussion focused on whether in the current state of the Internet we actually need a new threat model.
この議論のこの部分は、現在のインターネットの状態にあるかどうか、実際に新しい脅威モデルが必要なのかに焦点を当てていました。
Many of the security concerns regarding communications have been addressed in the past few years, with increasing encryption. However, issues with trusting endpoints on the other side of the communication have not been addressed and are becoming more urgent with the advent of centralized service architectures.
暗号化の増大に伴い、通信に関するセキュリティ上の懸念の多くは過去数年間で取り上げられています。しかし、コミュニケーションの反対側に信頼するエンドポイントに関する問題は対処されておらず、集中型サービスアーキテクチャの出現に伴う緊急になりつつあります。
Further effort may be needed to minimize centralization, as having only a few places to tap increases the likelihood of surveillance.
監視の可能性を軽減するための場所を数少するだけの場所を持つので、集中化を最小限に抑えるためにさらなる努力が必要になるかもしれません。
There may be a need to update [RFC3552] and [RFC7258].
[RFC3552]と[RFC7258]を更新する必要があるかもしれません。
The participants in the workshop agreed that a new threat model is needed and that non-communications-security issues need to be handled.
ワークショップの参加者は、新しい脅威モデルが必要であり、非通信 - セキュリティ問題を処理する必要があることに合意しました。
Other security discussions were focused on IoT systems, algorithm agility issues, experiences from difficult security upgrades such as DNSSEC key rollovers, and routing security.
他のセキュリティ上の議論は、IOTシステム、アルゴリズムの俊敏性の問題、DNSSECキーロールオーバーなどの困難なセキュリティアップグレードからの経験、およびルーティングセキュリティを中心にしていました。
The participants cautioned against relying too much on device manufacturers for security, and being clear on security models and assumptions. Security is often poorly understood, and the assumptions about who the system defends against and who it does not are not clear.
参加者は、セキュリティのためにデバイス製造業者であまりにも多くの依存しており、セキュリティモデルや仮定には明らかになっています。セキュリティはよく理解されていませんが、システムが誰に反対しているかについての仮定は明確ではありません。
The workshop turned into a discussion of what actions we can take:
ワークショップは私たちがどの行動をとることができるかについての議論になった：
* Documenting our experiences?
* 私たちの経験を文書化する？
* Providing advice (to the IETF or to others)?
* アドバイスを提供する（IETFまたは他の人に）。
* Waiting for the catastrophe that will make people agree to changes? The participants of course did not wish for this.
* 人々が変化することに同意するような大惨事を待っていますか？参加者はこれを望んでいませんでした。
* Work at the IETF?
* IETFで働いていますか？
* Technical solutions/choices?
* 技術ソリューション/選択肢？
The best way for the IETF to do things is through standards; convincing people through other requests is difficult. The IETF needs to:
IETFが物事をするための最良の方法は標準を通してです。他の要求を通して説得力のある人々は困難です。IETFは以下のものです。
* Pick pieces that it is responsible for.
* それが責任があることを選ぶピック。
* Be reactive for the rest, be available as an expert in other discussions, provide Internet technology knowledge where needed, etc.
* 他の議論の専門家としての休息のために無効にする、必要に応じてインターネット技術の知識を提供します。
One key question is what other parties need to be involved in any discussions. Platform developers (mobile platforms, cloud systems, etc.) are one such group. Specific technology or business groups (such as email provider or certificate authority forums) are another.
1つの重要な質問は、他の締約国がどの議論に関わる必要があるかということです。プラットフォーム開発者（モバイルプラットフォーム、クラウドシステムなど）はそのようなグループの1つです。特定の技術またはビジネスグループ（電子メールプロバイダまたは認証局のフォーラムなど）は別のものです。
The workshop also discussed specific technology issues -- for instance, around IoT systems. One observation in those systems is that there is no single model for applications; they vary. There are a lot of different constraints in different systems and different control points. What is perhaps most needed today is user control and transparency (for instance, via Manufacturer Usage Descriptions (MUDs) [RFC8520]). Another issue is management, particularly for devices that could be operational for decades. Given the diversity of IoT systems, it may also make more sense to build support systems for broader solutions than for specific solutions or specific protocols.
ワークショップはまた、特定の技術の問題を論じた - 例えば、IOTシステムの周囲。これらのシステムでの1つの観察は、アプリケーションに単一のモデルがないことです。彼らは異なります。さまざまなシステムと異なるコントロールポイントには、多くの異なる制約があります。今日最も必要とされるおそらく、ユーザーの管理と透明性（例えば、製造業者使用状況説明（MUDS）[RFC8520]）です。もう1つの問題は、特に数十年間運用可能な装置の管理です。IOTシステムの多様性を考えると、特定のソリューションまたは特定のプロトコルよりも、より広いソリューションのためのサポートシステムを構築することをより理にかなっています。
There are also many security issues. While some of them are trivial (such as default passwords), one should also look forward and be prepared to have solutions for, say, trust management for long time scales, or be able to provide data minimization to cut down on the potential for leakages. And the difficulty of establishing peer-to-peer security strengthens the need for a central point, which may also be harmful from a long-term privacy perspective.
多くのセキュリティ問題もあります。それらのうちのいくつかは（デフォルトのパスワードなど）を楽しみにしており、言うまでもなく、長時間のスケールのための解決策を持つようにするか、または漏れの可能性を減らすためにデータの最小化を提供できるようにする必要があります。。また、ピアツーピアセキュリティを確立することの難しさは、長期的なプライバシーの観点から有害である可能性がある中心点の必要性を強化します。
The workshop met in the sunny Finnish countryside and made the unsurprising observation that technologies sometimes get deployed in surprising ways. But the consequences of deployment choices can have an impact on security, privacy, centralized vs. distributed models, competition, and surveillance. As the IETF community cares deeply about these aspects, it is worthwhile to spend time on the analysis of these choices.
ワークショップは日当たりの良いフィンランドの田園地帯で会い、技術が時々驚くべき方法で展開されることがあるというわかりやすい観察をしました。しかし、展開の選択の影響は、セキュリティ、プライバシー、集中化されたVS.分散モデル、競争、および監視に影響を与える可能性があります。IETFコミュニティはこれらの側面について深く気づいているので、これらの選択肢の分析に時間を過ごすのは価値があります。
The prime factor driving deployments is perceived needs; expecting people to recognize obvious virtues and therefore deploy them is not likely to work.
Prime Factor Driving展開は、ニーズに知覚されます。人々が明らかな美徳を認識し、したがってそれらを展開することを期待することは働く可能性は低いです。
And the ecosystem is complex, including, for instance, many parties: different business roles, users, regulators, and so on, and perceptions of needs and the ability to act depend highly on what party one talks to.
そして、生態系は、例えば多くの締約国、ユーザ、規制当局などを含む複雑なものであり、必要なニーズや行動の認識、および行動する能力は、どの党者が話すかについて非常に高く依存しています。
While the workshop discussed actions and advice, there is a critical question of who these are targeted towards. There is a need to construct a map of what parties need to perform what actions.
ワークショップで行動やアドバイスについて話し合っている間、これらが対象となっている人の重要な問題があります。どのような行動を実行する必要があるかの地図を構築する必要があります。
The workshop also made some technical observations. One issue is that the workshop identified a set of hard issues that affect deployment and for which we have no good solutions. These issues include, for instance, dealing with DDoS attacks and how to handle spam. Similarly, a lack of good solutions for micropayments is one factor behind a lot of the Internet economy being based on advertisements.
ワークショップはまたいくつかの技術的観察をしました。1つの問題は、ワークショップが展開に影響を与える一連の努力と優れた解決策がないということです。これらの問題には、例えば、DDOS攻撃やスパムの処理方法を扱うことが含まれます。同様に、マイクロペイメントのための優れた解決策の欠如は、広告に基づいている多くのインターネット経済経済の背後にある1つの要因です。
One recent trend is that technology is moving up the stack, e.g., in the areas of services, transport protocol functionality, security, naming, and so on. This impacts how easy or hard changes are and who is able to perform them.
最近の傾向の1つは、技術、例えば、サービスの分野、トランスポートプロトコル機能、セキュリティ、命名などである。これはどのように簡単かつ難しい変更がどれほど簡単か、誰が実行できるかに影響します。
It was also noted that interoperability continues to be important, and we need to explore what new interfaces need standardization -- this will enable different deployment models and competition. The prime factor driving deployments is actual needs; we cannot force anything on others but can provide solutions for those that need them. Needs and actions may fall to different parties.
相互運用性が重要であることが注目されており、新しいインタフェースが標準化が必要なのかを探る必要があることに注意しました - これはさまざまな展開モデルと競争を可能にします。Prime Factor Driving展開は実際のニーズです。私たちは他の人に何も強制することはできませんが、それらを必要とする人々のための解決策を提供することができます。必要性と行動は異なる当事者に落ちるかもしれません。
The workshop also considered the balancing of user non-involvement and transparency, as well as choice, relevant threats such as communicating with malicious endpoints, the role and willingness of browsers in increasing the ability to defend users' privacy, and concerns around centralized control or data storage points.
ワークショップはまた、ユーザーの非関与と透明性のバランス、そして選択、悪意のあるエンドポイントとのコミュニケーションなどの関連する脅威、ユーザーのプライバシーを守る能力を高め、集中管理または集中管理の懸念を高めるなどの関連性のある脅威と見なしました。データ格納ポイント
The workshop also discussed specific issues around routing, DoS attacks, IoT systems, the role of device manufacturers, the DNS, and regulatory reactions and their possible consequences.
このワークショップはまた、ルーティング、DOS攻撃、IOTシステム、デバイス製造業者の役割、DNS、および規制反応、およびその可能性のある影響に関する特定の問題についても議論した。
The prime conclusion from the workshop was that the topics we discussed were not completed in the workshop. Much more work is needed. The best way for the IETF to make an impact is through standards. The IETF should focus on the parts that it is responsible for and be available as an expert on other discussions.
ワークショップからの主な結論は、我々が議論したトピックがワークショップで完了していないということでした。もっと仕事が必要です。IETFが影響を与えるための最良の方法は、標準を通じています。IETFは、それが責任がある部分に焦点を合わせるべきであり、他の議論の専門家として利用可能になるべきです。
The documents/outputs and actions described in the following items were deemed relevant by the participants.
以下の項目に記載されている文書/出力および操作は、参加者によって関連性があると見なされました。
* Develop and document a modern threat model.
* 現代の脅威モデルを開発して文書化する。
* Continue discussion of consolidation/centralization issues.
* 統合/集中化の問題についての議論を続ける。
* Document architectural principles, e.g., (re)application of the end-to-end principle.
* エンドツーエンドの原理のアーキテクチャの原理、例えば（re）アプリケーション。
The first receiver of these thoughts is the IETF and protocol community, but combined with some evangelizing and validation elsewhere.
これらの考えの最初の受信者は、IETFおよびプロトコルコミュニティですが、他の場所での伝道と検証と組み合わされています。
* Pursuit of specific IETF topics, e.g., working on taking into account reputation systems in IETF work, working to ensure that certificate scoping can be appropriately limited, building end-to-end encryption tools for applications, etc.
* 特別なIETFトピックの追求、例えば、IETFの作業で評判システムを考慮して、証明書のスコープが適切に限られていることを確認するために、アプリケーションのためのエンドツーエンドの暗号化ツールを構築することを確実にするために働きます。
* General deployment experiences/advice, and documenting deployment assumptions possibly already in WG charters.
* 一般的な展開の経験/アドバイス、および展開の仮定の文書化は、すでにWG Chartersにすでにあります。
* A report will be produced from the workshop (this RFC).
* レポートはワークショップ（このRFC）から作成されます。
The workshop results have also been reported at [ISPColumn] by Geoff Huston.
ワークショップの結果は、Geoff Hustonによって[ISPColumn]で報告されています。
Feedback regarding the workshop is appreciated and can be sent to the program committee, the IAB, or the architecture-discuss list.
ワークショップに関するフィードバックは高く評価されており、プログラム委員会、IAB、またはアーキテクチャ講演リストに送ることができます。
Proposals discussed at the workshop would have significantly different security impacts, and each workshop paper should be read for its own security considerations.
ワークショップで議論された提案は、大幅に異なるセキュリティの影響を及ぼし、各ワークショップ紙は独自のセキュリティ上の考慮事項について読み取られるべきです。
[Arkko2019] Arkko, J., "Changes in the Internet Threat Model", position paper submitted for the IAB DEDR workshop, June 2019.
[ARKKO2019] Arkko、J.、「インターネット脅威モデルの変化」、IAB Dedrワークショップ、2019年6月に提出された位置紙。
[Bertola2019] Bertola, V., "How the Internet Was Won and Where It Got Us", position paper submitted for the IAB DEDR workshop, June 2019.
[Bertola2019] Bertola、V.、「インターネットが勝ったのか、そしてそれがどこに得られたのか」、2019年6月、IAB Dedrワークショップに提出されたポジションペーパー。
[Bormann2019] Bormann, C. and J. Rieckers, "WiFi authentication: Some deployment observations from eduroam", position paper submitted for the IAB DEDR workshop, June 2019.
[BormAnn2019] Bormann、C、J.Rieckers、「WiFi認証：エドロアムからの展開観測」、IAB Dedrワークショップ、2019年6月に提出されたポジションペーパー。
[Bortzmeyer2019] Bortzmeyer, S., "Encouraging better deployments", position paper submitted for the IAB DEDR workshop, June 2019.
[Bortzmeyer2019] Bortzmeyer、S。、2019年6月、IAB Dedrワークショップに提出されたポジションペーパー。
[Carpenter2019] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", position paper submitted for the IAB DEDR workshop, June 2019.
[Carpenter2019] Carpenter、B.およびB. LIU、「限定ドメインとインターネットプロトコル」、2019年6月、IAB Dedrワークショップに提出された位置紙。
[CFP] IAB, "Design Expectations vs. Deployment Reality in Protocol Development Workshop 2019", June 2019, <https://www.iab.org/activities/workshops/dedr-workshop/>.
[CFP] IAB、「プロトコル開発ワークショップ2019の設計期待対展開現実」、2019年6月、<https：//www.iab.org/activities/workshops/dedr-workshop/>。
[Cooper2019] Cooper, A., "Don't Forget the Access Network", position paper submitted for the IAB DEDR workshop, June 2019.
[Cooper2019] Cooper、A。、「アクセスネットワークを忘れないでください」、IAB Dedrワークショップ、2019年6月に提出されたポジションペーパー。
[Farrell2019] Farrell, S., "We're gonna need a bigger threat model", position paper submitted for the IAB DEDR workshop, June 2019.
[Farrell2019] Farrell、S.、「私たちはより大きな脅威モデルを必要とする」、2019年6月、IAB Dedrワークショップに提出されたポジションペーパー。
[HallamBaker2019] Hallam-Baker, P., "The Devil is in the Deployment", position paper submitted for the IAB DEDR workshop, June 2019.
[Hallambaker2019]ハラムベイカー、P。、「悪魔は展開にあります」、2019年6月、IAB Dedrワークショップに提出された位置紙。
[Hardie2019] Hardie, T., "Instant Messaging and Presence: A Cautionary Tale", position paper submitted for the IAB DEDR workshop, June 2019.
[Hardie2019] hardie、T.、「インスタントメッセージングとプレゼンス：注意の物語」、IAB Dedrワークショップ、2019年6月に提出されたポジションペーパー。
[Hoffman2019] Hoffman, P., "Realities in DNSSEC Deployment", position paper submitted for the IAB DEDR workshop, June 2019.
[HOFFMAN2019] HOFFMAN、P。、「DNSSEC展開の現実」、2019年6月、IAB DEDRワークショップに提出された位置紙。
[Huitema2019] Huitema, C., "Concentration is a business model", position paper submitted for the IAB DEDR workshop, June 2019.
[HUITEMA2019] Huitema、C、「集中はビジネスモデル」、2019年6月のIAB DEDRワークショップに提出されたポジションペーパー。
[Huston2019] Huston, G., "The Border Gateway Protocol, 25 years on", position paper submitted for the IAB DEDR workshop, June 2019.
[Huston2019] Huston、G.、「25年のボーダーゲートウェイプロトコル」、2019年6月、IAB DEDRワークショップに提出されたポジションペーパー。
[ISPColumn] Huston, G., "Network Protocols and their Use", June 2019, <https://www.potaroo.net/ispcol/2019-06/dedr.html>.
[ISPCOLUMN] Huston、G.、「ネットワークプロトコルとその使用」、2019年6月、<https：//www.potaroo.net/ispcol/2019-06/dedr.html>。
[Kutscher2019] Kutscher, D., "Great Expectations: Protocol Design and Socioeconomic Realities", position paper submitted for the IAB DEDR workshop, June 2019.
[Kutscher2019] Kutscher、D.、「素晴らしい期待：プロトコルデザインと社会経済的現実」、2019年6月のIAB DEDRワークショップに提出されたポジションペーパー。
[Maisonneuve2019] Maisonneuve, J., "DNS, side effects and concentration", position paper submitted for the IAB DEDR workshop, June 2019.
[Maisonneuve2019] Maisonneuve、J.、「DNS、副作用と集中」、IAB Dedrワークショップ、2019年6月に提出された位置紙。
[Mattsson2019] Mattsson, J., "Consolidation, Privacy, Jurisdiction, and the Health of the Internet", position paper submitted for the IAB DEDR workshop, June 2019.
[Mattsson 2019]マットソン、J。、「連結、プライバシー、管轄区域、およびインターネットの健康」、2019年6月、IAB DEDRワークショップに提出されたポジションペーパー。
[Muller2019] Müller, M., "Rolling Forward: An Outlook on Future Root Rollovers", position paper submitted for the IAB DEDR workshop, June 2019.
[MULLER2019]Müller、M。、「将来の転がり：将来のルートロールオーバーに関する見通し」、IAB Dedrワークショップに提出された位置紙。
[Ott2019] Ott, J., "Protocol Design Assumptions and PEPs", position paper submitted for the IAB DEDR workshop, June 2019.
[OTT2019] OTT、J。、「プロトコル設計前提とPEP」、IAB Dedrワークショップ、2019年6月に提出された位置紙。
[Pardue2019] Pardue, L., "Some challenges with IP multicast deployment", position paper submitted for the IAB DEDR workshop, June 2019.
[Pardue2019] Pardue、L. IPマルチキャスト展開によるいくつかの挑戦、2019年6月、IAB DEDRワークショップに提出されたポジションペーパー。
[POS] IAB, "Position Papers: DEDR Workshop", June 2019, <https://www.iab.org/activities/workshops/dedr-workshop/ position-papers/>.
[POS] IAB、「ポジションペーパー：DEDRワークショップ」、2019年6月、<https：//www.iab.org/activities/workshops/dedr-workshop/ポジションペーパー/>。
[Reid2019] Reid, J., "Where/Why has DNS gone wrong?", position paper submitted for the IAB DEDR workshop, June 2019.
[REID2019] REID、J.、「どこで/なぜDNSが間違っていましたか」、2019年6月、IAB Dedrワークショップに提出されたポジションペーパー。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC3552] Rescorla、E.およびB.Korver、「セキュリティ上のRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、DOI 10.17487 / RFC3552、2003年7月、<https：//www.rfc-editor.org/情報/ RFC3552>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、 "DNSセキュリティ紹介および要件"、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<https：//www.rfc-editor.org/info/rfc4033>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271]、y、ed。、Li、T.、Ed。、S. Hares、Ed。、「ボーダーゲートウェイプロトコル4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月<https://www.rfc-editor.org/info/rfc4271>。
[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, <https://www.rfc-editor.org/info/rfc5218>.
[RFC5218] Thaler、D.およびB. Aboba、「正常なプロトコルのために何が成功させるのか」、RFC 5218、DOI 10.17487 / RFC5218、2008年7月、<https://www.rfc-editor.org/info/rfc5218>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S.およびH.Tschofenig、「Pervasive Monitoringは攻撃」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<https：//www.rfc-editor.org/info/rfc7258>。
[RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, May 2017, <https://www.rfc-editor.org/info/rfc8170>.
[RFC8170] Thaler、D.、ED。、「プロトコル採用とその後の移行の計画」、RFC 8170、DOI 10.17487 / RFC8170、<https：//www.rfc-editor.org/info/rfc8170>。
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.
[RFC8484] HOFFMAN、P.およびP.Mcmanus、「HTTPS経由のDNSクエリ（DOH）」、RFC 8484、DOI 10.17487 / RFC8484、2018年10月、<https：//www.rfc-editor.org/info/rfc8484>。
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage Description Specification", RFC 8520, DOI 10.17487/RFC8520, March 2019, <https://www.rfc-editor.org/info/rfc8520>.
[RFC8520] Lear、E.、Droms、R。、RFC 8520、DOI 10.17487 / RFC8520、2019年3月、<https://www.rfc-editor.org/info/ RFC8520>。
[Sethi2019] Sethi, M. and T. Aura, "IoT Security and the role of Manufacturers: A Story of Unrealistic Design Expectations", position paper submitted for the IAB DEDR workshop, June 2019.
[SETHI2019] Sethi、M.およびT.オーラ、「IOTセキュリティおよび製造業者の役割：非現実的な設計期待の物語」、2019年6月のIAB Dedrワークショップに提出されたポジションペーパー。
[Sullivan2019] Sullivan, A., "Three kinds of concentration in open protocols", position paper submitted for the IAB DEDR workshop, June 2019.
[Sullivan2019] Sullivan、A。、「オープンプロトコルの3種類の濃度」、2019年6月、IAB DEDRワークショップに提出された位置紙。
The following is a list of participants on site and over a remote connection:
以下は、サイト上の参加者のリスト、およびリモート接続を介したものです。
* Arkko, Jari
* arkko、jari.
* Aura, Tuomas
* オーラ、タマ
* Bertola, Vittorio
* ベルトーラ、Vittorio
* Bormann, Carsten
* Bormann、Carsten
* Bortzmeyer, Stéphane
* Bortzmeyer、Stéphane.
* Cooper, Alissa
* クーパー、アリッサ
* Farrell, Stephen
* ファレル、スティーブン
* Flinck, Hannu
* フランキ、阪
* Gahnberg, Carl
* カールのガーンベルク
* Hallam-Baker, Phillip
* ハラムベイカー、フィリップ
* Hardie, Ted
* 丈夫な、テッド
* Hoffman, Paul
* ホフマン、ポール
* Huitema, Christian (remote)
* Huitema、クリスチャン（リモート）
* Huston, Geoff
* ハストン、ジオフ
* Komaitis, Konstantinos
* コマ膜炎、Konstantinos
* Kühlewind, Mirja
* ミルハ州Kühlewind
* Kutscher, Dirk
* クッツチャー、汚れ
* Li, Zhenbin
* Zhenbin.Li、Zhenbin
* Maisonneuve, Julien
* ジュリアンのMaisonneuve
* Mattsson, John
* マッツソン、ジョン
* Müller, Moritz
* ミュラー、モリッツ
* Ott, Jörg
* jörg
* Pardue, Lucas
* ポルデュー、ルーカス
* Reid, Jim
* リード、ジム
* Rieckers, Jan-Frederik
* Rieckers、Jan-Frederik
* Sethi, Mohit
* Sethi、Mohit
* Shore, Melinda (remote)
* ショア、メリンダ（リモート）
* Soininen, Jonne
* ソインネン、ジョンヌ
* Sullivan, Andrew
* サリバン、アンドリュー
* Trammell, Brian
* Trammell、Brian
IAB Members at the Time of Approval
承認時のIABメンバー
Internet Architecture Board members at the time this document was approved for publication were:
インターネットアーキテクチャボードメンバーこの文書が公開のために承認された時点では：
Jari Arkko Alissa Cooper Stephen Farrell Wes Hardaker Ted Hardie Christian Huitema Zhenbin Li Erik Nordmark Mark Nottingham Melinda Shore Jeff Tantsura Martin Thomson Brian Trammell
Jari Arkko Alissa Cooper Stephen Farrell Wes Hardaker Ted Hardie Christian Huitema Zhenbin Li Erik NordmarkマークノッティンガムMelinda Shore Jeff Tantura Martin Thomson Brian Trammell
Acknowledgements
謝辞
The authors would like to thank the workshop participants, the members of the IAB, and the participants in the architecture discussion list for interesting discussions. The notes from Jim Reid were instrumental in writing this report. The workshop organizers would also like to thank Nokia for hosting the workshop in excellent facilities in Kirkkonummi, Finland.
著者らは、Workshopの参加者、IABのメンバー、および興味深い議論のためのアーキテクチャディスカッションリストの参加者に感謝します。Jim Reidからのメモはこのレポートを書くのに役立ちました。ワークショップの主催者はまた、フィンランドのKirkkonummiの優れた施設でワークショップをホスティングするためにノキアに感謝します。
Authors' Addresses
著者の住所
Jari Arkko Ericsson
Jari Arkko Ericsson.
Email: jari.arkko@piuha.net
Ted Hardie
テッドーディーリー
Email: ted.ietf@gmail.com