File: rfc8980.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2018 lines) | stat: -rw-r--r-- 101,983 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8980: Report from the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol Development</title>
<meta content="Jari Arkko" name="author">
<meta content="Ted Hardie" name="author">
<meta content="
       The Design Expectations vs. Deployment Reality in Protocol Development Workshop was convened by the Internet Architecture Board (IAB) in June 2019. This report summarizes the workshop's significant points of discussion and identifies topics that may warrant further consideration. 
       Note that this document is a report on the proceedings of the 
workshop.  The views and positions documented in this report are 
those of the workshop participants and do not necessarily reflect IAB 
views and positions. 
    " name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="8980" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.5.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc8980.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8980" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-iab-dedr-report-01" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8980</td>
<td class="center">DEDR Report</td>
<td class="right">February 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Arkko &amp; Hardie</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Architecture Board (IAB)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8980" class="eref">8980</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-02" class="published">February 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">J. Arkko</div>
</div>
<div class="author">
      <div class="author-name">T. Hardie</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8980</h1>
<h1 id="title">Report from the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol Development</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">The Design Expectations vs. Deployment Reality in Protocol Development Workshop was convened by the Internet Architecture Board (IAB) in June 2019. This report summarizes the workshop's significant points of discussion and identifies topics that may warrant further consideration.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">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.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Architecture Board
            (IAB) and represents information that the IAB has deemed valuable
            to provide for permanent record.  It represents the consensus of the Internet
            Architecture Board (IAB).  Documents approved for publication
            by the IAB are not candidates for any level of Internet Standard; see
            Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8980">https://www.rfc-editor.org/info/rfc8980</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-workshop-agenda" class="xref">Workshop Agenda</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-position-papers" class="xref">Position Papers</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-discussions" class="xref">Discussions</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-past-experiences" class="xref">Past Experiences</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-principles" class="xref">Principles</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-centralized-deployment-mode" class="xref">Centralized Deployment Models</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-security" class="xref">Security</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-future" class="xref">Future</a><a href="#section-toc.1-1.4.2.5.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-conclusions" class="xref">Conclusions</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-summary-of-discussions" class="xref">Summary of Discussions</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-actions" class="xref">Actions</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.2.2.1">
                    <p id="section-toc.1-1.5.2.2.2.1.1"><a href="#section-5.2.1" class="xref">5.2.1</a>.  <a href="#name-potential-architecture-acti" class="xref">Potential Architecture Actions and Outputs</a><a href="#section-toc.1-1.5.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.2.2.2">
                    <p id="section-toc.1-1.5.2.2.2.2.1"><a href="#section-5.2.2" class="xref">5.2.2</a>.  <a href="#name-other-potential-actions" class="xref">Other Potential Actions</a><a href="#section-toc.1-1.5.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-other-publications" class="xref">Other Publications</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-feedback" class="xref">Feedback</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-participant-list" class="xref">Participant List</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-iab-members-at-the-time-of-" class="xref">IAB Members at the Time of Approval</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.d" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">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).<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">The Design Expectations vs. Deployment Reality in Protocol Development  Workshop was convened by the IAB in June 2019. This report summarizes the workshop's significant points of discussion and identifies topics that may warrant further consideration.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">The background for the workshop was that during the development and early elaboration phase for a number of protocols, there was a presumption of specific deployment models. Actual deployments have, however, often run contrary to these early expectations when economies of scale, Distributed Denial-of-Service (DDoS) attack resilience, market consolidation, or other factors have come into play. These factors can result in the deployed reality being highly concentrated.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">This is a serious issue for the Internet, as concentrated, centralized deployment models present risks to user choice, privacy, and future protocol evolution.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">On occasion, the differences from the original expectations were almost immediate, but they also occur after significant time has passed since the protocol's initial development.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">Some examples are given below.<a href="#section-1-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-7.1">Email standards, which presumed many providers running in a largely uncoordinated fashion but have seen both significant market consolidation and a need for coordination to defend against spam and other attacks. The coordination and centralized defense mechanisms scale better for large entities; these have fueled additional consolidation.<a href="#section-1-7.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-7.2">The Domain Name System (DNS), which presumed deep hierarchies but has often been deployed in large, flat zones, leading to the nameservers for those zones becoming critical infrastructure. Future developments in DNS may see concentration through the use of globally available common resolver services, which evolve rapidly and can offer better security. Paradoxically, concentration of these queries into a few services creates new security and privacy concerns.<a href="#section-1-7.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-7.3">The Web, which is built on a fundamentally decentralized design but is now often delivered with the aid of Content Delivery Networks (CDNs). Their services provide scaling, distribution, and prevention of denial of service in ways that new entrants and smaller systems operators would find difficult to replicate. While truly small services and truly large services may each operate using only their own infrastructure, many others are left with the only practical choice being the use of a globally available commercial service.<a href="#section-1-7.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-8">Similar developments may happen with future technologies and services. For instance, the growing use of Machine Learning technology presents challenges for distributing effective implementation of a service throughout a pool of many different providers.<a href="#section-1-8" class="pilcrow">¶</a></p>
<p id="section-1-9">In <span>[<a href="#RFC5218" class="xref">RFC5218</a>]</span>, the IAB tackled what made for a successful protocol. In <span>[<a href="#RFC8170" class="xref">RFC8170</a>]</span>, the IAB described how to handle protocol transitions. The purpose of this workshop was to explore cases where the initial system design assumptions turned out to be wrong, looking for patterns in what caused those assumptions to fail (e.g., concentration due to DDoS resilience) and in how those failures impact the security, privacy, and manageability of the resulting deployments.<a href="#section-1-9" class="pilcrow">¶</a></p>
<p id="section-1-10">While the eventual goals might include proposing common remediations for specific cases of confounded protocol expectations, this workshop and thus this report focused on identifying patterns.<a href="#section-1-10" class="pilcrow">¶</a></p>
<p id="section-1-11">The workshop call for papers invited the submission of position papers that would:<a href="#section-1-11" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-12.1">Describe specific cases where systems assumptions during protocol development were confounded by later deployment conditions.<a href="#section-1-12.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-12.2">Survey a set of cases to identify common factors in these confounded expectations.<a href="#section-1-12.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-12.3">Explore remediations that foster user privacy, security, and provider diversity in the face of these changes.<a href="#section-1-12.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-13">A total of 21 position papers were received and are listed in <a href="#positionpapers" class="xref">Section 3</a>. On site or remote were 30 participants; they are listed in <a href="#participants" class="xref">Appendix A</a>.<a href="#section-1-13" class="pilcrow">¶</a></p>
</section>
</div>
<div id="workshop-agenda">
<section id="section-2">
      <h2 id="name-workshop-agenda">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-workshop-agenda" class="section-name selfRef">Workshop Agenda</a>
      </h2>
