rfc8980xml2.original.xml   rfc8980.xml 
<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.15 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-iab-dedr-report-01" number="8980" category="info" obsoletes="" updates="" submi
ssionType="IAB" consensus="true" xml:lang="en" tocInclude="true" sortRefs="true"
symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.5.0 -->
<front>
<title abbrev="DEDR Report">Report from the IAB Workshop on Design Expectati
ons vs. Deployment Reality in Protocol Development</title>
<seriesInfo name="RFC" value="8980"/>
<author initials="J." surname="Arkko" fullname="Jari Arkko">
<organization showOnFrontPage="false">Ericsson</organization>
<address>
<email>jari.arkko@piuha.net</email>
</address>
</author>
<author initials="T." surname="Hardie" fullname="Ted Hardie">
<organization/>
<address>
<email>ted.ietf@gmail.com</email>
</address>
</author>
<date year="2021" month="February"/>
<abstract>
<t>The Design Expectations vs. Deployment Reality in Protocol Development
Workshop was convened by the Internet Architecture Board (IAB) in June 2019. Thi
s report summarizes the workshop's significant points of discussion and identifi
es topics that may warrant further consideration.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>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).</t>
<t>The Design Expectations vs. Deployment Reality in Protocol Development
Workshop was convened by the IAB in June 2019. This report summarizes the works
hop's significant points of discussion and identifies topics that may warrant fu
rther consideration.</t>
<t>The background for the workshop was that during the development and ear
ly elaboration phase for a number of protocols, there was a presumption of speci
fic deployment models. Actual deployments have, however, often run contrary to t
hese early expectations when economies of scale, Distributed Denial-of-Service (
DDoS) attack resilience, market consolidation, or other factors have come into p
lay. These factors can result in the deployed reality being highly concentrated.
</t>
<t>This is a serious issue for the Internet, as concentrated, centralized
deployment models present risks to user choice, privacy, and future protocol evo
lution.</t>
<t>On occasion, the differences from the original expectations were almost
immediate, but they also occur after significant time has passed since the prot
ocol's initial development.
</t>
<t>Some examples are given below.</t>
<ul spacing="normal">
<li>Email standards, which presumed many providers running in a largely uncoordi
nated fashion but have seen both significant market consolidation and a need for
coordination to defend against spam and other attacks. The coordination and cen
tralized defense mechanisms scale better for large entities; these have fueled a
dditional consolidation.</li>
<li>The Domain Name System (DNS), which presumed deep hierarchies but has
often been deployed in large, flat zones, leading to the nameservers for those z
ones becoming critical infrastructure. Future developments in DNS may see concen
tration through the use of globally available common resolver services, which ev
olve rapidly and can offer better security. Paradoxically, concentration of thes
e queries into a few services creates new security and privacy concerns.</li>
<li>The Web, which is built on a fundamentally decentralized design but is
now often delivered with the aid of Content Delivery Networks (CDNs). Their ser
vices provide scaling, distribution, and prevention of denial of service in ways
that new entrants and smaller systems operators would find difficult to replica
te. While truly small services and truly large services may each operate using o
nly their own infrastructure, many others are left with the only practical choic
e being the use of a globally available commercial service.</li>
</ul>
<t>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 man
y different providers.</t>
<t>In <xref target="RFC5218" format="default"/>, the IAB tackled what made
for a successful protocol. In <xref target="RFC8170" format="default"/>, the IA
B 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 w
rong, looking for patterns in what caused those assumptions to fail (e.g., conce
ntration due to DDoS resilience) and in how those failures impact the security,
privacy, and manageability of the resulting deployments.
</t>
<t>While the eventual goals might include proposing common remediations fo
r specific cases of confounded protocol expectations, this workshop and thus thi
s report focused on identifying patterns.
</t>
<t>The workshop call for papers invited the submission of position papers
that would:</t>
<ul spacing="normal">
<li>Describe specific cases where systems assumptions during protocol de
velopment were confounded by later deployment conditions.</li>
<li>Survey a set of cases to identify common factors in these confounded
expectations.</li>
<li>Explore remediations that foster user privacy, security, and provide
r diversity in the face of these changes.</li>
</ul>
<t>A total of 21 position papers were received and are listed in <xref tar
get="positionpapers" format="default"/>. On site or remote were 30 participants;
they are listed in <xref target="participants" format="default"/>.</t>
</section>
<section anchor="workshop-agenda" numbered="true" toc="default">
<name>Workshop Agenda</name>
<t>After opening and discussion of goals for the workshop, the discussion
focused on five main topics:</t>
<ul spacing="normal">
<li>Past experiences. What have we learned?</li>
<li>Principles. What forces apply to deployment? What principles to take
into account in design?</li>
<li>Centralized deployment models. The good and the bad of centralizatio
n. Can centralization be avoided? How?</li>
<li>Security. Are we addressing the right threats? What should we prepar
e ourselves for?</li>
<li>Future. What can we do? Should we get better at predicting, or shoul
d we do different things?</li>
</ul>
</section>
<section anchor="positionpapers" numbered="true" toc="default">
<name>Position Papers</name>
<t>The following position papers were submitted to the workshop by the
following people (listed in alphabetical order):</t>
<ul spacing="normal">
<li><t><contact fullname="Jari Arkko"/>. "Changes in the Internet Threat
Model" <xref target="Arkko2019" format="default"/></t></li>
<li><t><contact fullname="Vittorio Bertola"/>. "How the Internet Was Won
and Where It Got Us" <xref target="Bertola2019" format="default"/></t></li>
<li><t><contact fullname="Carsten Bormann"/> and <contact fullname="Jan-
Frederik Rieckers"/>. "WiFi authentication: Some deployment observations from ed
uroam" <xref target="Bormann2019" format="default"/></t></li>
<li><t><contact fullname="Stéphane Bortzmeyer"/>. "Encouraging better de
ployments" <xref target="Bortzmeyer2019" format="default"/></t></li>
<li><t><contact fullname="Brian Carpenter"/> and <contact fullname="Bing
Liu"/>. &nbsp;"Limited Domains and Internet Protocols" <xref target="Carpenter2
019" format="default"/></t></li>
<li><t><contact fullname="Alissa Cooper"/>. "Don't Forget the Access Net
work" <xref target="Cooper2019" format="default"/></t></li>
<li><t><contact fullname="Stephen Farrell"/>. "We're gonna need a bigger
threat model" <xref target="Farrell2019" format="default"/></t></li>
<li><t><contact fullname="Phillip Hallam-Baker"/>. "The Devil is in the
Deployment" <xref target="HallamBaker2019" format="default"/></t></li>
<li><t><contact fullname="Ted Hardie"/>. "Instant Messaging and Presence
: A Cautionary Tale" <xref target="Hardie2019" format="default"/></t></li>
<li><t><contact fullname="Paul Hoffman"/>. "Realities in DNSSEC Deployme
nt" <xref target="Hoffman2019" format="default"/>
</t></li>
<li><t><contact fullname="Christian Huitema"/>. "Concentration is a busi
ness model" <xref target="Huitema2019" format="default"/></t></li>
<li><t><contact fullname="Geoff Huston"/>. "The Border Gateway Protocol,
25 years on" <xref target="Huston2019" format="default"/></t></li>
<li><t><contact fullname="Dirk Kutscher"/>. "Great Expectations: Protoco
l Design and Socioeconomic Realities" <xref target="Kutscher2019" format="defaul
t"/></t></li>
<li><t><contact fullname="Julien Maisonneuve"/>. "DNS, side effects and
concentration" <xref target="Maisonneuve2019" format="default"/></t></li>
<li><t><contact fullname="John Mattsson"/>. "Consolidation, Privacy, Jur
isdiction, and the Health of the Internet" <xref target="Mattsson2019" format="d
efault"/></t></li>
<li><t><contact fullname="Moritz Müller"/>. "Rolling Forward: An Outlook
on Future Root Rollovers" <xref target="Muller2019" format="default"/></t></li>
<li><t><contact fullname="Jörg Ott"/>. &nbsp;"Protocol Design Assumption
s and PEPs" <xref target="Ott2019" format="default"/></t></li>
<li><t><contact fullname="Lucas Pardue"/>. "Some challenges with IP mult
icast deployment" <xref target="Pardue2019" format="default"/></t></li>
<li><t><contact fullname="Jim Reid"/>. "Where/Why has DNS gone wrong?" <
xref target="Reid2019" format="default"/></t></li>
<li><t><contact fullname="Mohit Sethi"/> and <contact fullname="Tuomas A
ura"/>. "IoT Security and the role of Manufacturers: A Story of Unrealistic Desi
gn Expectations" <xref target="Sethi2019" format="default"/></t></li>
<li><t><contact fullname="Andrew Sullivan"/>. "Three kinds of concentrat
ion in open protocols" <xref target="Sullivan2019" format="default"/></t></li>
</ul>
<t>These papers are available from the IAB website <xref target="CFP" form
at="default"/> <xref target="POS" format="default"/>.</t>
</section>
<section anchor="discussions" numbered="true" toc="default">
<name>Discussions</name>
<section anchor="past-experiences" numbered="true" toc="default">
<name>Past Experiences</name>
<t>The workshop investigated deployment cases from certificate authoriti
es for web connections (WebPKI) to DNS Security (DNSSEC), from the Border Gatewa
y Protocol (BGP) to Network Address Translators (NATs), from DNS resolvers to CD
Ns, and from Internet of Things (IoT) systems to instant messaging and social me
dia applications.</t>
<t>In many cases, (1) there was a surprise in how technology was deploye
d,
(2)&nbsp;there was a lack of sufficient adoption, or (3)&nbsp;the business model
s associated with chosen technologies were not in favor of broader interoperabil
ity.</t>
<t>In general, the protocol designers cannot affect market forces but mu
st work within them. But there are often competing technical approaches or featu
res 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 establi
shed business, a feature designed to support collaboration among smaller players
, or some kind of disruption through a more speculative new feature or technolog
y.</t>
<t>Lessons learned include the following:</t>
<ul spacing="normal">
<li>Feedback from those who deploy often comes too late.</li>
<li>Building blocks get repurposed in unexpected ways.</li>
<li>User communities come in too late.</li>
<li>The Web is getting more centralized, and counteracting this trend
is difficult. It is not necessarily clear what technical path leads to distribut
ed markets and decentralized architectures, for instance.</li>
<li>There are also many forces that make it easier to pursue centraliz
ed models than other models. For instance, deployment is often easier in a centr
alized model. And various business and regulatory processes work best within a s
mall, well-defined set of entities that can interact with each other. This can l
ead to, for instance, regulators preferring a situation with a small number of e
ntities that they can talk to, rather than a diverse set of providers.</li>
<li>It is important but hard to determine how useful new protocols are
.</li>
<li>It is difficult for the IETF community to interact with other comm
unities, e.g., specific business sectors that need new technology (such as aviat
ion or healthcare) or regulators.</li>
</ul>
</section>
<section anchor="principles" numbered="true" toc="default">
<name>Principles</name>
<t>Several underlying principles can be observed in the example cases th
at were discussed. Deployment failures tend to be associated with cases where in
terdependencies make progress difficult and there's no major advantage for early
deployment. Despite persistent problems in the currently used technology, it be
comes difficult for the ecosystem to switch to better technology. For instance,
there are a number of areas where the Internet routing protocol BGP <xref target
="RFC4271" format="default"/> is lacking, but there has been only limited succes
s in deploying significant improvements -- for instance, in the area of security
.</t>
<t>Another principle appears to be first-mover advantage. Several equall
y interesting technologies have fared in very different ways, depending on wheth
er there was an earlier system that provided most of the benefits of the new sys
tem. Again, despite potential problems in an already-deployed technology, it bec
omes 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 DN
SSEC <xref target="RFC4033" format="default"/> is not. Is this because of the ea
rlier commercial adoption of WebPKI, the more complex interdependencies between
systems that wished to deploy DNSSEC, or some other reason?</t>
<t>The definition of "success" in <xref target="RFC5218" format="default
"/> appears to be part of the problem. The only way to control deployments up fr
ont is to prevent wild success, but wild successes are actually what we want. An
d it seems very difficult to predict these successes.</t>
<t>The workshop also discussed the extent to which protocol work even sh
ould 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.</t>
<t>The workshop also discussed different types of deployment patterns on
the Internet:</t>
<ul spacing="normal">
<li>Delivering functionality over the Internet as a web service. The I
nternet 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 aga
inst each other over the browser and Internet infrastructure. Several large appl
ication systems have grown in the Internet in this manner, encompassing large am
ounts of functionality and a large fraction of Internet users. This makes it eas
ier for web applications to grow by themselves without cross-fertilization or in
teroperability.</li>
<li>Delivering concentrated network services that offer the standard c
apabilities of the Internet. Examples in this category include the provisioning
of some mail services, DNS resolution, and so on.</li>
</ul>
<t>The second case is more interesting for an Internet architecture disc
ussion. There can, however, be different underlying situations even in that case
. The service may be simply a concentrated way to provide a commodity service. T
he market should find a natural equilibrium for such situations. This may be fin
e, 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).</
t>
<t>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.
</t>
<t>The group also discussed monocultures, and their negative effect on t
he Internet and its stability and resistance to various problems and attacks.</t
>
<t>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.</t>
</section>
<section anchor="centralized-deployment-models" numbered="true" toc="defau
lt">
<name>Centralized Deployment Models</name>
<t>Many of the participants have struggled with these trends and their e
ffect on desirable characteristics of Internet systems, such as distributed, end
-to-end architecture or privacy. Yet, there are many business and technical driv
ers causing the Internet architecture to become further and further centralized.
</t>
<t>Some observations that were made:</t>
<ul spacing="normal">
<li>When standardizing new technology, the parties involved in the eff
ort may think they agree on what the goals are but in reality are often surprise
d in the end. For instance, with DNS (queries) over HTTPS (DoH) <xref target="RF
C8484" format="default"/>, there were very different aspirations, some around im
provements in confidentiality of the queries, some around operational and latenc
y improvements to DNS operations, and some about shifting business and deploymen
t models. The full picture was not clear before the work was completed.</li>
<li>In DNS, DDoS is a practical reality, and only a handful of provide
rs can handle the traffic load in these attacks.</li>
</ul>
<t>The hopeful side of this issue is that there are some potential answe
rs:</t>
<ul spacing="normal">
<li>DDoS defenses do not have to come through large entities, as layer
ed defenses and federation also help similarly.</li>
<li>Surveillance state data capture can be fought with data object enc
ryption and by not storing all of the data in one place.</li>
<li>Web tracking can be combatted by browsers choosing to avoid techni
ques that are sensitive to tracking. Competition in the browser market may help
drive some of these changes.</li>
<li>Open interfaces help guard against the bundling of services in one
large entity; as long as there are open, well-defined interfaces to specific fu
nctions, these functions can also be performed by other parties.</li>
<li>Commercial surveillance does not seem to be curbed by current mean
s. But there are still possibilities, such as stronger regulation, data minimiza
tion, or browsers acting on behalf of users. There are hopeful signs that at lea
st some browsers are becoming more aggressive in this regard. But more is needed
.</li>
</ul>
<t>One comment made in the workshop was that the Internet community need
s to curb the architectural trend of centralization. Another comment was that di
scussing this in the abstract is not as useful as more concrete, practical actio
ns. For instance, one might imagine different DoH deployments with widely differ
ent implications for privacy or tolerance of failures. Getting to the specifics
of how a particular service can be made better is important.</t>
</section>
<section anchor="security" numbered="true" toc="default">
<name>Security</name>
<t>This part of the discussion focused on whether in the current state o
f the Internet we actually need a new threat model.</t>
<t>Many of the security concerns regarding communications have been addr
essed in the past few years, with increasing encryption. However, issues with tr
usting endpoints on the other side of the communication have not been addressed
and are becoming more urgent with the advent of centralized service architecture
s.
</t>
<t>Further effort may be needed to minimize centralization, as having on
ly a few places to tap increases the likelihood of surveillance.</t>
<t>There may be a need to update <xref target="RFC3552" format="default"
/> and <xref target="RFC7258" format="default"/>.</t>
<t>The participants in the workshop agreed that a new threat model is ne
eded and that non-communications-security issues need to be handled.
</t>
<t>Other security discussions were focused on IoT systems, algorithm agi
lity issues, experiences from difficult security upgrades such as DNSSEC key rol
lovers, and routing security.</t>
<t>The participants cautioned against relying too much on device manufac
turers for security, and being clear on security models and assumptions. Securit
y is often poorly understood, and the assumptions about who the system defends a
gainst and who it does not are not clear.
</t>
</section>
<section anchor="future" numbered="true" toc="default">
<name>Future</name>
<t>The workshop turned into a discussion of what actions we can take:</t
>
<ul spacing="normal">
<li>Documenting our experiences?</li>
<li>Providing advice (to the IETF or to others)?</li>
<li>Waiting for the catastrophe that will make people agree to changes
? The participants of course did not wish for this.</li>
<li>Work at the IETF?</li>
<li>Technical solutions/choices?</li>
</ul>
<t>The best way for the IETF to do things is through standards; convinci
ng people through other requests is difficult. The IETF needs to:</t>
<ul spacing="normal">
<li>Pick pieces that it is responsible for.</li>
<li>Be reactive for the rest, be available as an expert in other discu
ssions, provide Internet technology knowledge where needed, etc.</li>
</ul>
<t>One key question is what other parties need to be involved in any dis
cussions. Platform developers (mobile platforms, cloud systems, etc.) are one su
ch group. Specific technology or business groups (such as email provider or cert
ificate authority forums) are another.</t>
<t>The workshop also discussed specific technology issues -- for instanc
e, around IoT systems. One observation in those systems is that there is no sing
le model for applications; they vary. There are a lot of different constraints i
n different systems and different control points. What is perhaps most needed to
day is user control and transparency (for instance, via Manufacturer Usage Descr
iptions (MUDs) <xref target="RFC8520" format="default"/>). Another issue is mana
gement, particularly for devices that could be operational for decades. Given th
e diversity of IoT systems, it may also make more sense to build support systems
for broader solutions than for specific solutions or specific protocols.
</t>
<t>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 provid
e data minimization to cut down on the potential for leakages. And the difficult
y of establishing peer-to-peer security strengthens the need for a central point
, which may also be harmful from a long-term privacy perspective.</t>
</section>
</section>
<section anchor="conclusions" numbered="true" toc="default">
<name>Conclusions</name>
<section anchor="summary-of-discussions" numbered="true" toc="default">
<name>Summary of Discussions</name>
<t>The workshop met in the sunny Finnish countryside and made the unsurp
rising observation that technologies sometimes get deployed in surprising ways.
But the consequences of deployment choices can have an impact on security, priva
cy, centralized vs. distributed models, competition, and surveillance. As the IE
TF community cares deeply about these aspects, it is worthwhile to spend time on
the analysis of these choices.</t>
<t>The prime factor driving deployments is perceived needs; expecting pe
ople to recognize obvious virtues and therefore deploy them is not likely to wor
k.</t>
<t>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.</t>
<t>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 o
f what parties need to perform what actions.</t>
<t>The workshop also made some technical observations. One issue is that
the workshop identified a set of hard issues that affect deployment and for whi
ch we have no good solutions. These issues include, for instance, dealing with D
DoS attacks and how to handle spam. Similarly, a lack of good solutions for micr
opayments is one factor behind a lot of the Internet economy being based on adve
rtisements.</t>
<t>One recent trend is that technology is moving up the stack, e.g., in
the areas of services, transport protocol functionality, security, naming, and s
o on. This impacts how easy or hard changes are and who is able to perform them.
</t>
<t>It was also noted that interoperability continues to be important, an
d we need to explore what new interfaces need standardization -- this will enabl
e different deployment models and competition. The prime factor driving deployme
nts is actual needs; we cannot force anything on others but can provide solution
s for those that need them. Needs and actions may fall to different parties.</t>
<t>The workshop also considered the balancing of user non-involvement an
d transparency, as well as choice, relevant threats such as communicating with m
alicious endpoints, the role and willingness of browsers in increasing the abili
ty to defend users' privacy, and concerns around centralized control or data sto
rage points.</t>
<t>The workshop also discussed specific issues around routing, DoS attac
ks, IoT systems, the role of device manufacturers, the DNS, and regulatory react
ions and their possible consequences.</t>
</section>
<section anchor="actions" numbered="true" toc="default">
<name>Actions</name>
<t>The prime conclusion from the workshop was that the topics we discuss
ed were not completed in the workshop. Much more work is needed. The best way fo
r 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 discussi
ons.</t>
<section anchor="potential-architecture-actions-and-outputs" numbered="t
rue" toc="default">
<name>Potential Architecture Actions and Outputs</name>
<t>The documents/outputs and actions described in the following items
were deemed relevant by the participants.</t>
<ul spacing="normal">
<li>Develop and document a modern threat model.</li>
<li>Continue discussion of consolidation/centralization issues.</li>
<li>Document architectural principles, e.g., (re)application of the
end-to-end principle.</li>
</ul>
<t>The first receiver of these thoughts is the IETF and protocol commu
nity, but combined with some evangelizing and validation elsewhere.</t>
</section>
<section anchor="potential-other-actions" numbered="true" toc="default">
<name>Other Potential Actions</name>
<ul spacing="normal">
<li>Pursuit of specific IETF topics, e.g., working on taking into ac
count reputation systems in IETF work, working to ensure that certificate scopin
g can be appropriately limited, building end-to-end encryption tools for applica
tions, etc.</li>
<li>General deployment experiences/advice, and documenting deploymen
t assumptions possibly already in WG charters.</li>
<li>A report will be produced from the workshop (this RFC).</li>
</ul>
</section>
</section>
<section anchor="other-publications" numbered="true" toc="default">
<name>Other Publications</name>
<t>The workshop results have also been reported at <xref target="ISPColu
mn" format="default"/> by <contact fullname="Geoff Huston"/>.</t>
</section>
<section anchor="feedback" numbered="true" toc="default">
<name>Feedback</name>
<t>Feedback regarding the workshop is appreciated and can be sent to the
program committee, the IAB, or the architecture-discuss list.</t>
</section>
</section>
<section anchor="sec-cons" numbered="true" toc="default">
<name>Security Considerations</name>
<t>Proposals discussed at the workshop would have significantly different
security impacts, and each workshop paper should be read for its own security co
nsiderations.</t>
</section>
</middle>
<back>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.3552.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4033.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.4271.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.5218.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7258.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8170.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8484.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8520.xml"/>
<reference anchor="Arkko2019">
<front>
<title>Changes in the Internet Threat Model</title>
<author initials="J." surname="Arkko">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Bertola2019">
<front>
<title>How the Internet Was Won and Where It Got Us</title>
<author initials="V." surname="Bertola">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Bormann2019">
<front>
<title>WiFi authentication: Some deployment observations from eduroam<
/title>
<author initials="C." surname="Bormann">
<organization/>
</author>
<author initials="J." surname="Rieckers">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Bortzmeyer2019">
<front>
<title>Encouraging better deployments</title>
<author initials="S." surname="Bortzmeyer">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Carpenter2019">
<front>
<title>Limited Domains and Internet Protocols</title>
<author initials="B." surname="Carpenter">
<organization/>
</author>
<author initials="B." surname="Liu">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Cooper2019">
<front>
<title>Don't Forget the Access Network</title>
<author initials="A." surname="Cooper">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Farrell2019">
<front>
<title>We're gonna need a bigger threat model</title>
<author initials="S." surname="Farrell">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="HallamBaker2019">
<front>
<title>The Devil is in the Deployment</title>
<author initials="P." surname="Hallam-Baker">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Hardie2019">
<front>
<title>Instant Messaging and Presence: A Cautionary Tale</title>
<author initials="T." surname="Hardie">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Hoffman2019">
<front>
<title>Realities in DNSSEC Deployment</title>
<author initials="P." surname="Hoffman">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Huitema2019">
<front>
<title>Concentration is a business model</title>
<author initials="C." surname="Huitema">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Huston2019">
<front>
<title>The Border Gateway Protocol, 25 years on</title>
<author initials="G." surname="Huston">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Kutscher2019">
<front>
<title>Great Expectations: Protocol Design and Socioeconomic Realities
</title>
<author initials="D." surname="Kutscher">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Maisonneuve2019">
<front>
<title>DNS, side effects and concentration</title>
<author initials="J." surname="Maisonneuve">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Mattsson2019">
<front>
<title>Consolidation, Privacy, Jurisdiction, and the Health of the Int
ernet</title>
<author initials="J." surname="Mattsson">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Muller2019">
<front>
<title>Rolling Forward: An Outlook on Future Root Rollovers</title>
<author initials="M." surname="Müller">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Ott2019">
<front>
<title>Protocol Design Assumptions and PEPs</title>
<author initials="J." surname="Ott">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Pardue2019">
<front>
<title>Some challenges with IP multicast deployment</title>
<author initials="L." surname="Pardue">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Reid2019">
<front>
<title>Where/Why has DNS gone wrong?</title>
<author initials="J." surname="Reid">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Sethi2019">
<front>
<title>IoT Security and the role of Manufacturers: A Story of Unrealis
tic Design Expectations</title>
<author initials="M." surname="Sethi">
<organization/>
</author>
<author initials="T." surname="Aura">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="Sullivan2019">
<front>
<title>Three kinds of concentration in open protocols</title>
<author initials="A." surname="Sullivan">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
<refcontent>position paper submitted for the IAB DEDR workshop</refconte
nt>
</reference>
<reference anchor="CFP" target="https://www.iab.org/activities/workshops/d
edr-workshop/">
<front>
<title>Design Expectations vs. Deployment Reality in Protocol Developm
ent Workshop 2019</title>
<author><organization>IAB</organization></author>
<date year="2019" month="June"/>
</front>
</reference>
<reference anchor="POS" target="https://www.iab.org/activities/workshops/d
edr-workshop/position-papers/">
<front>
<title>Position Papers: DEDR Workshop</title>
<author><organization>IAB</organization></author>
<date year="2019" month="June"/>
</front>
</reference>
<reference anchor="ISPColumn" target="https://www.potaroo.net/ispcol/2019-
06/dedr.html">
<front>
<title>Network Protocols and their Use</title>
<author initials="G." surname="Huston">
<organization/>
</author>
<date year="2019" month="June"/>
</front>
</reference>
</references>
<section anchor="participants" numbered="true" toc="default">
<name>Participant List</name>
<t>The following is a list of participants on site and over a remote conne
ction:</t>
<ul spacing="normal">
<li><t><contact fullname="Arkko, Jari"/></t></li>
<li><t><contact fullname="Aura, Tuomas"/></t></li>
<li><t><contact fullname="Bertola, Vittorio"/></t></li>
<li><t><contact fullname="Bormann, Carsten"/></t></li>
<li><t><contact fullname="Bortzmeyer, Stéphane"/></t></li>
<li><t><contact fullname="Cooper, Alissa"/></t></li>
<li><t><contact fullname="Farrell, Stephen"/></t></li>
<li><t><contact fullname="Flinck, Hannu"/></t></li>
<li><t><contact fullname="Gahnberg, Carl"/></t></li>
<li><t><contact fullname="Hallam-Baker, Phillip"/></t></li>
<li><t><contact fullname="Hardie, Ted"/></t></li>
<li><t><contact fullname="Hoffman, Paul"/></t></li>
<li><t><contact fullname="Huitema, Christian"/> (remote)</t></li>
<li><t><contact fullname="Huston, Geoff"/></t></li>
<li><t><contact fullname="Komaitis, Konstantinos"/></t></li>
<li><t><contact fullname="Kühlewind, Mirja"/></t></li>
<li><t><contact fullname="Kutscher, Dirk"/></t></li>
<li><t><contact fullname="Li, Zhenbin"/></t></li>
<li><t><contact fullname="Maisonneuve, Julien"/></t></li>
<li><t><contact fullname="Mattsson, John"/></t></li>
<li><t><contact fullname="Müller, Moritz"/></t></li>
<li><t><contact fullname="Ott, Jörg"/></t></li>
<li><t><contact fullname="Pardue, Lucas"/></t></li>
<li><t><contact fullname="Reid, Jim"/></t></li>
<li><t><contact fullname="Rieckers, Jan-Frederik"/></t></li>
<li><t><contact fullname="Sethi, Mohit"/></t></li>
<li><t><contact fullname="Shore, Melinda"/> (remote)</t></li>
<li><t><contact fullname="Soininen, Jonne"/></t></li>
<li><t><contact fullname="Sullivan, Andrew"/></t></li>
<li><t><contact fullname="Trammell, Brian"/></t></li>
</ul>
</section>
<section numbered="false" toc="default">
<name>IAB Members at the Time of Approval</name>
<t>Internet Architecture Board members at the time this document was
approved for publication were:</t>
<ul empty="true" spacing="compact">
<li><t><contact fullname="Jari Arkko"/></t></li>
<li><t><contact fullname="Alissa Cooper"/></t></li>
<li><t><contact fullname="Stephen Farrell"/></t></li>
<li><t><contact fullname="Wes Hardaker"/></t></li>
<li><t><contact fullname="Ted Hardie"/></t></li>
<li><t><contact fullname="Christian Huitema"/></t></li>
<li><t><contact fullname="Zhenbin Li"/></t></li>
<li><t><contact fullname="Erik Nordmark"/></t></li>
<li><t><contact fullname="Mark Nottingham"/></t></li>
<li><t><contact fullname="Melinda Shore"/></t></li>
<li><t><contact fullname="Jeff Tantsura"/></t></li>
<li><t><contact fullname="Martin Thomson"/></t></li>
<li><t><contact fullname="Brian Trammell"/></t></li>
</ul>
</section>
<section anchor="ack" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank the workshop participants, the members
of the IAB, and the participants in the architecture discussion list for interes
ting discussions. The notes from <contact fullname="Jim Reid"/> were instrumenta
l in writing this report. The workshop organizers would also like to thank Nokia
for hosting the workshop in excellent facilities in Kirkkonummi, Finland.</t>
</section>
</back>
</rfc>
 End of changes. 1 change blocks. 
lines changed or deleted lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/