doc: Add RFC documents

1 files changed, 881 insertions, 0 deletions

diff --git a/doc/rfc/rfc8980.txt b/doc/rfc/rfc8980.txt
new file mode 100644
index 0000000..5f4a9b6
--- /dev/null
+++ b/doc/rfc/rfc8980.txt
@@ -0,0 +1,881 @@
+
+
+
+
+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
+
+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.
+
+   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.
+
+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.
+
+   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.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+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
+
+1.  Introduction
+
+   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).
+
+   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.
+
+   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.
+
+   *  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.
+
+   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.
+
+   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.
+
+2.  Workshop Agenda
+
+   After opening and discussion of goals for the workshop, the
+   discussion focused on five main topics:
+
+   *  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?
+
+3.  Position Papers
+
+   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]
+
+   *  Vittorio Bertola.  "How the Internet Was Won and Where It Got Us"
+      [Bertola2019]
+
+   *  Carsten Bormann and Jan-Frederik Rieckers.  "WiFi authentication:
+      Some deployment observations from eduroam" [Bormann2019]
+
+   *  Stéphane Bortzmeyer.  "Encouraging better deployments"
+      [Bortzmeyer2019]
+
+   *  Brian Carpenter and Bing Liu.  "Limited Domains and Internet
+      Protocols" [Carpenter2019]
+
+   *  Alissa Cooper.  "Don't Forget the Access Network" [Cooper2019]
+
+   *  Stephen Farrell.  "We're gonna need a bigger threat model"
+      [Farrell2019]
+
+   *  Phillip Hallam-Baker.  "The Devil is in the Deployment"
+      [HallamBaker2019]
+
+   *  Ted Hardie.  "Instant Messaging and Presence: A Cautionary Tale"
+      [Hardie2019]
+
+   *  Paul Hoffman.  "Realities in DNSSEC Deployment" [Hoffman2019]
+
+   *  Christian Huitema.  "Concentration is a business model"
+      [Huitema2019]
+
+   *  Geoff Huston.  "The Border Gateway Protocol, 25 years on"
+      [Huston2019]
+
+   *  Dirk Kutscher.  "Great Expectations: Protocol Design and
+      Socioeconomic Realities" [Kutscher2019]
+
+   *  Julien Maisonneuve.  "DNS, side effects and concentration"
+      [Maisonneuve2019]
+
+   *  John Mattsson.  "Consolidation, Privacy, Jurisdiction, and the
+      Health of the Internet" [Mattsson2019]
+
+   *  Moritz Müller.  "Rolling Forward: An Outlook on Future Root
+      Rollovers" [Muller2019]
+
+   *  Jörg Ott.  "Protocol Design Assumptions and PEPs" [Ott2019]
+
+   *  Lucas Pardue.  "Some challenges with IP multicast deployment"
+      [Pardue2019]
+
+   *  Jim Reid.  "Where/Why has DNS gone wrong?"  [Reid2019]
+
+   *  Mohit Sethi and Tuomas Aura.  "IoT Security and the role of
+      Manufacturers: A Story of Unrealistic Design Expectations"
+      [Sethi2019]
+
+   *  Andrew Sullivan.  "Three kinds of concentration in open protocols"
+      [Sullivan2019]
+
+   These papers are available from the IAB website [CFP] [POS].
+
+4.  Discussions
+
+4.1.  Past Experiences
+
+   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.
+
+   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.
+
+   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.
+
+   *  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.
+
+4.2.  Principles
+
+   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.
+
+   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?
+
+   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.
+
+   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.
+
+   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.
+
+   *  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.
+
+   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).
+
+   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.
+
+4.3.  Centralized Deployment Models
+
+   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.
+
+   *  In DNS, DDoS is a practical reality, and only a handful of
+      providers can handle the traffic load in these attacks.
+
+   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.
+
+   *  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.
+
+   *  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.
+
+   *  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.
+
+4.4.  Security
+
+   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].
+
+   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.
+
+   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.
+
+4.5.  Future
+
+   The workshop turned into a discussion of what actions we can take:
+
+   *  Documenting our experiences?
+
+   *  Providing advice (to the IETF or to others)?
+
+   *  Waiting for the catastrophe that will make people agree to
+      changes?  The participants of course did not wish for this.
+
+   *  Work at the 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:
+
+   *  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.
+
+   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.
+
+   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.
+
+5.  Conclusions
+
+5.1.  Summary of Discussions
+
+   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.
+
+   The prime factor driving deployments is perceived needs; expecting
+   people to recognize obvious virtues and therefore deploy them is not
+   likely to work.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+5.2.  Actions
+
+   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.
+
+5.2.1.  Potential Architecture Actions and Outputs
+
+   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.
+
+   The first receiver of these thoughts is the IETF and protocol
+   community, but combined with some evangelizing and validation
+   elsewhere.
+
+5.2.2.  Other Potential Actions
+
+   *  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.
+
+   *  General deployment experiences/advice, and documenting deployment
+      assumptions possibly already in WG charters.
+
+   *  A report will be produced from the workshop (this RFC).
+
+5.3.  Other Publications
+
+   The workshop results have also been reported at [ISPColumn] by Geoff
+   Huston.
+
+5.4.  Feedback
+
+   Feedback regarding the workshop is appreciated and can be sent to the
+   program committee, the IAB, or the architecture-discuss list.
+
+6.  Security Considerations
+
+   Proposals discussed at the workshop would have significantly
+   different security impacts, and each workshop paper should be read
+   for its own security considerations.
+
+7.  Informative References
+
+   [Arkko2019]
+              Arkko, J., "Changes in the Internet Threat Model",
+              position paper submitted for the IAB DEDR workshop, June
+              2019.
+
+   [Bertola2019]
+              Bertola, V., "How the Internet Was Won and Where It Got
+              Us", position paper submitted for the IAB DEDR workshop,
+              June 2019.
+
+   [Bormann2019]
+              Bormann, C. and J. Rieckers, "WiFi authentication: Some
+              deployment observations from eduroam", position paper
+              submitted for the IAB DEDR workshop, June 2019.
+
+   [Bortzmeyer2019]
+              Bortzmeyer, S., "Encouraging better deployments", position
+              paper submitted for the IAB DEDR workshop, June 2019.
+
+   [Carpenter2019]
+              Carpenter, B. and B. Liu, "Limited Domains and Internet
+              Protocols", position paper submitted for the IAB DEDR
+              workshop, June 2019.
+
+   [CFP]      IAB, "Design Expectations vs. Deployment Reality in
+              Protocol Development Workshop 2019", June 2019,
+              <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.
+
+   [Farrell2019]
+              Farrell, S., "We're gonna need a bigger threat model",
+              position paper submitted for the IAB DEDR workshop, June
+              2019.
+
+   [HallamBaker2019]
+              Hallam-Baker, P., "The Devil is in the Deployment",
+              position paper submitted for the IAB DEDR workshop, June
+              2019.
+
+   [Hardie2019]
+              Hardie, T., "Instant Messaging and Presence: A Cautionary
+              Tale", position paper submitted for the IAB DEDR workshop,
+              June 2019.
+
+   [Hoffman2019]
+              Hoffman, P., "Realities in DNSSEC Deployment", position
+              paper submitted for the IAB DEDR workshop, June 2019.
+
+   [Huitema2019]
+              Huitema, C., "Concentration is a business model", position
+              paper submitted for the IAB DEDR workshop, June 2019.
+
+   [Huston2019]
+              Huston, G., "The Border Gateway Protocol, 25 years on",
+              position paper submitted for the IAB DEDR workshop, June
+              2019.
+
+   [ISPColumn]
+              Huston, G., "Network Protocols and their Use", June 2019,
+              <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.
+
+   [Maisonneuve2019]
+              Maisonneuve, J., "DNS, side effects and concentration",
+              position paper submitted for the IAB DEDR workshop, June
+              2019.
+
+   [Mattsson2019]
+              Mattsson, J., "Consolidation, Privacy, Jurisdiction, and
+              the Health of the Internet", position paper submitted for
+              the IAB DEDR workshop, June 2019.
+
+   [Muller2019]
+              Müller, M., "Rolling Forward: An Outlook on Future Root
+              Rollovers", position paper submitted for the IAB DEDR
+              workshop, June 2019.
+
+   [Ott2019]  Ott, J., "Protocol Design Assumptions and PEPs", position
+              paper submitted for the IAB DEDR workshop, June 2019.
+
+   [Pardue2019]
+              Pardue, L., "Some challenges with IP multicast
+              deployment", position paper submitted for the IAB DEDR
+              workshop, June 2019.
+
+   [POS]      IAB, "Position Papers: DEDR Workshop", June 2019,
+              <https://www.iab.org/activities/workshops/dedr-workshop/
+              position-papers/>.
+
+   [Reid2019] Reid, J., "Where/Why has DNS gone wrong?", position paper
+              submitted for the IAB DEDR workshop, June 2019.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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.
+
+   [Sullivan2019]
+              Sullivan, A., "Three kinds of concentration in open
+              protocols", position paper submitted for the IAB DEDR
+              workshop, June 2019.
+
+Appendix A.  Participant List
+
+   The following is a list of participants on site and over a remote
+   connection:
+
+   *  Arkko, Jari
+
+   *  Aura, Tuomas
+
+   *  Bertola, Vittorio
+
+   *  Bormann, Carsten
+
+   *  Bortzmeyer, Stéphane
+
+   *  Cooper, Alissa
+
+   *  Farrell, Stephen
+
+   *  Flinck, Hannu
+
+   *  Gahnberg, Carl
+
+   *  Hallam-Baker, Phillip
+
+   *  Hardie, Ted
+
+   *  Hoffman, Paul
+
+   *  Huitema, Christian (remote)
+
+   *  Huston, Geoff
+
+   *  Komaitis, Konstantinos
+
+   *  Kühlewind, Mirja
+
+   *  Kutscher, Dirk
+
+   *  Li, Zhenbin
+
+   *  Maisonneuve, Julien
+
+   *  Mattsson, John
+
+   *  Müller, Moritz
+
+   *  Ott, Jörg
+
+   *  Pardue, Lucas
+
+   *  Reid, Jim
+
+   *  Rieckers, Jan-Frederik
+
+   *  Sethi, Mohit
+
+   *  Shore, Melinda (remote)
+
+   *  Soininen, Jonne
+
+   *  Sullivan, Andrew
+
+   *  Trammell, Brian
+
+IAB Members at the Time of Approval
+
+   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
+
+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.
+
+Authors' Addresses
+
+   Jari Arkko
+   Ericsson
+
+   Email: jari.arkko@piuha.net
+
+
+   Ted Hardie
+
+   Email: ted.ietf@gmail.com