<p id="section-2-1">After opening and discussion of goals for the workshop, the discussion focused on five main topics:<a href="#section-2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-2.1">Past experiences. What have we learned?<a href="#section-2-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-2.2">Principles. What forces apply to deployment? What principles to take into account in design?<a href="#section-2-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-2.3">Centralized deployment models. The good and the bad of centralization. Can centralization be avoided? How?<a href="#section-2-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-2.4">Security. Are we addressing the right threats? What should we prepare ourselves for?<a href="#section-2-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-2.5">Future. What can we do? Should we get better at predicting, or should we do different things?<a href="#section-2-2.5" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="positionpapers">
<section id="section-3">
      <h2 id="name-position-papers">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-position-papers" class="section-name selfRef">Position Papers</a>
      </h2>
<p id="section-3-1">The following position papers were submitted to the workshop by the
      following people (listed in alphabetical order):<a href="#section-3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-2.1">
          <p id="section-3-2.1.1"><span class="contact-name">Jari Arkko</span>. "Changes in the Internet Threat Model" <span>[<a href="#Arkko2019" class="xref">Arkko2019</a>]</span><a href="#section-3-2.1.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.2">
          <p id="section-3-2.2.1"><span class="contact-name">Vittorio Bertola</span>. "How the Internet Was Won and Where It Got Us" <span>[<a href="#Bertola2019" class="xref">Bertola2019</a>]</span><a href="#section-3-2.2.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.3">
          <p id="section-3-2.3.1"><span class="contact-name">Carsten Bormann</span> and <span class="contact-name">Jan-Frederik Rieckers</span>. "WiFi authentication: Some deployment observations from eduroam" <span>[<a href="#Bormann2019" class="xref">Bormann2019</a>]</span><a href="#section-3-2.3.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.4">
          <p id="section-3-2.4.1"><span class="contact-name">Stéphane Bortzmeyer</span>. "Encouraging better deployments" <span>[<a href="#Bortzmeyer2019" class="xref">Bortzmeyer2019</a>]</span><a href="#section-3-2.4.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.5">
          <p id="section-3-2.5.1"><span class="contact-name">Brian Carpenter</span> and <span class="contact-name">Bing Liu</span>.  "Limited Domains and Internet Protocols" <span>[<a href="#Carpenter2019" class="xref">Carpenter2019</a>]</span><a href="#section-3-2.5.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.6">
          <p id="section-3-2.6.1"><span class="contact-name">Alissa Cooper</span>. "Don't Forget the Access Network" <span>[<a href="#Cooper2019" class="xref">Cooper2019</a>]</span><a href="#section-3-2.6.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.7">
          <p id="section-3-2.7.1"><span class="contact-name">Stephen Farrell</span>. "We're gonna need a bigger threat model" <span>[<a href="#Farrell2019" class="xref">Farrell2019</a>]</span><a href="#section-3-2.7.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.8">
          <p id="section-3-2.8.1"><span class="contact-name">Phillip Hallam-Baker</span>. "The Devil is in the Deployment" <span>[<a href="#HallamBaker2019" class="xref">HallamBaker2019</a>]</span><a href="#section-3-2.8.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.9">
          <p id="section-3-2.9.1"><span class="contact-name">Ted Hardie</span>. "Instant Messaging and Presence: A Cautionary Tale" <span>[<a href="#Hardie2019" class="xref">Hardie2019</a>]</span><a href="#section-3-2.9.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.10">
          <p id="section-3-2.10.1"><span class="contact-name">Paul Hoffman</span>. "Realities in DNSSEC Deployment" <span>[<a href="#Hoffman2019" class="xref">Hoffman2019</a>]</span><a href="#section-3-2.10.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.11">
          <p id="section-3-2.11.1"><span class="contact-name">Christian Huitema</span>. "Concentration is a business model" <span>[<a href="#Huitema2019" class="xref">Huitema2019</a>]</span><a href="#section-3-2.11.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.12">
          <p id="section-3-2.12.1"><span class="contact-name">Geoff Huston</span>. "The Border Gateway Protocol, 25 years on" <span>[<a href="#Huston2019" class="xref">Huston2019</a>]</span><a href="#section-3-2.12.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.13">
          <p id="section-3-2.13.1"><span class="contact-name">Dirk Kutscher</span>. "Great Expectations: Protocol Design and Socioeconomic Realities" <span>[<a href="#Kutscher2019" class="xref">Kutscher2019</a>]</span><a href="#section-3-2.13.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.14">
          <p id="section-3-2.14.1"><span class="contact-name">Julien Maisonneuve</span>. "DNS, side effects and concentration" <span>[<a href="#Maisonneuve2019" class="xref">Maisonneuve2019</a>]</span><a href="#section-3-2.14.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.15">
          <p id="section-3-2.15.1"><span class="contact-name">John Mattsson</span>. "Consolidation, Privacy, Jurisdiction, and the Health of the Internet" <span>[<a href="#Mattsson2019" class="xref">Mattsson2019</a>]</span><a href="#section-3-2.15.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.16">
          <p id="section-3-2.16.1"><span class="contact-name">Moritz Müller</span>. "Rolling Forward: An Outlook on Future Root Rollovers" <span>[<a href="#Muller2019" class="xref">Muller2019</a>]</span><a href="#section-3-2.16.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.17">
          <p id="section-3-2.17.1"><span class="contact-name">Jörg Ott</span>.  "Protocol Design Assumptions and PEPs" <span>[<a href="#Ott2019" class="xref">Ott2019</a>]</span><a href="#section-3-2.17.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.18">
          <p id="section-3-2.18.1"><span class="contact-name">Lucas Pardue</span>. "Some challenges with IP multicast deployment" <span>[<a href="#Pardue2019" class="xref">Pardue2019</a>]</span><a href="#section-3-2.18.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.19">
          <p id="section-3-2.19.1"><span class="contact-name">Jim Reid</span>. "Where/Why has DNS gone wrong?" <span>[<a href="#Reid2019" class="xref">Reid2019</a>]</span><a href="#section-3-2.19.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.20">
          <p id="section-3-2.20.1"><span class="contact-name">Mohit Sethi</span> and <span class="contact-name">Tuomas Aura</span>. "IoT Security and the role of Manufacturers: A Story of Unrealistic Design Expectations" <span>[<a href="#Sethi2019" class="xref">Sethi2019</a>]</span><a href="#section-3-2.20.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.21">
          <p id="section-3-2.21.1"><span class="contact-name">Andrew Sullivan</span>. "Three kinds of concentration in open protocols" <span>[<a href="#Sullivan2019" class="xref">Sullivan2019</a>]</span><a href="#section-3-2.21.1" class="pilcrow">¶</a></p>
