draft-arkko-arch-dedr-report-00.txt   draft-arkko-arch-dedr-report.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational T. Hardie Intended status: Informational T. Hardie
Expires: May 7, 2020 Google Expires: September 11, 2020 Google
November 04, 2019 March 10, 2020
Report from the IAB workshop on Design Expectations vs. Deployment Report from the IAB workshop on Design Expectations vs. Deployment
Reality in Protocol Development Reality in Protocol Development
draft-arkko-arch-dedr-report-00 draft-iab-dedr-report-00
Abstract Abstract
The Design Expectations vs. Deployment Reality in Protocol The Design Expectations vs. Deployment Reality in Protocol
Development Workshop was convened by the Internet Architecture Board Development Workshop was convened by the Internet Architecture Board
(IAB) in June 2019. This report summarizes its significant points of (IAB) in June 2019. This report summarizes its significant points of
discussion and identifies topics that may warrant further discussion and identifies topics that may warrant further
consideration. consideration.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 7, 2020. This Internet-Draft will expire on September 11, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Workshop Agenda . . . . . . . . . . . . . . . . . . . . . . . 4 2. Workshop Agenda . . . . . . . . . . . . . . . . . . . . . . . 4
3. Position Papers . . . . . . . . . . . . . . . . . . . . . . . 4 3. Position Papers . . . . . . . . . . . . . . . . . . . . . . . 4
4. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Past experiences . . . . . . . . . . . . . . . . . . . . 6 4.1. Past experiences . . . . . . . . . . . . . . . . . . . . 6
4.2. Principles . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Principles . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Centralised deployment models . . . . . . . . . . . . . . 7 4.3. Centralised deployment models . . . . . . . . . . . . . . 8
4.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Future . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Future . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Summary of discussions . . . . . . . . . . . . . . . . . 9 5.1. Summary of discussions . . . . . . . . . . . . . . . . . 11
5.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. Potential architecture actions and outputs . . . . . 11 5.2.1. Potential architecture actions and outputs . . . . . 12
5.2.2. Potential other actions . . . . . . . . . . . . . . . 11 5.2.2. Potential other actions . . . . . . . . . . . . . . . 13
5.3. Other publications . . . . . . . . . . . . . . . . . . . 11 5.3. Other publications . . . . . . . . . . . . . . . . . . . 13
5.4. Feedback . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4. Feedback . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Informative References . . . . . . . . . . . . . . . . . . . 11 6. Informative References . . . . . . . . . . . . . . . . . . . 13
Appendix A. Particant List . . . . . . . . . . . . . . . . . . . 14 Appendix A. Particant List . . . . . . . . . . . . . . . . . . . 16
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The Design Expectations vs. Deployment Reality in Protocol The Design Expectations vs. Deployment Reality in Protocol
Development Workshop was convened by the Internet Architecture Board Development Workshop was convened by the Internet Architecture Board
(IAB) in June 2019. This report summarizes its significant points of (IAB) in June 2019. This report summarizes its significant points of
discussion and identifies topics that may warrant further discussion and identifies topics that may warrant further
consideration. consideration.
Note: While late in being submitted, this report is still an early Note: While late in being submitted, this report is still an early
skipping to change at page 6, line 17 skipping to change at page 6, line 17
These papers are available from the IAB website [CFP] [POS]. These papers are available from the IAB website [CFP] [POS].
4. Discussions 4. Discussions
4.1. Past experiences 4.1. Past experiences
The workshop investigated deployment cases from WebPKI to DNSSEC, The workshop investigated deployment cases from WebPKI to DNSSEC,
from BGP to NATs, from DNS resolvers to CDNs, and from IOT to instant from BGP to NATs, from DNS resolvers to CDNs, and from IOT to instant
messaging and social media applications. messaging and social media applications.
In many cases there was either a surprise in how technology was
deployed, lack of sufficient adoption, or 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 it is possible to choose, for instance,
whether to work to support the markets with standards that an
established business clearly needs, or to enable competition and
disruption through more speculative new technology.
Themes on lessons learned include:
o Feedback from those who deploy often comes too late.
o Building blocks get re-purposed in unexpected ways
o User communities come in too late.
o The web is getting more centralised. Counteracting this trend is
difficult. Even when there's a clear goal, such as supporting de-
centralised market models, it is not necessarily clear what
technical path leads to such goals. There are also many forces
that make it easier to pursue centralised models, deployment is
often easier in such a model, the technologists and regulators
find more easily which parties to talk to about the topic, and so
on.
o It is important but hard to determine how useful new protocols
are.
o It is difficult for the IETF community to interact with others,
e.g., specific business sectors that need new technology (such as
aviation or healthcare) or regulators.
4.2. Principles 4.2. Principles
Several underlying principles can be observed in the example cases Several underlying principles can be observed in the example cases
that were discussed. Deployment failures tend to be associated with that were discussed. Deployment failures tend to be associated with
cases where interdependencies make progress difficult and there's no cases where interdependencies make progress difficult and there's no
major advantage for early deployment. Despite persistent problems in major advantage for early deployment. Despite persistent problems in
the currently used technology, it becomes difficult for the ecosystem the currently used technology, it becomes difficult for the ecosystem
to switch to better technology. For instance, there are a number of to switch to better technology. For instance, there are a number of
areas where the Internet routing protocol, BGP, is lacking, but areas where the Internet routing protocol, BGP, is lacking, but
success in deploying significant improvements has been lacking, for success in deploying significant improvements has been lacking, for
skipping to change at page 6, line 41 skipping to change at page 7, line 29
depending whether there was an earlier system that provided most of depending whether there was an earlier system that provided most of
the benefits of the new system. Again, despite potential problems in the benefits of the new system. Again, despite potential problems in
an already deployed technology, it becomes difficult to deploy an already deployed technology, it becomes difficult to deploy
improvements due to lack of immediate incentives and due to the improvements due to lack of immediate incentives and due to the
competing and already deployed alternative that is proceeding forward competing and already deployed alternative that is proceeding forward
in the ecosystem. For instance, WebPKI is very widely deployed and in the ecosystem. For instance, WebPKI is very widely deployed and
used, but DNSSEC is not. Is this because the earlier commercial used, but DNSSEC is not. Is this because the earlier commercial
adoption of WebPKI, and the initially more complex interdependencies adoption of WebPKI, and the initially more complex interdependencies
between systems that wished to deploy DNSSEC. between systems that wished to deploy DNSSEC.
The definition of success in [RFC5218] appears to a 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 anyway. The workshop
also discussed the extent to which protocol work 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 workshop also discussed different types of deployment patterns on
the Internet: the Internet:
o Delivering functionality over Internet as a web service. The o Delivering functionality over Internet as a web service. The
Internet is an open and standardised system, but the service on Internet is an open and standardised system, but the service on
top may be closed, essentially running two components of the top may be closed, essentially running two components of the same
service provider's software against each other over the browser service provider's software against each other over the browser
and Internet infrastructure. Several large application systems and Internet infrastructure. Several large application systems
have grown in the Internet in this manner, encompassing large have grown in the Internet in this manner, encompassing large
amounts of functionality and a large fraction of Internet users. amounts of functionality and a large fraction of Internet users.
This makes it easier for web applications to grow by themselves
without cross-fertilisation or interoperability.
o Delivering concentrated network services that offer the standard o Delivering concentrated network services that offer the standard
capabilities of the Internet. Examples in this category include capabilities of the Internet. Examples in this category include
the provisioning of DNS resolution, some mail services, and so on. the provisioning of some mail services, DNS resolution, and so on.
The second case is more interesting for an Internet architecture The second case is more interesting for an Internet architecture
discussion. There can, however, be different underlying situations discussion. There can, however, be different underlying situations
in that case. The service may be simply a concentrated way to even in that case. The service may be simply a concentrated way to
provide a commodity service. The market should find a natural provide a commodity service. The market should find a natural
equilibrium for such situations. This may be fine, particularly, equilibrium for such situations. This may be fine, particularly,
where the service does not provide any new underlying advantage to where the service does not provide any new underlying advantage to
whoever is providing it (in the form of user data that can be whoever is providing it (in the form of user data that can be
commercialized, for instance, or as training data for an important commercialized, for instance, or as training data for an important
machine learning service). machine learning service).
Secondly, the service may be an extension beyond standard protocols, Secondly, the service may be an extension beyond standard protocols,
leading to some questions about how well standards and user leading to some questions about how well standards and user
expectations match. But those questions could be addressed by better expectations match. But those questions could be addressed by better
or newer standards. But the third situation is more troubling: the or newer standards. But the third situation is more troubling: the
service are provided in this concentrated manner due to business service are provided in this concentrated manner due to business
patterns that make it easier for particular entities to deploy such patterns that make it easier for particular entities to deploy such
services. services.
The group also discussed monocultures, and their negative effect on
the Internet and its stability.
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. Centralised deployment models 4.3. Centralised deployment models
Many of the participants have struggled with these trends and their Many of the participants have struggled with these trends and their
effect on desirable characteristics of Internet systems, such as effect on desirable characteristics of Internet systems, such as
distributed, end-to-end architecture or privacy. Yet, there are many distributed, end-to-end architecture or privacy. Yet, there are many
business and technical drivers causing the Internet architecture to business and technical drivers causing the Internet architecture to
become further and further centralised. become further and further centralised.
Some observations that were made:
o When standardising new technology, the parties involved in the
effort may think they agree on what the goals are, but often in
reality are surprised in the end. For instance, with DNS-over-
HTTPS 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.
o In DNS, UDP-based DDOS is 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 The hopeful side of this issue is that there are some potential
answers: answers:
o DDOS defenses do not have to come through large entities, as o DDOS defenses do not have to come through large entities, as
layered defenses and federation also helps similarly. layered defenses and federation also helps similarly.
o Surveillance state data capture can be fought with data object o Surveillance state data capture can be fought with data object
encryption, and not storing all of the datal in one place. encryption, and not storing all of the data in one place.
o Open interface help guard against the bundling of services in one o Web tracking can be combatted by browsers choosing to avoid the
techniques sensitive to tracking. Competition in the browser
market may help drive some of these changes.
o Open interfaces help guard against the bundling of services in one
large entity; as long as there are open, well-defined interface to large entity; as long as there are open, well-defined interface to
specific functions these functions can also be performed by other specific functions these functions can also be performed by other
parties. parties.
o Commercial surveillance does not seem to curbed by current means. o Commercial surveillance does not seem to be curbed by current
But there are still possibilities, such as stronger regulation, means. But there are still possibilities, such as stronger
data minimisation, or browsers acting on behalf of users. There regulation, data minimisation, or browsers acting on behalf of
are hopeful signs that at least some browsers are becoming more users. There are hopeful signs that at least some browsers are
aggressive in this regard. But more is needed. becoming more aggressive in this regard. But more is needed.
One comment made in the workshop that the Internet community needs to One comment made in the workshop that the Internet community needs to
move back from regulation to trying to curb the architectural trend curb the architectural trend of centralization. Another comment was
of centralization instead. Another comment was that discussing this that discussing this in the abstract is not as useful as more
in the abstract is not as useful as more concrete, practical actions. concrete, practical actions. For instance, one might imagine
For instance, one might imagine DOH deployments with larger number of different DOH deployments with widely different implications for
trusted resolvers. privacy or tolerance of failures. Getting to the specifics of how a
particular service can be made better is important.
4.4. Security 4.4. Security
This part of the discussed focused on whether in the current state of This part of the discussed focused on whether in the current state of
the Internet we actually need a new threat model. the Internet we actually need a new threat model.
Many of the communications security concerns have been addressed in Many of the communications security concerns have been addressed in
the past few years, with increasing encryption. However, issues with the past few years, with increasing encryption. However, issues with
trusting endpoints on the other side of the communication have not trusting endpoints on the other side of the communication have not
been addressed, and are becoming more urgent with the advent or been addressed, and are becoming more urgent with the advent or
centralised service architectures. centralised service architectures.
Further effort may be needed to minimise centralisation, as having
only 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 The participants in the workshop agreed that a new threat model is
needed, and that non-communications-security issues need to be needed, and that non-communications-security issues need to be
treated. treated.
Other security discussions were focused on IOT systems, algorithm Other security discussions were focused on IOT systems, algorithm
agility issues, and experiences from difficult security upgrades such agility issues, experiences from difficult security upgrades such as
as the DNSSEC key rollover. the DNSSEC key rollover, and routing security.
The participants cautioned against relying too much on device The participants cautioned against relying too much on device
manufacturers for security, and being clear on security models and manufacturers for security, and being clear on security models and
assumptions. Security is often poorly understood, and the assumptions. Security is often poorly understood, and the
assumptions about who the system defends against and not are not assumptions about who the system defends against and not are not
clear. clear.
4.5. Future 4.5. Future
The workshop turned into a discussion of what actions we can take: The workshop turned into a discussion of what actions we can take:
skipping to change at page 9, line 4 skipping to change at page 10, line 33
The workshop turned into a discussion of what actions we can take: The workshop turned into a discussion of what actions we can take:
o Documenting our experiences? o Documenting our experiences?
o Providing advice (to IETF, to others) o Providing advice (to IETF, to others)
o Waiting for the catastrophe that will make people agree to o Waiting for the catastrophe that will make people agree to
changes? (hopefully not this) changes? (hopefully not this)
o Work at the IETF? o Work at the IETF?
o Technical solutions/choices? o Technical solutions/choices?
The best way for ietf to do things is through standards; convinging The best way for the IETF to do things is through standards;
people through other requests is difficult. The IETF needs to: convincing people through other requests is difficult. The IETF
needs to:
o pick pieces that it is responsible for o Pick pieces that it is responsible for.
o being reactive for the rest, be available as an expert in other o Be reactive for the rest, be available as an expert in other
discussions, provide Internet technology clue where needed, etc. discussions, provide Internet technology clue where needed, etc.
One key question is what other parties need to be involved in any One key question is what other parties need to be involved in any
discussions. Platform developers (mobile platforms, cloud systems, discussions. Platform developers (mobile platforms, cloud systems,
etc) is one such group. Specific technology or business groups (such etc.) is one such group. Specific technology or business groups
as email provider or certificate authority forums) are another. (such as email provider or certificate authority forums) are another.
The workshop also discussed specific technology issues, for instance The workshop also discussed specific technology issues, for instance
around IOT systems. One observation in those systems is that there around IOT systems. One observation in those systems is that there
is no single model for applications, they vary. There are a lot of is no single model for applications, they vary. There are a lot of
different constraints in different systems and different control different constraints in different systems and different control
points. What is needed perhaps most today is user control and points. What is needed perhaps most today is user control and
transparency (for instance, via MUD descriptions). Another issue is transparency (for instance, via MUD descriptions). Another issue is
management, particularly for devices that could be operational for management, particularly for devices that could be operational for
decades. Given the diversity of IOT systems, it may also make more decades. Given the diversity of IOT systems, it may also make more
sense to build support systems for the broader solutions that sense to build support systems for the broader solutions that
skipping to change at page 9, line 43 skipping to change at page 11, line 25
scales, or be able to provide data minimization to cut down on scales, or be able to provide data minimization to cut down on
potential for leakages. And the difficulty of establishing peer-to- potential for leakages. And the difficulty of establishing peer-to-
peer security strengthens the need for a central point, which may peer security strengthens the need for a central point, which may
also be harmful from a long-term privacy perspective. also be harmful from a long-term privacy perspective.
5. Conclusions 5. Conclusions
5.1. Summary of discussions 5.1. Summary of discussions
The workshop met in sunny Finnish countryside and made the non- The workshop met in sunny Finnish countryside and made the non-
suprising observation that technologies sometimes get deployed in surprising observation that technologies sometimes get deployed in
surprising ways. But the consequences of deployment choices can have surprising ways. But the consequences of deployment choices can have
an impact on security, privacy, centralised vs. distributed models, an impact on security, privacy, centralised vs. distributed models,
competition, surveillance, and the IETF community cares deeply about competition, surveillance. As the IETF community cares deeply about
these aspects, so it is worthwhile to spend time in analysis of these these aspects, it is worthwhile to spend time in analysis of these
choices. choices.
The prime factor driving deployments is perceived needs; expecting The prime factor driving deployments is perceived needs; expecting
people to recognise obvious virtues and therefore deploy is not people to recognise obvious virtues and therefore deploy is not
likely to work. likely to work.
And the ecosystem is complex, including for instance many parties: And the ecosystem is complex, including for instance many parties:
different business roles, users, regulators, and so on, and different business roles, users, regulators, and so on, and
perceptions of needs and ability to act depends highly on what party perceptions of needs and ability to act depends highly on what party
one talks to. one talks to.
While the workshop discussed actions and advice, there is a critical While the workshop discussed actions and advice, there is a critical
question of who these are targeted towards. There is need to question of who these are targeted towards. There is need to
construct a map of what parties need to perform what actions. construct a map of what parties need to perform what actions.
The workshop also made some technical observations. One recent trend The workshop also made some technical observations. One issue is
is that technology is moving up the stack, e.g., in the areas of that the workshop identified a set of hard issues that affect
services, transport protocol functionality, security, naming, and so deployment and for which have no good solutions. These issues
on. This impacts how easy or hard changes are, and who is able to include, for instance, dealing with distributed denial-of-service
perform them. attacks or how to handle spam. Similarly, 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, It was also noted that interoperability continues to be important,
and we need to explore what new interfaces need standardisation -- and we need to explore what new interfaces need standardisation --
this will enable different deployment models & competition. Prime this will enable different deployment models & competition. Prime
factor driving deployments is actual needs; we cannot force anything factor driving deployments is actual needs; we cannot force anything
to others but can provide solutions for those that need them. Needs to others but can provide solutions for those that need them. Needs
and actions may fall on different parties. and actions may fall on different parties.
The workshop also considered the balancing of user non-involvement The workshop also considered the balancing of user non-involvement
and transparency and choice, relevant threats such as communicating and transparency and choice, relevant threats such as communicating
with malicious endpoints, the role and willigness of browsers in with malicious endpoints, the role and willingness of browsers in
increasing the ability to defending the users' privacy, and concerns increasing the ability to defending the users' privacy, and concerns
around centralised control or data storage points around centralised control or data storage points
The workshop also discussed specific issues around routing, denial- The workshop also discussed specific issues around routing, denial-
of-service attacks, IOT systems, role of device manufacturers, the of-service attacks, IOT systems, role of device manufacturers, the
DNS, and regulatory reactions and their possible consequences. DNS, and regulatory reactions and their possible consequences.
5.2. Actions 5.2. Actions
The prime conclusion from the workshop was that the topic is not The prime conclusion from the workshop was that the topic is not
completed in the workshop. Much more work is needed. The best way completed in the workshop. Much more work is needed. The best way
for ietf to do things is through standards. The IETF should focus on for the IETF to make an impact is through standards. The IETF should
the parts that it is responsible for, and be available as an expert focus on the parts that it is responsible for, and be available as an
on other discussions. expert on other discussions.
The documents/outputs and actions described in the following were The documents/outputs and actions described in the following were
deemed relevant by the participants. deemed relevant by the participants.
5.2.1. Potential architecture actions and outputs 5.2.1. Potential architecture actions and outputs
o Develop and document a modern threat model o Develop and document a modern threat model
o Continue discussion of consolidation/centralisation issues o Continue discussion of consolidation/centralisation issues
skipping to change at page 14, line 5 skipping to change at page 15, line 36
workshop , June 2019. workshop , June 2019.
[POS] IAB, ., "Position Papers: DEDR Workshop", [POS] IAB, ., "Position Papers: DEDR Workshop",
https://www.iab.org/activities/workshops/dedr-workshop/ https://www.iab.org/activities/workshops/dedr-workshop/
position-papers/ , June 2019. position-papers/ , June 2019.
[Reid2019] [Reid2019]
Reid, J., "Where/Why has DNS gone wrong?", Position paper Reid, J., "Where/Why has DNS gone wrong?", Position paper
submitted for the IAB DEDR workshop , June 2019. 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>.
[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
<https://www.rfc-editor.org/info/rfc5218>. <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 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and
Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170,
May 2017, <https://www.rfc-editor.org/info/rfc8170>. May 2017, <https://www.rfc-editor.org/info/rfc8170>.
[Sethi2019] [Sethi2019]
Sethi, M. and T. Aura, "IoT Security and the role of Sethi, M. and T. Aura, "IoT Security and the role of
Manufacturers: A Story of Unrealistic Design Manufacturers: A Story of Unrealistic Design
Expectations", Position paper submitted for the IAB DEDR Expectations", Position paper submitted for the IAB DEDR
workshop , June 2019. workshop , June 2019.
skipping to change at page 15, line 44 skipping to change at page 17, line 36
o Soininen, Jonne o Soininen, Jonne
o Sullivan, Andrew o Sullivan, Andrew
o Trammell, Brian o Trammell, Brian
Appendix B. Acknowledgements Appendix B. Acknowledgements
The authors would like to thank the workshop participants, the The authors would like to thank the workshop participants, the
members of the IAB, and the participants in the architecture members of the IAB, and the participants in the architecture
discussion list for interesting discussions. The workshop organizers 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 would also like to thank Nokia for hosting the workshop in excellent
facilities in Kirkkonummi, Finland. facilities in Kirkkonummi, Finland.
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
Ted Hardie Ted Hardie
Google Google
Email: ted.ietf@gmail.com Email: ted.ietf@gmail.com
 End of changes. 33 change blocks. 
57 lines changed or deleted 153 lines changed or added

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