draft-iab-dedr-report-00.txt		draft-iab-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: September 11, 2020 Google		Expires: May 6, 2021 Google
	March 10, 2020		November 2, 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-iab-dedr-report-00		draft-iab-dedr-report-01
	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 September 11, 2020.		This Internet-Draft will expire on May 6, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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
	skipping to change at page 2, line 16		skipping to change at page 2, line 16
	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 . . . . . . . . . . . . . . . . . . . . . . . 7		4.2. Principles . . . . . . . . . . . . . . . . . . . . . . . 7
	4.3. Centralised deployment models . . . . . . . . . . . . . . 8		4.3. Centralised deployment models . . . . . . . . . . . . . . 8
	4.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 9		4.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.5. Future . . . . . . . . . . . . . . . . . . . . . . . . . 10		4.5. Future . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11		5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.1. Summary of discussions . . . . . . . . . . . . . . . . . 11		5.1. Summary of discussions . . . . . . . . . . . . . . . . . 11
	5.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 12		5.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.2.1. Potential architecture actions and outputs . . . . . 12		5.2.1. Potential architecture actions and outputs . . . . . 13
	5.2.2. Potential other actions . . . . . . . . . . . . . . . 13		5.2.2. Potential other actions . . . . . . . . . . . . . . . 13
	5.3. Other publications . . . . . . . . . . . . . . . . . . . 13		5.3. Other publications . . . . . . . . . . . . . . . . . . . 13
	5.4. Feedback . . . . . . . . . . . . . . . . . . . . . . . . 13		5.4. Feedback . . . . . . . . . . . . . . . . . . . . . . . . 13
	6. Informative References . . . . . . . . . . . . . . . . . . . 13		6. Informative References . . . . . . . . . . . . . . . . . . . 13
	Appendix A. Particant List . . . . . . . . . . . . . . . . . . . 16		Appendix A. Particant List . . . . . . . . . . . . . . . . . . . 17
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17		Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	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		The background for the workshop was that during the development and
	version. Comments and contributions are appreciated. We expect to		early elaboration phase for a number of protocols, there was a
	call for review of the -01 version.		presumption of specific deployment models. Actual deployments have,
			however, often run contrary to these early expectations when
	The background for the workshop was that a number of protocols have		economies of scale, Distributed Denial-of-Service (DDoS) attack
	presumed specific deployment models during the development or early		resilience, market consolidation, or other factors have come into
	elaboration of the protocol. Actual deployments have, however, often		play. These factors can result in the deployed reality being highly
	run contrary to these early expectations when economies of scale,		concentrated.
	DDoS 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,		This is a serious issue for the Internet, as concentrated,
	centralized deployment models present risks to user choice, privacy,		centralized deployment models present risks to user choice, privacy,
	and future protocol evolution.		and future protocol evolution.
	On occasion, the differences to expectations were almost immediate,		On occasion, the differences to expectations were almost immediate,
	but they also occur after a significant time has passed from the		but they also occur after a significant time has passed from the
	protocol's initial development.		protocol's initial development.
	Examples include:		Examples include:
	skipping to change at page 4, line 44		skipping to change at page 4, line 41
	centralisation. Can centralisation be avoided? How?		centralisation. Can centralisation be avoided? How?
	o Security. Are we addressing the right threats? What should we		o Security. Are we addressing the right threats? What should we
	prepare ourselves for?		prepare ourselves for?
	o Future. What can we do? Should we get better at predicting, or		o Future. What can we do? Should we get better at predicting, or
	should we do different things?		should we do different things?
	3. Position Papers		3. Position Papers
	The following position papers were submitted to the workshop:		The following position papers were submitted to the workshop (in
			alphabetical order):
	o Jari Arkko. "Changes in the Internet Threat Model" [Arkko2019]		o Jari Arkko. "Changes in the Internet Threat Model" [Arkko2019]
	o Vittorio Bertola. "How the Internet Was Won and Where It Got Us"		o Vittorio Bertola. "How the Internet Was Won and Where It Got Us"
	[Bertola2019]		[Bertola2019]
	o Carsten Bormann. "WiFi authentication: Some deployment		o Carsten Bormann. "WiFi authentication: Some deployment
	observations from eduroam" [Bormann2019]		observations from eduroam" [Bormann2019]
	o Stephane Bortzmeyer. "Encouraging better deployments"		o Stephane Bortzmeyer. "Encouraging better deployments"
	[Bortzmeyer2019]		[Bortzmeyer2019]
	skipping to change at page 6, line 13		skipping to change at page 6, line 13
	[Sethi2019]		[Sethi2019]
	o Andrew Sullivan. "Three kinds of concentration in open protocols"		o Andrew Sullivan. "Three kinds of concentration in open protocols"
	[Sullivan2019]		[Sullivan2019]
	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 certificate
	from BGP to NATs, from DNS resolvers to CDNs, and from IOT to instant		authorities for web connections (WebPKI) to DNS Security (DNSSEC),
			from Border Gateway Protocol (BGP) to Network Address Translators
			(NATs), from Domain Name System (DNS) resolvers to Content Data
			Networks (CDNs), and from Internet of Things (IoT) systems to instant
	messaging and social media applications.		messaging and social media applications.
	In many cases there was either a surprise in how technology was		In many cases there was either a surprise in how technology was
	deployed, lack of sufficient adoption, or the business models		deployed, lack of sufficient adoption, or the business models
	associated with chosen technologies were not in favor of broader		associated with chosen technologies were not in favor of broader
	interoperability.		interoperability.
	In general, the protocol designers cannot affect market forces but		In general, the protocol designers cannot affect market forces but
	must work within them. But it is possible to choose, for instance,		must work within them. But there are often competing technical
	whether to work to support the markets with standards that an		approaches or features that are tailored for a particular deployment
	established business clearly needs, or to enable competition and		pattern. In some cases it is possible to choose whether to support,
	disruption through more speculative new technology.		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.
	Themes on lessons learned include:		Lessons learned include:
	o Feedback from those who deploy often comes too late.		o Feedback from those who deploy often comes too late.
	o Building blocks get re-purposed in unexpected ways		o Building blocks get re-purposed in unexpected ways
	o User communities come in too late.		o User communities come in too late.
	o The web is getting more centralised. Counteracting this trend is		o The web is getting more centralised, and counteracting this trend
	difficult. Even when there's a clear goal, such as supporting de-		is difficult. It is not necessarily clear what technical path
	centralised market models, it is not necessarily clear what		leads to distributed markets and de-centralized architectures, for
	technical path leads to such goals. There are also many forces		instance.
	that make it easier to pursue centralised models, deployment is
	often easier in such a model, the technologists and regulators		o There are also many forces that make it easier to pursue
	find more easily which parties to talk to about the topic, and so		centralised models than other ones. For instance, deployment is
	on.		often easier in a centralised 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.
	o It is important but hard to determine how useful new protocols		o It is important but hard to determine how useful new protocols
	are.		are.
	o It is difficult for the IETF community to interact with others,		o It is difficult for the IETF community to interact with others,
	e.g., specific business sectors that need new technology (such as		e.g., specific business sectors that need new technology (such as
	aviation or healthcare) or regulators.		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 [RFC4271], is lacking,
	success in deploying significant improvements has been lacking, for		but there has been only limited success in deploying significant
	instance in the area of security.		improvements, for instance in the area of security.
	Another principle appears to be first mover advantage. Several		Another principle appears to be first mover advantage. Several
	equally interesting technologies have fared in very different ways,		equally interesting technologies have fared in very different ways,
	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 ([RFC4033]) is not. Is this because the earlier
	adoption of WebPKI, and the initially more complex interdependencies		commercial adoption of WebPKI, the more complex interdependencies
	between systems that wished to deploy DNSSEC.		between systems that wished to deploy DNSSEC, or some other reason?
	The definition of success in [RFC5218] appears to a part of the		The definition of success in [RFC5218] appears to a part of the
	problem. The only way to control deployments up front is to prevent		problem. The only way to control deployments up front is to prevent
	wild success, but wild successes are actually what we want. And it		wild success, but wild successes are actually what we want. And it
	seems very difficult to predict these successes anyway. The workshop		seems very difficult to predict these successes.
	also discussed the extent to which protocol work should be controlled
	by the IETF, or the IESG. It seems unproductive to attempt to		The workshop also discussed the extent to which protocol work even
	constrain deployment models, as one can only offer possibilities but		should be controlled by the IETF, or the IESG. It seems unproductive
	not force anyone to use a particular possibility.		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 same		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
	skipping to change at page 8, line 28		skipping to change at page 8, line 38
	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 group also discussed monocultures, and their negative effect on
	the Internet and its stability.		the Internet and its stability and resistance to various problems and
			attacks.
	Regulation may affect the Internet businesses as well. Regulation		Regulation may affect the Internet businesses as well. Regulation
	can exist in multiple forms, based on economic rationale (e.g.,		can exist in multiple forms, based on economic rationale (e.g.,
	competition law) or other factors. For instance, user privacy is a		competition law) or other factors. For instance, user privacy is a
	common regulatory topic.		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:		Some observations that were made:
	o When standardising new technology, the parties involved in the		o When standardising new technology, the parties involved in the
	effort may think they agree on what the goals are, but often in		effort may think they agree on what the goals are, but often in
	reality are surprised in the end. For instance, with DNS-over-		reality are surprised in the end. For instance, with DNS-over-
	HTTPS there were very different aspirations, some around		HTTPS (DoH, [RFC8484]) there were very different aspirations, some
	improvements in confidentiality of the queries, some around		around improvements in confidentiality of the queries, some around
	operational and latency improvements to DNS operations, and some		operational and latency improvements to DNS operations, and some
	about shifting business and deployment models. The full picture		about shifting business and deployment models. The full picture
	was not clear before the work was completed.		was not clear before the work was completed.
	o In DNS, UDP-based DDOS is practical reality, and only a handful of		o In DNS, DDoS is practical reality, and only a handful of providers
	providers can handle the traffic load in these attacks.		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 data in one place.		encryption, and not storing all of the data in one place.
	o Web tracking can be combatted by browsers choosing to avoid the		o Web tracking can be combatted by browsers choosing to avoid the
	techniques sensitive to tracking. Competition in the browser		techniques sensitive to tracking. Competition in the browser
	market may help drive some of these changes.		market may help drive some of these changes.
	o Open interfaces help guard against the bundling of services in one		o Open interfaces help guard against the bundling of services in one
	skipping to change at page 9, line 36		skipping to change at page 9, line 47
	o Commercial surveillance does not seem to be curbed by current		o Commercial surveillance does not seem to be curbed by current
	means. But there are still possibilities, such as stronger		means. But there are still possibilities, such as stronger
	regulation, data minimisation, or browsers acting on behalf of		regulation, data minimisation, or browsers acting on behalf of
	users. There are hopeful signs that at least some browsers are		users. There are hopeful signs that at least some browsers are
	becoming more 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
	curb the architectural trend of centralization. Another comment was		curb the architectural trend of centralization. Another comment was
	that discussing this in the abstract is not as useful as more		that discussing this in the abstract is not as useful as more
	concrete, practical actions. For instance, one might imagine		concrete, practical actions. For instance, one might imagine
	different DOH deployments with widely different implications for		different DoH deployments with widely different implications for
	privacy or tolerance of failures. Getting to the specifics of how a		privacy or tolerance of failures. Getting to the specifics of how a
	particular service can be made better is important.		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
	skipping to change at page 10, line 27		skipping to change at page 10, line 41
	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:
	o Documenting our experiences?		o Documenting our experiences?
	o Providing advice (to IETF, to others)		o Providing advice (to IETF or 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? The participants of course did not wish for this.
	o Work at the IETF?		o Work at the IETF?
	o Technical solutions/choices?		o Technical solutions/choices?
	The best way for the IETF to do things is through standards;		The best way for the IETF to do things is through standards;
	convincing people through other requests is difficult. The IETF		convincing people through other requests is difficult. The IETF
	needs to:		needs to:
	o Pick pieces that it is responsible for.		o Pick pieces that it is responsible for.
	skipping to change at page 11, line 6		skipping to change at page 11, line 20
	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		etc.) is one such group. Specific technology or business groups
	(such 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 Manufacturer Usage Descriptions
	management, particularly for devices that could be operational for		(MUDs, [RFC8520])). Another issue is management, particularly for
	decades. Given the diversity of IOT systems, it may also make more		devices that could be operational for decades. Given the diversity
	sense to build support systems for the broader solutions that		of IOT systems, it may also make more sense to build support systems
	specific solutions or specific protocols.		for the broader solutions that specific solutions or specific
			protocols.
	There are also many security issues. While some of them are trivial		There are also many security issues. While some of them are trivial
	(such as default passwords), one should also look forward and be		(such as default passwords), one should also look forward and be
	prepared to have solutions for, say, trust management for long time		prepared to have solutions for, say, trust management for long time
	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
	skipping to change at page 12, line 35		skipping to change at page 13, line 5
	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 the IETF to make an impact is through standards. The IETF should		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		focus on the parts that it is responsible for, and be available as an
	expert on other discussions.		expert on other discussions.
			5.2.1. Potential architecture actions and outputs
	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		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.
	o Document architectural principles, e.g., (re-)application of the		o Document architectural principles, e.g., (re-)application of the
	end-to-end principle		end-to-end principle.
	The first receiver of these thoughts is the IETF and protocol		The first receiver of these thoughts is the IETF and protocol
	community, but combined with some evangelising & validation elsewhere		community, but combined with some evangelising & validation
			elsewhere.
	5.2.2. Potential other actions		5.2.2. Potential other actions
	o Pursue specific IETF topics, e.g., work on taking into account		o Pursue specific IETF topics, e.g., work on taking into account
	reputation systems in IETF work, working to ensuring certificate		reputation systems in IETF work, working to ensuring certificate
	scoping can be appropriately limited, building end-to-end		scoping can be appropriately limited, building end-to-end
	encryption tools for applications, etc.		encryption tools for applications, etc.
	o General deployment experiences/advice, and documenting deployment		o General deployment experiences/advice, and documenting deployment
	assumptions possibly already in WG charters		assumptions possibly already in WG charters
	skipping to change at page 15, line 41		skipping to change at page 16, line 14
	[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		[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Text on Security Considerations", BCP 72, RFC 3552,		Text on Security Considerations", BCP 72, RFC 3552,
	DOI 10.17487/RFC3552, July 2003,		DOI 10.17487/RFC3552, July 2003,
	<https://www.rfc-editor.org/info/rfc3552>.		<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		[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		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
	Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May		Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
	2014, <https://www.rfc-editor.org/info/rfc7258>.		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>.
			[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]		[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.
	[Sullivan2019]		[Sullivan2019]
	Sullivan, A., "Three kinds of concentration in open		Sullivan, A., "Three kinds of concentration in open
	protocols", Position paper submitted for the IAB DEDR		protocols", Position paper submitted for the IAB DEDR
	workshop , June 2019.		workshop , June 2019.
End of changes. 30 change blocks.
	67 lines changed or deleted		98 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/