</li>
      </ul>
<p id="section-3-3">These papers are available from the IAB website <span>[<a href="#CFP" class="xref">CFP</a>]</span> <span>[<a href="#POS" class="xref">POS</a>]</span>.<a href="#section-3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="discussions">
<section id="section-4">
      <h2 id="name-discussions">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-discussions" class="section-name selfRef">Discussions</a>
      </h2>
<div id="past-experiences">
<section id="section-4.1">
        <h3 id="name-past-experiences">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-past-experiences" class="section-name selfRef">Past Experiences</a>
        </h3>
<p id="section-4.1-1">The workshop investigated deployment cases from certificate authorities for web connections (WebPKI) to DNS Security (DNSSEC), from the Border Gateway Protocol (BGP) to Network Address Translators (NATs), from DNS resolvers to CDNs, and from Internet of Things (IoT) systems to instant messaging and social media applications.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">In many cases, (1) there was a surprise in how technology was deployed,
(2) there was a lack of sufficient adoption, or (3) the business models associated with chosen technologies were not in favor of broader interoperability.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">In general, the protocol designers cannot affect market forces but must work within them. But there are often competing technical approaches or features that are tailored for a particular deployment pattern. In some cases, it is possible to choose whether to support, for instance, a clear need for an established business, a feature designed to support collaboration among smaller players, or some kind of disruption through a more speculative new feature or technology.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">Lessons learned include the following:<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.1-5.1">Feedback from those who deploy often comes too late.<a href="#section-4.1-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-5.2">Building blocks get repurposed in unexpected ways.<a href="#section-4.1-5.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-5.3">User communities come in too late.<a href="#section-4.1-5.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-5.4">The Web is getting more centralized, and counteracting this trend is difficult. It is not necessarily clear what technical path leads to distributed markets and decentralized architectures, for instance.<a href="#section-4.1-5.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-5.5">There are also many forces that make it easier to pursue centralized models than other models. For instance, deployment is often easier in a centralized model. And various business and regulatory processes work best within a small, well-defined set of entities that can interact with each other. This can lead to, for instance, regulators preferring a situation with a small number of entities that they can talk to, rather than a diverse set of providers.<a href="#section-4.1-5.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-5.6">It is important but hard to determine how useful new protocols are.<a href="#section-4.1-5.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-5.7">It is difficult for the IETF community to interact with other communities, e.g., specific business sectors that need new technology (such as aviation or healthcare) or regulators.<a href="#section-4.1-5.7" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="principles">
<section id="section-4.2">
        <h3 id="name-principles">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-principles" class="section-name selfRef">Principles</a>
        </h3>
<p id="section-4.2-1">Several underlying principles can be observed in the example cases that were discussed. Deployment failures tend to be associated with cases where interdependencies make progress difficult and there's no major advantage for early deployment. Despite persistent problems in the currently used technology, it becomes difficult for the ecosystem to switch to better technology. For instance, there are a number of areas where the Internet routing protocol BGP <span>[<a href="#RFC4271" class="xref">RFC4271</a>]</span> is lacking, but there has been only limited success in deploying significant improvements -- for instance, in the area of security.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">Another principle appears to be first-mover advantage. Several equally interesting technologies have fared in very different ways, depending on whether there was an earlier system that provided most of the benefits of the new system. Again, despite potential problems in an already-deployed technology, it becomes difficult to deploy improvements due to a lack of immediate incentives and due to the competing and already-deployed alternative that is proceeding forward in the ecosystem. For instance, WebPKI is very widely deployed and used, but DNSSEC <span>[<a href="#RFC4033" class="xref">RFC4033</a>]</span> is not. Is this because of the earlier commercial adoption of WebPKI, the more complex interdependencies between systems that wished to deploy DNSSEC, or some other reason?<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<p id="section-4.2-3">The definition of "success" in <span>[<a href="#RFC5218" class="xref">RFC5218</a>]</span> appears to be part of the problem. The only way to control deployments up front is to prevent wild success, but wild successes are actually what we want. And it seems very difficult to predict these successes.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<p id="section-4.2-4">The workshop also discussed the extent to which protocol work even should be controlled by the IETF, or the IESG. It seems unproductive to attempt to constrain deployment models, as one can only offer possibilities but not force anyone to use a particular possibility.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
<p id="section-4.2-5">The workshop also discussed different types of deployment patterns on the Internet:<a href="#section-4.2-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.2-6.1">Delivering functionality over the Internet as a web service. The Internet is an open and standardized system, but the service on top may be closed, essentially running two components of the same service provider's software against each other over the browser and Internet infrastructure. Several large application systems have grown in the Internet in this manner, encompassing large amounts of functionality and a large fraction of Internet users. This makes it easier for web applications to grow by themselves without cross-fertilization or interoperability.<a href="#section-4.2-6.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-6.2">Delivering concentrated network services that offer the standard capabilities of the Internet. Examples in this category include the provisioning of some mail services, DNS resolution, and so on.<a href="#section-4.2-6.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.2-7">The second case is more interesting for an Internet architecture discussion. There can, however, be different underlying situations even in that case. The service may be simply a concentrated way to provide a commodity service. The market should find a natural equilibrium for such situations. This may be fine, particularly where the service does not provide any new underlying advantage to whoever is providing it (in the form of user data that can be commercialized, for instance, or as training data for an important Machine Learning service).<a href="#section-4.2-7" class="pilcrow">¶</a></p>
<p id="section-4.2-8">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.<a href="#section-4.2-8" class="pilcrow">¶</a></p>
<p id="section-4.2-9">The group also discussed monocultures, and their negative effect on the Internet and its stability and resistance to various problems and attacks.<a href="#section-4.2-9" class="pilcrow">¶</a></p>
<p id="section-4.2-10">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.<a href="#section-4.2-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="centralized-deployment-models">
<section id="section-4.3">
        <h3 id="name-centralized-deployment-mode">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-centralized-deployment-mode" class="section-name selfRef">Centralized Deployment Models</a>
        </h3>
<p id="section-4.3-1">Many of the participants have struggled with these trends and their effect on desirable characteristics of Internet systems, such as distributed, end-to-end architecture or privacy. Yet, there are many business and technical drivers causing the Internet architecture to become further and further centralized.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">Some observations that were made:<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.3-3.1">When standardizing new technology, the parties involved in the effort may think they agree on what the goals are but in reality are often surprised in the end. For instance, with DNS (queries) over HTTPS (DoH) <span>[<a href="#RFC8484" class="xref">RFC8484</a>]</span>, 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.<a href="#section-4.3-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-3.2">In DNS, DDoS is a practical reality, and only a handful of providers can handle the traffic load in these attacks.<a href="#section-4.3-3.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.3-4">The hopeful side of this issue is that there are some potential answers:<a href="#section-4.3-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.3-5.1">DDoS defenses do not have to come through large entities, as layered defenses and federation also help similarly.<a href="#section-4.3-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-5.2">Surveillance state data capture can be fought with data object encryption and by not storing all of the data in one place.<a href="#section-4.3-5.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-5.3">Web tracking can be combatted by browsers choosing to avoid techniques that are sensitive to tracking. Competition in the browser market may help drive some of these changes.<a href="#section-4.3-5.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-5.4">Open interfaces help guard against the bundling of services in one large entity; as long as there are open, well-defined interfaces to specific functions, these functions can also be performed by other parties.<a href="#section-4.3-5.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-5.5">Commercial surveillance does not seem to be curbed by current means. But there are still possibilities, such as stronger regulation, data minimization, or browsers acting on behalf of users. There are hopeful signs that at least some browsers are becoming more aggressive in this regard. But more is needed.<a href="#section-4.3-5.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.3-6">One comment made in the workshop was that the Internet community needs to curb the architectural trend of centralization. Another comment was that discussing this in the abstract is not as useful as more concrete, practical actions. For instance, one might imagine different DoH deployments with widely different implications for privacy or tolerance of failures.  Getting to the specifics of how a particular service can be made better is important.<a href="#section-4.3-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security">
<section id="section-4.4">
        <h3 id="name-security">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-security" class="section-name selfRef">Security</a>
        </h3>
<p id="section-4.4-1">This part of the discussion focused on whether in the current state of the Internet we actually need a new threat model.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">Many of the security concerns regarding communications have been addressed in the past few years, with increasing encryption. However, issues with trusting endpoints on the other side of the communication have not been addressed and are becoming more urgent with the advent of centralized service architectures.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<p id="section-4.4-3">Further effort may be needed to minimize centralization, as having only a few places to tap increases the likelihood of surveillance.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
<p id="section-4.4-4">There may be a need to update <span>[<a href="#RFC3552" class="xref">RFC3552</a>]</span> and <span>[<a href="#RFC7258" class="xref">RFC7258</a>]</span>.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
<p id="section-4.4-5">The participants in the workshop agreed that a new threat model is needed and that non-communications-security issues need to be handled.<a href="#section-4.4-5" class="pilcrow">¶</a></p>
<p id="section-4.4-6">Other security discussions were focused on IoT systems, algorithm agility issues, experiences from difficult security upgrades such as DNSSEC key rollovers, and routing security.<a href="#section-4.4-6" class="pilcrow">¶</a></p>
<p id="section-4.4-7">The participants cautioned against relying too much on device manufacturers for security, and being clear on security models and assumptions. Security is often poorly understood, and the assumptions about who the system defends against and who it does not are not clear.<a href="#section-4.4-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="future">
<section id="section-4.5">
        <h3 id="name-future">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-future" class="section-name selfRef">Future</a>
        </h3>
<p id="section-4.5-1">The workshop turned into a discussion of what actions we can take:<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.5-2.1">Documenting our experiences?<a href="#section-4.5-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.5-2.2">Providing advice (to the IETF or to others)?<a href="#section-4.5-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.5-2.3">Waiting for the catastrophe that will make people agree to changes? The participants of course did not wish for this.<a href="#section-4.5-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.5-2.4">Work at the IETF?<a href="#section-4.5-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.5-2.5">Technical solutions/choices?<a href="#section-4.5-2.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.5-3">The best way for the IETF to do things is through standards; convincing people through other requests is difficult. The IETF needs to:<a href="#section-4.5-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.5-4.1">Pick pieces that it is responsible for.<a href="#section-4.5-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.5-4.2">Be reactive for the rest, be available as an expert in other discussions, provide Internet technology knowledge where needed, etc.<a href="#section-4.5-4.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.5-5">One key question is what other parties need to be involved in any discussions. Platform developers (mobile platforms, cloud systems, etc.) are one such group. Specific technology or business groups (such as email provider or certificate authority forums) are another.<a href="#section-4.5-5" class="pilcrow">¶</a></p>
<p id="section-4.5-6">The workshop also discussed specific technology issues -- for instance, around IoT systems. One observation in those systems is that there is no single model for applications; they vary. There are a lot of different constraints in different systems and different control points. What is perhaps most needed today is user control and transparency (for instance, via Manufacturer Usage Descriptions (MUDs) <span>[<a href="#RFC8520" class="xref">RFC8520</a>]</span>). Another issue is management, particularly for devices that could be operational for decades. Given the diversity of IoT systems, it may also make more sense to build support systems for broader solutions than for specific solutions or specific protocols.<a href="#section-4.5-6" class="pilcrow">¶</a></p>
<p id="section-4.5-7">There are also many security issues. While some of them are trivial (such as default passwords), one should also look forward and be prepared to have solutions for, say, trust management for long time scales, or be able to provide data minimization to cut down on the potential for leakages. And the difficulty of establishing peer-to-peer security strengthens the need for a central point, which may also be harmful from a long-term privacy perspective.<a href="#section-4.5-7" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="conclusions">
<section id="section-5">
      <h2 id="name-conclusions">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-conclusions" class="section-name selfRef">Conclusions</a>
      </h2>
<div id="summary-of-discussions">
<section id="section-5.1">
        <h3 id="name-summary-of-discussions">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-summary-of-discussions" class="section-name selfRef">Summary of Discussions</a>
        </h3>
<p id="section-5.1-1">The workshop met in the sunny Finnish countryside and made the unsurprising observation that technologies sometimes get deployed in surprising ways. But the consequences of deployment choices can have an impact on security, privacy, centralized vs. distributed models, competition, and surveillance. As the IETF community cares deeply about these aspects, it is worthwhile to spend time on the analysis of these choices.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">The prime factor driving deployments is perceived needs; expecting people to recognize obvious virtues and therefore deploy them is not likely to work.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<p id="section-5.1-3">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.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
<p id="section-5.1-4">While the workshop discussed actions and advice, there is a critical question of who these are targeted towards. There is a need to construct a map of what parties need to perform what actions.<a href="#section-5.1-4" class="pilcrow">¶</a></p>
<p id="section-5.1-5">The workshop also made some technical observations. One issue is that the workshop identified a set of hard issues that affect deployment and for which we have no good solutions. These issues include, for instance, dealing with DDoS attacks and how to handle spam. Similarly, a lack of good solutions for micropayments is one factor behind a lot of the Internet economy being based on advertisements.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
<p id="section-5.1-6">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.<a href="#section-5.1-6" class="pilcrow">¶</a></p>
<p id="section-5.1-7">It was also noted that interoperability continues to be important, and we need to explore what new interfaces need standardization -- this will enable different deployment models and competition. The prime factor driving deployments is actual needs; we cannot force anything on others but can provide solutions for those that need them. Needs and actions may fall to different parties.<a href="#section-5.1-7" class="pilcrow">¶</a></p>
<p id="section-5.1-8">The workshop also considered the balancing of user non-involvement and transparency, as well as choice, relevant threats such as communicating with malicious endpoints, the role and willingness of browsers in increasing the ability to defend users' privacy, and concerns around centralized control or data storage points.<a href="#section-5.1-8" class="pilcrow">¶</a></p>
<p id="section-5.1-9">The workshop also discussed specific issues around routing, DoS attacks, IoT systems, the role of device manufacturers, the DNS, and regulatory reactions and their possible consequences.<a href="#section-5.1-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="actions">
<section id="section-5.2">
        <h3 id="name-actions">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-actions" class="section-name selfRef">Actions</a>
        </h3>
<p id="section-5.2-1">The prime conclusion from the workshop was that the topics we discussed were not completed in the workshop. Much more work is needed. The best way for the IETF to make an impact is through standards. The IETF should focus on the parts that it is responsible for and be available as an expert on other discussions.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<div id="potential-architecture-actions-and-outputs">
<section id="section-5.2.1">
          <h4 id="name-potential-architecture-acti">
<a href="#section-5.2.1" class="section-number selfRef">5.2.1. </a><a href="#name-potential-architecture-acti" class="section-name selfRef">Potential Architecture Actions and Outputs</a>
          </h4>
<p id="section-5.2.1-1">The documents/outputs and actions described in the following items were deemed relevant by the participants.<a href="#section-5.2.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.2.1-2.1">Develop and document a modern threat model.<a href="#section-5.2.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.2.1-2.2">Continue discussion of consolidation/centralization issues.<a href="#section-5.2.1-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.2.1-2.3">Document architectural principles, e.g., (re)application of the end-to-end principle.<a href="#section-5.2.1-2.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-5.2.1-3">The first receiver of these thoughts is the IETF and protocol community, but combined with some evangelizing and validation elsewhere.<a href="#section-5.2.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="potential-other-actions">
<section id="section-5.2.2">
          <h4 id="name-other-potential-actions">
<a href="#section-5.2.2" class="section-number selfRef">5.2.2. </a><a href="#name-other-potential-actions" class="section-name selfRef">Other Potential Actions</a>
          </h4>
<ul class="normal">
<li class="normal" id="section-5.2.2-1.1">Pursuit of specific IETF topics, e.g., working on taking into account reputation systems in IETF work, working to ensure that certificate scoping can be appropriately limited, building end-to-end encryption tools for applications, etc.<a href="#section-5.2.2-1.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.2.2-1.2">General deployment experiences/advice, and documenting deployment assumptions possibly already in WG charters.<a href="#section-5.2.2-1.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.2.2-1.3">A report will be produced from the workshop (this RFC).<a href="#section-5.2.2-1.3" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
</section>
</div>
<div id="other-publications">
<section id="section-5.3">
        <h3 id="name-other-publications">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-other-publications" class="section-name selfRef">Other Publications</a>
        </h3>
<p id="section-5.3-1">The workshop results have also been reported at <span>[<a href="#ISPColumn" class="xref">ISPColumn</a>]</span> by <span class="contact-name">Geoff Huston</span>.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="feedback">
<section id="section-5.4">
        <h3 id="name-feedback">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-feedback" class="section-name selfRef">Feedback</a>
        </h3>
<p id="section-5.4-1">Feedback regarding the workshop is appreciated and can be sent to the program committee, the IAB, or the architecture-discuss list.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec-cons">
<section id="section-6">
      <h2 id="name-security-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-6-1">Proposals discussed at the workshop would have significantly different security impacts, and each workshop paper should be read for its own security considerations.<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-7">
      <h2 id="name-informative-references">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
      </h2>
<dl class="references">
<dt id="Arkko2019">[Arkko2019]</dt>
      <dd>
<span class="refAuthor">Arkko, J.</span>, <span class="refTitle">"Changes in the Internet Threat Model"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="Bertola2019">[Bertola2019]</dt>
      <dd>
<span class="refAuthor">Bertola, V.</span>, <span class="refTitle">"How the Internet Was Won and Where It Got Us"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="Bormann2019">[Bormann2019]</dt>
      <dd>
<span class="refAuthor">Bormann, C.</span><span class="refAuthor"> and J. Rieckers</span>, <span class="refTitle">"WiFi authentication: Some deployment observations from eduroam"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="Bortzmeyer2019">[Bortzmeyer2019]</dt>
      <dd>
<span class="refAuthor">Bortzmeyer, S.</span>, <span class="refTitle">"Encouraging better deployments"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="Carpenter2019">[Carpenter2019]</dt>
      <dd>
<span class="refAuthor">Carpenter, B.</span><span class="refAuthor"> and B. Liu</span>, <span class="refTitle">"Limited Domains and Internet Protocols"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="CFP">[CFP]</dt>
      <dd>
<span class="refAuthor">IAB</span>, <span class="refTitle">"Design Expectations vs. Deployment Reality in Protocol Development Workshop 2019"</span>, <time datetime="2019-06" class="refDate">June 2019</time>, <span>&lt;<a href="https://www.iab.org/activities/workshops/dedr-workshop/">https://www.iab.org/activities/workshops/dedr-workshop/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Cooper2019">[Cooper2019]</dt>
      <dd>
<span class="refAuthor">Cooper, A.</span>, <span class="refTitle">"Don't Forget the Access Network"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="Farrell2019">[Farrell2019]</dt>
      <dd>
<span class="refAuthor">Farrell, S.</span>, <span class="refTitle">"We're gonna need a bigger threat model"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="HallamBaker2019">[HallamBaker2019]</dt>
      <dd>
<span class="refAuthor">Hallam-Baker, P.</span>, <span class="refTitle">"The Devil is in the Deployment"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="Hardie2019">[Hardie2019]</dt>
      <dd>
<span class="refAuthor">Hardie, T.</span>, <span class="refTitle">"Instant Messaging and Presence: A Cautionary Tale"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="Hoffman2019">[Hoffman2019]</dt>
      <dd>
<span class="refAuthor">Hoffman, P.</span>, <span class="refTitle">"Realities in DNSSEC Deployment"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="Huitema2019">[Huitema2019]</dt>
      <dd>
<span class="refAuthor">Huitema, C.</span>, <span class="refTitle">"Concentration is a business model"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="Huston2019">[Huston2019]</dt>
      <dd>
<span class="refAuthor">Huston, G.</span>, <span class="refTitle">"The Border Gateway Protocol, 25 years on"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="ISPColumn">[ISPColumn]</dt>
      <dd>
<span class="refAuthor">Huston, G.</span>, <span class="refTitle">"Network Protocols and their Use"</span>, <time datetime="2019-06" class="refDate">June 2019</time>, <span>&lt;<a href="https://www.potaroo.net/ispcol/2019-06/dedr.html">https://www.potaroo.net/ispcol/2019-06/dedr.html</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Kutscher2019">[Kutscher2019]</dt>
      <dd>
<span class="refAuthor">Kutscher, D.</span>, <span class="refTitle">"Great Expectations: Protocol Design and Socioeconomic Realities"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="Maisonneuve2019">[Maisonneuve2019]</dt>
      <dd>
<span class="refAuthor">Maisonneuve, J.</span>, <span class="refTitle">"DNS, side effects and concentration"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="Mattsson2019">[Mattsson2019]</dt>
      <dd>
<span class="refAuthor">Mattsson, J.</span>, <span class="refTitle">"Consolidation, Privacy, Jurisdiction, and the Health of the Internet"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="Muller2019">[Muller2019]</dt>
      <dd>
<span class="refAuthor">Müller, M.</span>, <span class="refTitle">"Rolling Forward: An Outlook on Future Root Rollovers"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="Ott2019">[Ott2019]</dt>
      <dd>
<span class="refAuthor">Ott, J.</span>, <span class="refTitle">"Protocol Design Assumptions and PEPs"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="Pardue2019">[Pardue2019]</dt>
      <dd>
<span class="refAuthor">Pardue, L.</span>, <span class="refTitle">"Some challenges with IP multicast deployment"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="POS">[POS]</dt>
      <dd>
<span class="refAuthor">IAB</span>, <span class="refTitle">"Position Papers: DEDR Workshop"</span>, <time datetime="2019-06" class="refDate">June 2019</time>, <span>&lt;<a href="https://www.iab.org/activities/workshops/dedr-workshop/position-papers/">https://www.iab.org/activities/workshops/dedr-workshop/position-papers/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Reid2019">[Reid2019]</dt>
      <dd>
<span class="refAuthor">Reid, J.</span>, <span class="refTitle">"Where/Why has DNS gone wrong?"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="RFC3552">[RFC3552]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span><span class="refAuthor"> and B. Korver</span>, <span class="refTitle">"Guidelines for Writing RFC Text on Security Considerations"</span>, <span class="seriesInfo">BCP 72</span>, <span class="seriesInfo">RFC 3552</span>, <span class="seriesInfo">DOI 10.17487/RFC3552</span>, <time datetime="2003-07" class="refDate">July 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3552">https://www.rfc-editor.org/info/rfc3552</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4033">[RFC4033]</dt>
      <dd>
<span class="refAuthor">Arends, R.</span><span class="refAuthor">, Austein, R.</span><span class="refAuthor">, Larson, M.</span><span class="refAuthor">, Massey, D.</span><span class="refAuthor">, and S. Rose</span>, <span class="refTitle">"DNS Security Introduction and Requirements"</span>, <span class="seriesInfo">RFC 4033</span>, <span class="seriesInfo">DOI 10.17487/RFC4033</span>, <time datetime="2005-03" class="refDate">March 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4033">https://www.rfc-editor.org/info/rfc4033</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4271">[RFC4271]</dt>
      <dd>
<span class="refAuthor">Rekhter, Y., Ed.</span><span class="refAuthor">, Li, T., Ed.</span><span class="refAuthor">, and S. Hares, Ed.</span>, <span class="refTitle">"A Border Gateway Protocol 4 (BGP-4)"</span>, <span class="seriesInfo">RFC 4271</span>, <span class="seriesInfo">DOI 10.17487/RFC4271</span>, <time datetime="2006-01" class="refDate">January 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4271">https://www.rfc-editor.org/info/rfc4271</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5218">[RFC5218]</dt>
      <dd>
<span class="refAuthor">Thaler, D.</span><span class="refAuthor"> and B. Aboba</span>, <span class="refTitle">"What Makes for a Successful Protocol?"</span>, <span class="seriesInfo">RFC 5218</span>, <span class="seriesInfo">DOI 10.17487/RFC5218</span>, <time datetime="2008-07" class="refDate">July 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5218">https://www.rfc-editor.org/info/rfc5218</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7258">[RFC7258]</dt>
      <dd>
<span class="refAuthor">Farrell, S.</span><span class="refAuthor"> and H. Tschofenig</span>, <span class="refTitle">"Pervasive Monitoring Is an Attack"</span>, <span class="seriesInfo">BCP 188</span>, <span class="seriesInfo">RFC 7258</span>, <span class="seriesInfo">DOI 10.17487/RFC7258</span>, <time datetime="2014-05" class="refDate">May 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7258">https://www.rfc-editor.org/info/rfc7258</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8170">[RFC8170]</dt>
      <dd>
<span class="refAuthor">Thaler, D., Ed.</span>, <span class="refTitle">"Planning for Protocol Adoption and Subsequent Transitions"</span>, <span class="seriesInfo">RFC 8170</span>, <span class="seriesInfo">DOI 10.17487/RFC8170</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8170">https://www.rfc-editor.org/info/rfc8170</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8484">[RFC8484]</dt>
      <dd>
<span class="refAuthor">Hoffman, P.</span><span class="refAuthor"> and P. McManus</span>, <span class="refTitle">"DNS Queries over HTTPS (DoH)"</span>, <span class="seriesInfo">RFC 8484</span>, <span class="seriesInfo">DOI 10.17487/RFC8484</span>, <time datetime="2018-10" class="refDate">October 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8484">https://www.rfc-editor.org/info/rfc8484</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8520">[RFC8520]</dt>
      <dd>
<span class="refAuthor">Lear, E.</span><span class="refAuthor">, Droms, R.</span><span class="refAuthor">, and D. Romascanu</span>, <span class="refTitle">"Manufacturer Usage Description Specification"</span>, <span class="seriesInfo">RFC 8520</span>, <span class="seriesInfo">DOI 10.17487/RFC8520</span>, <time datetime="2019-03" class="refDate">March 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8520">https://www.rfc-editor.org/info/rfc8520</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Sethi2019">[Sethi2019]</dt>
      <dd>
<span class="refAuthor">Sethi, M.</span><span class="refAuthor"> and T. Aura</span>, <span class="refTitle">"IoT Security and the role of Manufacturers: A Story of Unrealistic Design Expectations"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
<dt id="Sullivan2019">[Sullivan2019]</dt>
    <dd>
<span class="refAuthor">Sullivan, A.</span>, <span class="refTitle">"Three kinds of concentration in open protocols"</span>, <span class="refContent">position paper submitted for the IAB DEDR workshop</span>, <time datetime="2019-06" class="refDate">June 2019</time>. </dd>
<dd class="break"></dd>
</dl>
</section>
<div id="participants">
<section id="section-appendix.a">
      <h2 id="name-participant-list">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-participant-list" class="section-name selfRef">Participant List</a>
      </h2>
<p id="section-appendix.a-1">The following is a list of participants on site and over a remote connection:<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-appendix.a-2.1">
          <p id="section-appendix.a-2.1.1"><span class="contact-name">Arkko, Jari</span><a href="#section-appendix.a-2.1.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.2">
          <p id="section-appendix.a-2.2.1"><span class="contact-name">Aura, Tuomas</span><a href="#section-appendix.a-2.2.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.3">
          <p id="section-appendix.a-2.3.1"><span class="contact-name">Bertola, Vittorio</span><a href="#section-appendix.a-2.3.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.4">
          <p id="section-appendix.a-2.4.1"><span class="contact-name">Bormann, Carsten</span><a href="#section-appendix.a-2.4.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.5">
          <p id="section-appendix.a-2.5.1"><span class="contact-name">Bortzmeyer, Stéphane</span><a href="#section-appendix.a-2.5.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.6">
          <p id="section-appendix.a-2.6.1"><span class="contact-name">Cooper, Alissa</span><a href="#section-appendix.a-2.6.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.7">
          <p id="section-appendix.a-2.7.1"><span class="contact-name">Farrell, Stephen</span><a href="#section-appendix.a-2.7.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.8">
          <p id="section-appendix.a-2.8.1"><span class="contact-name">Flinck, Hannu</span><a href="#section-appendix.a-2.8.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.9">
          <p id="section-appendix.a-2.9.1"><span class="contact-name">Gahnberg, Carl</span><a href="#section-appendix.a-2.9.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.10">
          <p id="section-appendix.a-2.10.1"><span class="contact-name">Hallam-Baker, Phillip</span><a href="#section-appendix.a-2.10.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.11">
          <p id="section-appendix.a-2.11.1"><span class="contact-name">Hardie, Ted</span><a href="#section-appendix.a-2.11.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.12">
          <p id="section-appendix.a-2.12.1"><span class="contact-name">Hoffman, Paul</span><a href="#section-appendix.a-2.12.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.13">
          <p id="section-appendix.a-2.13.1"><span class="contact-name">Huitema, Christian</span> (remote)<a href="#section-appendix.a-2.13.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.14">
          <p id="section-appendix.a-2.14.1"><span class="contact-name">Huston, Geoff</span><a href="#section-appendix.a-2.14.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.15">
          <p id="section-appendix.a-2.15.1"><span class="contact-name">Komaitis, Konstantinos</span><a href="#section-appendix.a-2.15.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.16">
          <p id="section-appendix.a-2.16.1"><span class="contact-name">Kühlewind, Mirja</span><a href="#section-appendix.a-2.16.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.17">
          <p id="section-appendix.a-2.17.1"><span class="contact-name">Kutscher, Dirk</span><a href="#section-appendix.a-2.17.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.18">
          <p id="section-appendix.a-2.18.1"><span class="contact-name">Li, Zhenbin</span><a href="#section-appendix.a-2.18.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.19">
          <p id="section-appendix.a-2.19.1"><span class="contact-name">Maisonneuve, Julien</span><a href="#section-appendix.a-2.19.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.20">
          <p id="section-appendix.a-2.20.1"><span class="contact-name">Mattsson, John</span><a href="#section-appendix.a-2.20.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.21">
          <p id="section-appendix.a-2.21.1"><span class="contact-name">Müller, Moritz</span><a href="#section-appendix.a-2.21.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.22">
          <p id="section-appendix.a-2.22.1"><span class="contact-name">Ott, Jörg</span><a href="#section-appendix.a-2.22.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.23">
          <p id="section-appendix.a-2.23.1"><span class="contact-name">Pardue, Lucas</span><a href="#section-appendix.a-2.23.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.24">
          <p id="section-appendix.a-2.24.1"><span class="contact-name">Reid, Jim</span><a href="#section-appendix.a-2.24.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.25">
          <p id="section-appendix.a-2.25.1"><span class="contact-name">Rieckers, Jan-Frederik</span><a href="#section-appendix.a-2.25.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.26">
          <p id="section-appendix.a-2.26.1"><span class="contact-name">Sethi, Mohit</span><a href="#section-appendix.a-2.26.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.27">
          <p id="section-appendix.a-2.27.1"><span class="contact-name">Shore, Melinda</span> (remote)<a href="#section-appendix.a-2.27.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.28">
          <p id="section-appendix.a-2.28.1"><span class="contact-name">Soininen, Jonne</span><a href="#section-appendix.a-2.28.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.29">
          <p id="section-appendix.a-2.29.1"><span class="contact-name">Sullivan, Andrew</span><a href="#section-appendix.a-2.29.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.a-2.30">
          <p id="section-appendix.a-2.30.1"><span class="contact-name">Trammell, Brian</span><a href="#section-appendix.a-2.30.1" class="pilcrow">¶</a></p>
</li>
      </ul>
</section>
</div>
<section id="section-appendix.b">
      <h2 id="name-iab-members-at-the-time-of-">
<a href="#name-iab-members-at-the-time-of-" class="section-name selfRef">IAB Members at the Time of Approval</a>
      </h2>
<p id="section-appendix.b-1">Internet Architecture Board members at the time this document was 
     approved for publication were:<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty">
<li class="compact ulEmpty" id="section-appendix.b-2.1">
          <p id="section-appendix.b-2.1.1"><span class="contact-name">Jari Arkko</span><a href="#section-appendix.b-2.1.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="section-appendix.b-2.2">
          <p id="section-appendix.b-2.2.1"><span class="contact-name">Alissa Cooper</span><a href="#section-appendix.b-2.2.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="section-appendix.b-2.3">
          <p id="section-appendix.b-2.3.1"><span class="contact-name">Stephen Farrell</span><a href="#section-appendix.b-2.3.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="section-appendix.b-2.4">
          <p id="section-appendix.b-2.4.1"><span class="contact-name">Wes Hardaker</span><a href="#section-appendix.b-2.4.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="section-appendix.b-2.5">
          <p id="section-appendix.b-2.5.1"><span class="contact-name">Ted Hardie</span><a href="#section-appendix.b-2.5.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="section-appendix.b-2.6">
          <p id="section-appendix.b-2.6.1"><span class="contact-name">Christian Huitema</span><a href="#section-appendix.b-2.6.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="section-appendix.b-2.7">
          <p id="section-appendix.b-2.7.1"><span class="contact-name">Zhenbin Li</span><a href="#section-appendix.b-2.7.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="section-appendix.b-2.8">
          <p id="section-appendix.b-2.8.1"><span class="contact-name">Erik Nordmark</span><a href="#section-appendix.b-2.8.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="section-appendix.b-2.9">
          <p id="section-appendix.b-2.9.1"><span class="contact-name">Mark Nottingham</span><a href="#section-appendix.b-2.9.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="section-appendix.b-2.10">
          <p id="section-appendix.b-2.10.1"><span class="contact-name">Melinda Shore</span><a href="#section-appendix.b-2.10.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="section-appendix.b-2.11">
          <p id="section-appendix.b-2.11.1"><span class="contact-name">Jeff Tantsura</span><a href="#section-appendix.b-2.11.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="section-appendix.b-2.12">
          <p id="section-appendix.b-2.12.1"><span class="contact-name">Martin Thomson</span><a href="#section-appendix.b-2.12.1" class="pilcrow">¶</a></p>
</li>
        <li class="compact ulEmpty" id="section-appendix.b-2.13">
          <p id="section-appendix.b-2.13.1"><span class="contact-name">Brian Trammell</span><a href="#section-appendix.b-2.13.1" class="pilcrow">¶</a></p>
</li>
      </ul>
</section>
<div id="ack">
<section id="section-appendix.c">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.c-1">The authors would like to thank the workshop participants, the members of the IAB, and the participants in the architecture discussion list for interesting discussions. The notes from <span class="contact-name">Jim Reid</span> were instrumental in writing this report. The workshop organizers would also like to thank Nokia for hosting the workshop in excellent facilities in Kirkkonummi, Finland.<a href="#section-appendix.c-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.d">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jari Arkko</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jari.arkko@piuha.net" class="email">jari.arkko@piuha.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Ted Hardie</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ted.ietf@gmail.com" class="email">ted.ietf@gmail.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>