File: rfc9067.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 (3500 lines) | stat: -rw-r--r-- 137,627 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 9067: A YANG Data Model for Routing Policy</title>
<meta content="Yingzhen Qu" name="author">
<meta content="Jeff Tantsura" name="author">
<meta content="Acee Lindem" name="author">
<meta content="Xufeng Liu" name="author">
<meta content="
       This document defines a YANG data model for configuring and managing
      routing policies in a vendor-neutral way. The model provides a generic
      routing policy framework that can be extended for specific routing
      protocols using the YANG 'augment' mechanism.
       
    " name="description">
<meta content="xml2rfc 3.10.0" name="generator">
<meta content="example" name="keyword">
<meta content="9067" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.10.0
    Python 3.6.13
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9067.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.ulBare, li.ulBare {
  margin-left: 0em !important;
}
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;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#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: auto;
  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";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9067" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-rtgwg-policy-model-31" 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 9067</td>
<td class="center">Routing Policy YANG Data Model</td>
<td class="right">October 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Qu, et al.</td>
<td class="center">Standards Track</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 Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9067" class="eref">9067</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-10" class="published">October 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">Y. Qu</div>
<div class="org">Futurewei</div>
</div>
<div class="author">
      <div class="author-name">J. Tantsura</div>
<div class="org">Microsoft</div>
</div>
<div class="author">
      <div class="author-name">A. Lindem</div>
<div class="org">Cisco</div>
</div>
<div class="author">
      <div class="author-name">X. Liu</div>
<div class="org">Volta Networks</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9067</h1>
<h1 id="title">A YANG Data Model for Routing Policy</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document defines a YANG data model for configuring and managing
      routing policies in a vendor-neutral way. The model provides a generic
      routing policy framework that can be extended for specific routing
      protocols using the YANG 'augment' mechanism.<a href="#section-abstract-1" 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 is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in 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/rfc9067">https://www.rfc-editor.org/info/rfc9067</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. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<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 ulBare ulEmpty">
<li class="compact toc ulBare 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></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-goals-and-approach" class="xref">Goals and Approach</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology-and-notation" class="xref">Terminology and Notation</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-tree-diagrams" class="xref">Tree Diagrams</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-prefixes-in-data-node-names" class="xref">Prefixes in Data Node Names</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-model-overview" class="xref">Model Overview</a></p>
</li>
          <li class="compact toc ulBare 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-route-policy-expression" class="xref">Route Policy Expression</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare 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-defined-sets-for-policy-mat" class="xref">Defined Sets for Policy Matching</a></p>
</li>
              <li class="compact toc ulBare 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-policy-conditions" class="xref">Policy Conditions</a></p>
</li>
              <li class="compact toc ulBare 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-policy-actions" class="xref">Policy Actions</a></p>
</li>
              <li class="compact toc ulBare 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-policy-subroutines" class="xref">Policy Subroutines</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-policy-evaluation" class="xref">Policy Evaluation</a></p>
</li>
          <li class="compact toc ulBare 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-applying-routing-policy" class="xref">Applying Routing Policy</a></p>
</li>
          <li class="compact toc ulBare 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-yang-module-and-tree" class="xref">YANG Module and Tree</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-routing-policy-model-tree" class="xref">Routing Policy Model Tree</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-routing-policy-model" class="xref">Routing Policy Model</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-routing-protocol-specific-p" class="xref">Routing Protocol-Specific Policies</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#appendix-B" class="xref">Appendix B</a>.  <a href="#name-policy-examples" class="xref">Policy Examples</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#appendix-C" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#appendix-D" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="intro">
<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">This document describes a YANG data model <span>[<a href="#RFC7950" class="xref">RFC7950</a>]</span> for routing policy configuration based on
      operational usage and best practices in a variety of service provider
      networks.  The model is intended to be vendor neutral to allow operators
      to manage policy configuration consistently in environments with routers
      supplied by multiple vendors.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2"> The YANG modules in this document conform to the Network Management
      Datastore Architecture (NMDA) <span>[<a href="#RFC8342" class="xref">RFC8342</a>]</span>.<a href="#section-1-2" class="pilcrow">¶</a></p>
<div id="goals">
<section id="section-1.1">
        <h3 id="name-goals-and-approach">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-goals-and-approach" class="section-name selfRef">Goals and Approach</a>
        </h3>
<p id="section-1.1-1">
      This model does not aim to be feature complete; it is a
      subset of the policy configuration parameters available
      in a variety of vendor implementations but supports widely
      used constructs for managing how routes are imported,
      exported, and modified across different routing protocols.
      The model development approach has been to examine actual
      policy configurations in use across several operator
      networks.  Hence, the focus is on enabling policy configuration
      capabilities and structure that are in wide use.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">
      Despite the differences in details of policy expressions and
      conventions in various vendor implementations, the model
      reflects the observation that a relatively simple condition-action
      approach can be readily mapped to several existing vendor
      implementations and also gives operators a familiar and 
      straightforward way to express policy. A side effect of this design 
      decision is that other methods for expressing policies are not 
      considered.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
<p id="section-1.1-3">
      Consistent with the goal to produce a data model that is vendor
      neutral, only policy expressions that are deemed to be widely
      available in prevalent implementations are included in the
      model.  Those configuration items that are only available from
      a single implementation are omitted from the model with the
      expectation they will be available in separate vendor-provided
      modules that augment the current model.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-2">
      <h2 id="name-terminology-and-notation">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology-and-notation" class="section-name selfRef">Terminology and Notation</a>
      </h2>
<p id="section-2-1">
      The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
      "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
      "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
      "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are
      to be interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and
      only when, they appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2-2">
        <dt id="section-2-2.1">Routing policy:
</dt>
        <dd style="margin-left: 1.5em" id="section-2-2.2">A routing policy defines how routes are imported, exported, modified, and
advertised between routing protocol instances or within a single routing
protocol instance.<a href="#section-2-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-2.3">Policy chain:
</dt>
        <dd style="margin-left: 1.5em" id="section-2-2.4">A policy chain is a sequence of policy definitions. They can be
referenced from different contexts.<a href="#section-2-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-2.5">Policy statement:
</dt>
        <dd style="margin-left: 1.5em" id="section-2-2.6">Policy statements consist of a set of conditions and actions (either of
which may be empty).<a href="#section-2-2.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-2-3">The following terms are defined in <span>[<a href="#RFC8342" class="xref">RFC8342</a>]</span>:<a href="#section-2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-4.1">client<a href="#section-2-4.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-4.2">server<a href="#section-2-4.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-4.3">configuration<a href="#section-2-4.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-4.4">system state<a href="#section-2-4.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-4.5">operational state<a href="#section-2-4.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-4.6">intended configuration<a href="#section-2-4.6" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-2-5">The following terms are defined in <span>[<a href="#RFC7950" class="xref">RFC7950</a>]</span>:<a href="#section-2-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-6.1">action<a href="#section-2-6.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-6.2">augment<a href="#section-2-6.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-6.3">container<a href="#section-2-6.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-6.4">container with presence<a href="#section-2-6.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-6.5">data model<a href="#section-2-6.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-6.6">data node<a href="#section-2-6.6" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-6.7">feature<a href="#section-2-6.7" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-6.8">leaf<a href="#section-2-6.8" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-6.9">list<a href="#section-2-6.9" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-6.10">mandatory node<a href="#section-2-6.10" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-6.11">module<a href="#section-2-6.11" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-6.12">schema tree<a href="#section-2-6.12" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-6.13">RPC (Remote Procedure Call) operation<a href="#section-2-6.13" class="pilcrow">¶</a>
</li>
      </ul>
<section id="section-2.1">
        <h3 id="name-tree-diagrams">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-tree-diagrams" class="section-name selfRef">Tree Diagrams</a>
        </h3>
<p id="section-2.1-1">Tree diagrams used in this document follow the notation
          defined in <span>[<a href="#RFC8340" class="xref">RFC8340</a>]</span>.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
</section>
<div id="sec.prefixes">
<section id="section-2.2">
        <h3 id="name-prefixes-in-data-node-names">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-prefixes-in-data-node-names" class="section-name selfRef">Prefixes in Data Node Names</a>
        </h3>
<p id="section-2.2-1">
        In this document, names of data nodes, actions, and other data model
        objects are often used without a prefix if it is clear in which YANG
        module each name is defined given the context. Otherwise, names are
        prefixed using the standard prefix associated with the corresponding
        YANG module, as shown in <a href="#tab.prefixes" class="xref">Table 1</a>.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<span id="name-prefixes-and-corresponding-"></span><div id="tab.prefixes">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-prefixes-and-corresponding-" class="selfRef">Prefixes and Corresponding YANG Modules</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Prefix</th>
              <th class="text-left" rowspan="1" colspan="1">YANG module</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">if</td>
              <td class="text-left" rowspan="1" colspan="1">ietf-interfaces</td>
              <td class="text-left" rowspan="1" colspan="1">
                <span>[<a href="#RFC8343" class="xref">RFC8343</a>]</span>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">rt</td>
              <td class="text-left" rowspan="1" colspan="1">ietf-routing</td>
              <td class="text-left" rowspan="1" colspan="1">
                <span>[<a href="#RFC8349" class="xref">RFC8349</a>]</span>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">yang</td>
              <td class="text-left" rowspan="1" colspan="1">ietf-yang-types</td>
              <td class="text-left" rowspan="1" colspan="1">
                <span>[<a href="#RFC6991" class="xref">RFC6991</a>]</span>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">inet</td>
              <td class="text-left" rowspan="1" colspan="1">ietf-inet-types</td>
              <td class="text-left" rowspan="1" colspan="1">
                <span>[<a href="#RFC6991" class="xref">RFC6991</a>]</span>
</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
</section>
<div id="overview">
<section id="section-3">
      <h2 id="name-model-overview">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-model-overview" class="section-name selfRef">Model Overview</a>
      </h2>
<p id="section-3-1">
      The routing policy module has three main parts:<a href="#section-3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-2.1">
          A generic framework is provided to express policies as sets of
          related conditions and actions. This includes match sets and actions
          that are useful across many routing protocols.<a href="#section-3-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-2.2">
          A structure that allows routing protocol models to add
          protocol-specific policy conditions and actions through YANG
          augmentations is also provided.  There is a complete example of
          this for <span><a href="#RFC4271" class="xref">BGP</a> [<a href="#RFC4271" class="xref">RFC4271</a>]</span> policies
          in the proposed vendor-neutral <span><a href="#I-D.ietf-idr-bgp-model" class="xref">BGP data model</a> [<a href="#I-D.ietf-idr-bgp-model" class="xref">IDR-BGP-MODEL</a>]</span>.  <a href="#augment" class="xref">Appendix A</a> provides an
          example of how an augmentation for BGP policies might be
          accomplished. Note that this section is not normative, as the BGP
          model is still evolving.<a href="#section-3-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-2.3">
          Finally, a reusable grouping is defined for attaching import and
          export rules in the context of routing configuration for different
          protocols, Virtual Routing and Forwarding (VRF) instances, etc.  This also enables the creation of policy
          chains and the expression of default policy behavior. In this document,
          policy chains are sequences of policy definitions that are
   applied in order (described in <a href="#expression" class="xref">Section 4</a>).<a href="#section-3-2.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-3">
        The module makes use of the standard Internet types,
        such as IP addresses, autonomous system numbers, etc.,
        defined in <span><a href="#RFC6991" class="xref">RFC 6991</a> [<a href="#RFC6991" class="xref">RFC6991</a>]</span>.<a href="#section-3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="expression">
<section id="section-4">
      <h2 id="name-route-policy-expression">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-route-policy-expression" class="section-name selfRef">Route Policy Expression</a>
      </h2>
<p id="section-4-1">
      Policies are expressed as a sequence of top-level policy
      definitions, each of which consists of a sequence of policy statements.
      Policy statements in turn consist of simple condition-action
      tuples. Conditions may include multiple match or comparison
      operations, and similarly, actions may include multiple changes to
      route attributes or indicate a final disposition of accepting
      or rejecting the route.  This structure is shown below.<a href="#section-4-1" class="pilcrow">¶</a></p>
<div id="section-4-2">
<pre class="lang-yangtree sourcecode">
  +--rw routing-policy
     +--rw policy-definitions
        +--ro match-modified-attributes?   boolean
        +--rw policy-definition* [name]
           +--rw name          string
           +--rw statements
              +--rw statement* [name]
                 +--rw name          string
                 +--rw conditions
                 |     ...
                 +--rw actions
                       ...
</pre><a href="#section-4-2" class="pilcrow">¶</a>
</div>
<div id="sets">
<section id="section-4.1">
        <h3 id="name-defined-sets-for-policy-mat">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-defined-sets-for-policy-mat" class="section-name selfRef">Defined Sets for Policy Matching</a>
        </h3>
<p id="section-4.1-1">
        The model provides a collection of generic sets that can be used for
        matching in policy conditions.  These sets are applicable for
        route selection across  multiple routing protocols. They may be
        further augmented by protocol-specific models that have their
        own defined sets. The defined sets include:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.1-2">
          <dt id="section-4.1-2.1">prefix sets:
</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-2.2">Each prefix set defines a set of IP prefixes, each with an associated IP
prefix and netmask range (or exact length).<a href="#section-4.1-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-2.3">neighbor sets:
</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-2.4">Each neighbor set defines a set of neighboring nodes by their IP
addresses. A neighbor set is used for selecting routes based on the neighbors
advertising the routes.<a href="#section-4.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-2.5">tag sets: 
</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-2.6">Each tag set defines a set of generic tag values that can be used in
matches for selecting routes.<a href="#section-4.1-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.1-3">
          The model structure for defined sets is shown below.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<div id="section-4.1-4">
<pre class="lang-yangtree sourcecode">
    +--rw routing-policy
       +--rw defined-sets
       |  +--rw prefix-sets
       |  |  +--rw prefix-set* [name]
       |  |     +--rw name        string
       |  |     +--rw mode?       enumeration
       |  |     +--rw prefixes
       |  |        +--rw prefix-list* [ip-prefix mask-length-lower
       |  |                            mask-length-upper]
       |  |           +--rw ip-prefix           inet:ip-prefix
       |  |           +--rw mask-length-lower    uint8
       |  |           +--rw mask-length-upper    uint8
       |  +--rw neighbor-sets
       |  |  +--rw neighbor-set* [name]
       |  |     +--rw name       string
       |  |     +--rw address*   inet:ip-address
       |  +--rw tag-sets
       |     +--rw tag-set* [name]
       |        +--rw name         string
       |        +--rw tag-value*   tag-type
</pre><a href="#section-4.1-4" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="conditions">
<section id="section-4.2">
        <h3 id="name-policy-conditions">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-policy-conditions" class="section-name selfRef">Policy Conditions</a>
        </h3>
<p id="section-4.2-1">
        Policy statements consist of a set of conditions and actions
        (either of which may be empty).  Conditions are used to
        match route attributes against a defined set (e.g., a prefix
        set) or to compare attributes against a specific value.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">
        Match conditions may be further modified using the
        match-set-options configuration, which allows network operators to
        change the behavior of a match. Three options are supported:<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.2-3">
          <dt id="section-4.2-3.1">'all':
</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-3.2">Match is true only if the given value matches all members of the set.<a href="#section-4.2-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-3.3">'any':
</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-3.4">Match is true if the given value matches any member of the set.<a href="#section-4.2-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-3.5">'invert':
</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-3.6">Match is true if the given value does not match any member of the given set.<a href="#section-4.2-3.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.2-4">
        Not all options are appropriate for matching against all
        defined sets (e.g., match 'all' in a prefix set does not make sense).
        In the model, a restricted set of match options is used where
        applicable.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
<p id="section-4.2-5">
        Comparison conditions may similarly use options to change how route
        attributes should be tested, e.g., for equality or inequality, against
        a given value.<a href="#section-4.2-5" class="pilcrow">¶</a></p>
<p id="section-4.2-6">
        While most policy conditions will be added by individual
        routing protocol models via augmentation, this routing policy
        model includes several generic match conditions and the
        ability to test which protocol or mechanism installed a route
        (e.g., BGP, IGP, static, etc.).  The conditions included in
        the model are shown below.<a href="#section-4.2-6" class="pilcrow">¶</a></p>
<div id="section-4.2-7">
<pre class="lang-yangtree sourcecode">
  +--rw routing-policy
     +--rw policy-definitions
        +--rw policy-definition* [name]
           +--rw name          string
           +--rw statements
              +--rw statement* [name]
                 +--rw conditions
                 |  +--rw call-policy?
                 |  +--rw source-protocol?
                 |  +--rw match-interface
                 |  |  +--rw interface?
                 |  +--rw match-prefix-set
                 |  |  +--rw prefix-set?
                 |  |  +--rw match-set-options?
                 |  +--rw match-neighbor-set
                 |  |  +--rw neighbor-set?
                 |  +--rw match-tag-set
                 |  |  +--rw tag-set?
                 |  |  +--rw match-set-options?
                 |  +--rw match-route-type
                 |     +--rw route-type*
</pre><a href="#section-4.2-7" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="actions">
<section id="section-4.3">
        <h3 id="name-policy-actions">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-policy-actions" class="section-name selfRef">Policy Actions</a>
        </h3>
<p id="section-4.3-1">
        When policy conditions are satisfied, policy actions are used
        to set various attributes of the route being processed or to
        indicate the final disposition of the route, i.e., accept or
        reject.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">
        Similar to policy conditions, the routing policy model includes
        generic actions in addition to the basic route disposition
        actions. These are shown below.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<div id="section-4.3-3">
<pre class="lang-yangtree sourcecode">
  +--rw routing-policy
     +--rw policy-definitions
        +--rw policy-definition* [name]
           +--rw statements
              +--rw statement* [name]
                 +--rw actions
                    +--rw policy-result?   policy-result-type
                    +--rw set-metric
                    |  +--rw metric-modification?
                    |  |         metric-modification-type
                    |  +--rw metric?                 uint32
                    +--rw set-metric-type
                    |  +--rw metric-type?   identityref
                    +--rw set-route-level
                    |  +--rw route-level?   identityref
                    +--rw set-route-preference?      uint16
                    +--rw set-tag?               tag-type
                    +--rw set-application-tag?   tag-type
</pre><a href="#section-4.3-3" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="subroutines">
<section id="section-4.4">
        <h3 id="name-policy-subroutines">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-policy-subroutines" class="section-name selfRef">Policy Subroutines</a>
        </h3>
<p id="section-4.4-1">
        Policy 'subroutines' (or nested policies) are
        supported by allowing policy statement conditions to reference
        other policy definitions using the call-policy configuration.
        Called policies apply their conditions and
        actions before returning to the calling policy statement and
        resuming evaluation.  The outcome of the called policy affects
        the evaluation of the calling policy.  If the called policy
        results in an accept-route,
        then the subroutine returns an effective Boolean true value to
        the calling policy.  For the calling policy, this is equivalent
        to a condition statement evaluating to a true value, thus the calling party
        continues in its evaluation of the policy 
        (see <a href="#evaluation" class="xref">Section 5</a>).  Note that
        the called policy may also modify attributes of the route in
        its action statements. Similarly, a reject-route action
        returns false, and the calling policy evaluation will be
        affected accordingly. When the end of the subroutine policy
        statements is reached, the default route disposition
        action is returned (i.e., Boolean false for reject-route).
        Consequently, a subroutine cannot
        explicitly accept or reject a route. Rather, the called policy
        returns Boolean true if its outcome is accept-route or Boolean
        false if its outcome is reject-route. Route
        acceptance or rejection is solely determined by the top-level
        policy.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">
        Note that the called policy may itself call other policies (subject to
        implementation limitations).  The model does not prescribe a nesting
        depth because this varies among implementations. For example, an
        implementation may only support a single level of subroutine
        recursion. As with any routing policy construction, care must be taken
        with nested policies to ensure that the effective return value results
        in the intended behavior.  Nested policies are a convenience in many
        routing policy constructions, but creating policies nested beyond a
        small number of levels (e.g., two to three) is discouraged. Also,
        implementations <span class="bcp14">MUST</span> perform validation to ensure that there is
        no recursion among nested routing policies.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="evaluation">
<section id="section-5">
      <h2 id="name-policy-evaluation">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-policy-evaluation" class="section-name selfRef">Policy Evaluation</a>
      </h2>
<p id="section-5-1">
      Evaluation of each policy definition proceeds by evaluating its
      individual policy statements in the order that they are defined.  When all
      the condition statements in a policy statement are satisfied, the
      corresponding action statements are executed.  If the actions
      include either accept-route or reject-route actions,
      evaluation of the current policy definition stops, and no further
      policy statement is evaluated. If there are multiple policies
      in the policy chain, subsequent policies are not
      evaluated.  Policy chains are sequences of
      policy definitions (as described in <a href="#expression" class="xref">Section 4</a>).<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
      If the conditions are not satisfied, then evaluation proceeds to
      the next policy statement.  If none of the policy statement
      conditions are satisfied, then evaluation of the current policy
      definition stops, and the next policy definition in the chain is
      evaluated. When the end of the policy chain is reached, the
      default route disposition action is performed (i.e., reject-route
      unless an alternate default action is specified for the
      chain).<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">
      Whether the route's pre-policy attributes are used for testing policy
      statement conditions is dependent on the implementation-specific value
      of the match-modified-attributes leaf. If match-modified-attributes is
      false and actions modify route attributes, these modifications are not
      used for policy statement conditions.  Conversely, if
      match-modified-attributes is true and actions modify the policy
      application-specific attributes, the attributes as modified by the
      policy are used for policy condition statements.<a href="#section-5-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="usage">
<section id="section-6">
      <h2 id="name-applying-routing-policy">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-applying-routing-policy" class="section-name selfRef">Applying Routing Policy</a>
      </h2>
<p id="section-6-1">
      Routing policy is applied by defining and attaching policy chains in
      various routing contexts.  Policy chains are sequences of policy
      definitions (described in <a href="#expression" class="xref">Section 4</a>). They can be referenced from different contexts. For example, a
      policy chain could be associated with a routing protocol and used to
      control its interaction with its protocol peers, or it could be used to
      control the interaction between a routing protocol and the local routing
      information base.  A policy chain has an associated direction (import or
      export) with respect to the context in which it is referenced.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">The routing policy model defines an apply-policy grouping that
      can be imported and used by other models.  As shown below, it
      allows definition of import and export policy chains, as well as
      specifies the default route disposition to be used when no
      policy definition in the chain results in a final decision.<a href="#section-6-2" class="pilcrow">¶</a></p>
<div id="section-6-3">
<pre class="lang-yangtree sourcecode">
      +--rw apply-policy
      |  +--rw import-policy*
      |  +--rw default-import-policy?   default-policy-type
      |  +--rw export-policy*
      |  +--rw default-export-policy?   default-policy-type
</pre><a href="#section-6-3" class="pilcrow">¶</a>
</div>
<p id="section-6-4">
      The default policy defined by the model is to reject the route for
      both import and export policies.<a href="#section-6-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="models">
<section id="section-7">
      <h2 id="name-yang-module-and-tree">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-yang-module-and-tree" class="section-name selfRef">YANG Module and Tree</a>
      </h2>
<div id="policy.tree">
<section id="section-7.1">
        <h3 id="name-routing-policy-model-tree">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-routing-policy-model-tree" class="section-name selfRef">Routing Policy Model Tree</a>
        </h3>
<p id="section-7.1-1">The tree of the routing policy model is shown below.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<div id="section-7.1-2">
<pre class="lang-yangtree sourcecode">
module: ietf-routing-policy
  +--rw routing-policy
     +--rw defined-sets
     |  +--rw prefix-sets
     |  |  +--rw prefix-set* [name mode]
     |  |     +--rw name        string
     |  |     +--rw mode        enumeration
     |  |     +--rw prefixes
     |  |        +--rw prefix-list* [ip-prefix mask-length-lower
     |  |                            mask-length-upper]
     |  |           +--rw ip-prefix            inet:ip-prefix
     |  |           +--rw mask-length-lower    uint8
     |  |           +--rw mask-length-upper    uint8
     |  +--rw neighbor-sets
     |  |  +--rw neighbor-set* [name]
     |  |     +--rw name       string
     |  |     +--rw address*   inet:ip-address
     |  +--rw tag-sets
     |     +--rw tag-set* [name]
     |        +--rw name         string
     |        +--rw tag-value*   tag-type
     +--rw policy-definitions
        +--ro match-modified-attributes?   boolean
        +--rw policy-definition* [name]
           +--rw name          string
           +--rw statements
              +--rw statement* [name]
                 +--rw name          string
                 +--rw conditions
                 |  +--rw call-policy?       -&gt; ../../../../../..
                 |                           /policy-definitions
                 |                           /policy-definition/name
                 |  +--rw source-protocol?      identityref
                 |  +--rw match-interface
                 |  |  +--rw interface?      if:interface-ref
                 |  +--rw match-prefix-set
                 |  |  +--rw prefix-set?     -&gt; ../../../../../../..
                 |  |                        /defined-sets
                 |  |                        /prefix-sets
                 |  |                        /prefix-set/name
                 |  |  +--rw match-set-options?
                 |  |                        match-set-options-type
                 |  +--rw match-neighbor-set
                 |  |  +--rw neighbor-set?   -&gt; ../../../../../../..
                 |  |                        /defined-sets
                 |  |                        /neighbor-sets
                 |  |                        /neighbor-set/name
                 |  +--rw match-tag-set
                 |  |  +--rw tag-set?        -&gt; ../../../../../../..
                 |  |                        /defined-sets/tag-sets
                 |  |                        /tag-set/name
                 |  |  +--rw match-set-options?
                 |  |                        match-set-options-type
                 |  +--rw match-route-type
                 |     +--rw route-type*     identityref
                 +--rw actions
                    +--rw policy-result?         policy-result-type
                    +--rw set-metric
                    |  +--rw metric-modification?
                    |                        metric-modification-type
                    |  +--rw metric?                uint32
                    +--rw set-metric-type
                    |  +--rw metric-type?   identityref
                    +--rw set-route-level
                    |  +--rw route-level?   identityref
                    +--rw set-route-preference?        uint16
                    +--rw set-tag?               tag-type
                    +--rw set-application-tag?   tag-type
</pre><a href="#section-7.1-2" class="pilcrow">¶</a>
</div>
</section>
</div>
<section id="section-7.2">
        <h3 id="name-routing-policy-model">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-routing-policy-model" class="section-name selfRef">Routing Policy Model</a>
        </h3>
<p id="section-7.2-1">The following RFCs are not referenced in the document text but
        are referenced in the ietf-routing-policy.yang module:
        <span>[<a href="#RFC2328" class="xref">RFC2328</a>]</span>, <span>[<a href="#RFC3101" class="xref">RFC3101</a>]</span>,
        <span>[<a href="#RFC5130" class="xref">RFC5130</a>]</span>, <span>[<a href="#RFC5302" class="xref">RFC5302</a>]</span>,
        <span>[<a href="#RFC6991" class="xref">RFC6991</a>]</span>, and <span>[<a href="#RFC8343" class="xref">RFC8343</a>]</span>.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<div id="section-7.2-2">
<pre class="lang-yang sourcecode">&lt;CODE BEGINS&gt; file "ietf-routing-policy@2021-10-11.yang"

module ietf-routing-policy {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy";
  prefix rt-pol;

  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991: Common YANG Data Types";
  }
  import ietf-yang-types {
    prefix yang;
    reference
      "RFC 6991: Common YANG Data Types";
  }
  import ietf-interfaces {
    prefix if;
    reference
      "RFC 8343: A YANG Data Model for Interface
                 Management";
  }
  import ietf-routing {
    prefix rt;
    reference
      "RFC 8349: A YANG Data Model for Routing
                 Management (NMDA Version)";
  }

  organization
    "IETF RTGWG - Routing Area Working Group";
  contact
    "WG Web:   &lt;https://datatracker.ietf.org/wg/rtgwg/&gt;
     WG List:  &lt;mailto: rtgwg@ietf.org&gt;

     Editors:  Yingzhen Qu
               &lt;mailto: yingzhen.qu@futurewei.com&gt;
               Jeff Tantsura
               &lt;mailto: jefftant.ietf@gmail.com&gt;
               Acee Lindem
               &lt;mailto: acee@cisco.com&gt;
               Xufeng Liu
               &lt;mailto: xufeng.liu.ietf@gmail.com&gt;";
  description
    "This module describes a YANG data model for routing policy
     configuration. It is a limited subset of all of the policy
     configuration parameters available in the variety of vendor
     implementations, but supports widely used constructs for
     managing how routes are imported, exported, modified, and
     advertised across different routing protocol instances or
     within a single routing protocol instance.  This module is
     intended to be used in conjunction with routing protocol
     configuration modules (e.g., BGP) defined in other models.

     This YANG module conforms to the Network Management
     Datastore Architecture (NMDA), as described in RFC 8342.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.

     Copyright (c) 2021 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Simplified BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC 9067;
     see the RFC itself for full legal notices.";

  reference
    "RFC 9067: A YANG Data Model for Routing Policy.";

  revision 2021-10-11 {
    description
      "Initial revision.";
    reference
      "RFC 9067: A YANG Data Model for Routing Policy.";
  }

  /* Identities */

  identity metric-type {
    description
      "Base identity for route metric types.";
  }

  identity ospf-type-1-metric {
    base metric-type;
    description
      "Identity for the OSPF type 1 external metric types.  It
       is only applicable to OSPF routes.";
    reference
      "RFC 2328: OSPF Version 2";
  }

  identity ospf-type-2-metric {
    base metric-type;
    description
      "Identity for the OSPF type 2 external metric types.  It
       is only applicable to OSPF routes.";
    reference
      "RFC 2328: OSPF Version 2";
  }

  identity isis-internal-metric {
    base metric-type;
    description
      "Identity for the IS-IS internal metric types.  It is only
       applicable to IS-IS routes.";
    reference
      "RFC 5302: Domain-Wide Prefix Distribution with
       Two-Level IS-IS";
  }

  identity isis-external-metric {
    base metric-type;
    description
      "Identity for the IS-IS external metric types.  It is only
       applicable to IS-IS routes.";
    reference
      "RFC 5302: Domain-Wide Prefix Distribution with
       Two-Level IS-IS";
  }

  identity route-level {
    description
      "Base identity for route import level.";
  }

  identity ospf-normal {
    base route-level;
    description
      "Identity for OSPF importation into normal areas.
       It is only applicable to routes imported
       into the OSPF protocol.";
    reference
      "RFC 2328: OSPF Version 2";
  }

  identity ospf-nssa-only {
    base route-level;
    description
      "Identity for the OSPF Not-So-Stubby Area (NSSA) area
       importation.  It is only applicable to routes imported
       into the OSPF protocol.";
    reference
      "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
  }

  identity ospf-normal-nssa {
    base route-level;
    description
      "Identity for OSPF importation into both normal and NSSA
       areas.  It is only applicable to routes imported into
       the OSPF protocol.";
    reference
      "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
  }

  identity isis-level-1 {
    base route-level;
    description
      "Identity for IS-IS Level 1 area importation.  It is only
       applicable to routes imported into the IS-IS protocol.";
    reference
      "RFC 5302: Domain-Wide Prefix Distribution with
       Two-Level IS-IS";
  }

  identity isis-level-2 {
    base route-level;
    description
      "Identity for IS-IS Level 2 area importation.  It is only
       applicable to routes imported into the IS-IS protocol.";
    reference
      "RFC 5302: Domain-Wide Prefix Distribution with
       Two-Level IS-IS";
  }

  identity isis-level-1-2 {
    base route-level;
    description
      "Identity for IS-IS importation into both Level 1 and Level 2
       areas.  It is only applicable to routes imported into the
       IS-IS protocol.";
    reference
      "RFC 5302: Domain-Wide Prefix Distribution with
       Two-Level IS-IS";
  }

  identity proto-route-type {
    description
      "Base identity for route type within a protocol.";
  }

  identity isis-level-1-type {
    base proto-route-type;
    description
      "Identity for IS-IS Level 1 route type.  It is only
       applicable to IS-IS routes.";
    reference
      "RFC 5302: Domain-Wide Prefix Distribution with
       Two-Level IS-IS";
  }

  identity isis-level-2-type {
    base proto-route-type;
    description
      "Identity for IS-IS Level 2 route type.  It is only
       applicable to IS-IS routes.";
    reference
      "RFC 5302: Domain-Wide Prefix Distribution with
       Two-Level IS-IS";
  }

  identity ospf-internal-type {
    base proto-route-type;
    description
      "Identity for OSPF intra-area or inter-area route type.
       It is only applicable to OSPF routes.";
    reference
      "RFC 2328: OSPF Version 2";
  }

  identity ospf-external-type {
    base proto-route-type;
    description
      "Identity for OSPF external type 1/2 route type.
       It is only applicable to OSPF routes.";
    reference
      "RFC 2328: OSPF Version 2";
  }

  identity ospf-external-t1-type {
    base ospf-external-type;
    description
      "Identity for OSPF external type 1 route type.
       It is only applicable to OSPF routes.";
    reference
      "RFC 2328: OSPF Version 2";
  }

  identity ospf-external-t2-type {
    base ospf-external-type;
    description
      "Identity for OSPF external type 2 route type.
       It is only applicable to OSPF routes.";
    reference
      "RFC 2328: OSPF Version 2";
  }

  identity ospf-nssa-type {
    base proto-route-type;
    description
      "Identity for OSPF NSSA type 1/2 route type.
       It is only applicable to OSPF routes.";
    reference
      "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
  }

  identity ospf-nssa-t1-type {
    base ospf-nssa-type;
    description
      "Identity for OSPF NSSA type 1 route type.
       It is only applicable to OSPF routes.";
    reference
      "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
  }

  identity ospf-nssa-t2-type {
    base ospf-nssa-type;
    description
      "Identity for OSPF NSSA type 2 route type.
       It is only applicable to OSPF routes.";
    reference
      "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
  }

  identity bgp-internal {
    base proto-route-type;
    description
      "Identity for routes learned from internal BGP (IBGP).
       It is only applicable to BGP routes.";
    reference
      "RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
  }

  identity bgp-external {
    base proto-route-type;
    description
      "Identity for routes learned from external BGP (EBGP).
       It is only applicable to BGP routes.";
    reference
      "RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
  }

  /* Type Definitions */

  typedef default-policy-type {
    type enumeration {
      enum accept-route {
        description
          "Default policy to accept the route.";
      }
      enum reject-route {
        description
          "Default policy to reject the route.";
      }
    }
    description
      "Type used to specify route disposition in
       a policy chain.  This typedef is used in
       the default import and export policy.";
  }

  typedef policy-result-type {
    type enumeration {
      enum accept-route {
        description
          "Policy accepts the route.";
      }
      enum reject-route {
        description
          "Policy rejects the route.";
      }
    }
    description
      "Type used to specify route disposition in
       a policy chain.";
  }

  typedef tag-type {
    type union {
      type uint32;
      type yang:hex-string;
    }
    description
      "Type for expressing route tags on a local system,
       including IS-IS and OSPF; may be expressed as either decimal
       or hexadecimal integer.";
    reference
      "RFC 2328: OSPF Version 2
       RFC 5130: A Policy Control Mechanism in IS-IS Using
                 Administrative Tags";
  }

  typedef match-set-options-type {
    type enumeration {
      enum any {
        description
          "Match is true if given value matches any member
           of the defined set.";
      }
      enum all {
        description
          "Match is true if given value matches all
           members of the defined set.";
      }
      enum invert {
        description
          "Match is true if given value does not match any
           member of the defined set.";
      }
    }
    default "any";
    description
      "Options that govern the behavior of a match statement.  The
       default behavior is any, i.e., the given value matches any
       of the members of the defined set.";
  }

  typedef metric-modification-type {
    type enumeration {
      enum set-metric {
        description
          "Set the metric to the specified value.";
      }
      enum add-metric {
        description
          "Add the specified value to the existing metric.
           If the result overflows the maximum metric
           (0xffffffff), set the metric to the maximum.";
      }
      enum subtract-metric {
        description
          "Subtract the specified value from the existing metric.  If
           the result is less than 0, set the metric to 0.";
      }
    }
    description
      "Type used to specify how to set the metric given the
       specified value.";
  }

  /* Groupings */

  grouping prefix {
    description
      "Configuration data for a prefix definition.

       The combination of mask-length-lower and mask-length-upper
       define a range for the mask length or single 'exact'
       length if mask-length-lower and mask-length-upper are
       equal.

       Example: 192.0.2.0/24 through 192.0.2.0/26 would be
       expressed as prefix: 192.0.2.0/24,
                    mask-length-lower=24,
                    mask-length-upper=26

       Example: 192.0.2.0/24 (an exact match) would be
       expressed as prefix: 192.0.2.0/24,
                    mask-length-lower=24,
                    mask-length-upper=24

       Example: 2001:DB8::/32 through 2001:DB8::/64 would be
       expressed as prefix: 2001:DB8::/32,
                    mask-length-lower=32,
                    mask-length-upper=64";
    leaf ip-prefix {
      type inet:ip-prefix;
      mandatory true;
      description
        "The IP prefix represented as an IPv6 or IPv4 network
         number followed by a prefix length with an intervening
         slash character as a delimiter.  All members of the
         prefix-set MUST be of the same address family as the
         prefix-set mode.";
    }
    leaf mask-length-lower {
      type uint8 {
        range "0..128";
      }
      description
        "Mask length range lower bound.  It MUST NOT be less than
         the prefix length defined in ip-prefix.";
    }
    leaf mask-length-upper {
      type uint8 {
        range "1..128";
      }
      must '../mask-length-upper &gt;= ../mask-length-lower' {
        error-message "The upper bound MUST NOT be less "
                    + "than lower bound.";
      }
      description
        "Mask length range upper bound.  It MUST NOT be less than
         lower bound.";
    }
  }

  grouping match-set-options-group {
    description
      "Grouping containing options relating to how a particular set
       will be matched.";
    leaf match-set-options {
      type match-set-options-type;
      description
        "Optional parameter that governs the behavior of the
         match operation.";
    }
  }

  grouping match-set-options-restricted-group {
    description
      "Grouping for a restricted set of match operation
       modifiers.";
    leaf match-set-options {
      type match-set-options-type {
        enum any {
          description
            "Match is true if given value matches any
             member of the defined set.";
        }
        enum invert {
          description
            "Match is true if given value does not match
             any member of the defined set.";
        }
      }
      description
        "Optional parameter that governs the behavior of the
         match operation.  This leaf only supports
         the 'any' and 'invert' match options.
         Matching on 'all' is not supported.";
    }
  }

  grouping apply-policy-group {
    description
      "Top-level container for routing policy applications.  This
       grouping is intended to be used in routing models where
       needed.";
    container apply-policy {
      description
        "Anchor point for routing policies in the model.
         Import and export policies are with respect to the local
         routing table, i.e., export (send) and import (receive),
         depending on the context.";
      leaf-list import-policy {
        type leafref {
          path "/rt-pol:routing-policy/rt-pol:policy-definitions/"
             + "rt-pol:policy-definition/rt-pol:name";
          require-instance true;
        }
        ordered-by user;
        description
          "List of policy names in sequence to be applied on
           receiving redistributed routes from another routing
           protocol or receiving a routing update in the current
           context, e.g., for the current peer group, neighbor,
           address family, etc.";
      }
      leaf default-import-policy {
        type default-policy-type;
        default "reject-route";
        description
          "Explicitly set a default policy if no policy definition
           in the import policy chain is satisfied.";
      }
      leaf-list export-policy {
        type leafref {
          path "/rt-pol:routing-policy/rt-pol:policy-definitions/"
             + "rt-pol:policy-definition/rt-pol:name";
          require-instance true;
        }
        ordered-by user;
        description
          "List of policy names in sequence to be applied on
           redistributing routes from one routing protocol to another
           or sending a routing update in the current context, e.g.,
           for the current peer group, neighbor, address family,
           etc.";
      }
      leaf default-export-policy {
        type default-policy-type;
        default "reject-route";
        description
          "Explicitly set a default policy if no policy definition
           in the export policy chain is satisfied.";
      }
    }
  }

  container routing-policy {
    description
      "Top-level container for all routing policy.";
    container defined-sets {
      description
        "Predefined sets of attributes used in policy match
         statements.";
      container prefix-sets {
        description
          "Data definitions for a list of IPv4 or IPv6
           prefixes that are matched as part of a policy.";
        list prefix-set {
          key "name mode";
          description
            "List of the defined prefix sets";
          leaf name {
            type string;
            description
              "Name of the prefix set; this is used as a label to
               reference the set in match conditions.";
          }
          leaf mode {
            type enumeration {
              enum ipv4 {
                description
                  "Prefix set contains IPv4 prefixes only.";
              }
              enum ipv6 {
                description
                  "Prefix set contains IPv6 prefixes only.";
              }
            }
            description
              "Indicates the mode of the prefix set in terms of
               which address families (IPv4 or IPv6) are present.
               The mode provides a hint; all prefixes MUST be of
               the indicated type.  The device MUST validate
               all prefixes and reject the configuration if there
               is a discrepancy.";
          }
          container prefixes {
            description
              "Container for the list of prefixes in a policy
               prefix list.  Since individual prefixes do not have
               unique actions, the order in which the prefix in
               prefix-list are matched has no impact on the outcome
               and is left to the implementation.  A given prefix-set
               condition is satisfied if the input prefix matches
               any of the prefixes in the prefix-set.";
            list prefix-list {
              key "ip-prefix mask-length-lower mask-length-upper";
              description
                "List of prefixes in the prefix set.";
              uses prefix;
            }
          }
        }
      }
      container neighbor-sets {
        description
          "Data definition for a list of IPv4 or IPv6
           neighbors that can be matched in a routing policy.";
        list neighbor-set {
          key "name";
          description
            "List of defined neighbor sets for use in policies.";
          leaf name {
            type string;
            description
              "Name of the neighbor set; this is used as a label
               to reference the set in match conditions.";
          }
          leaf-list address {
            type inet:ip-address;
            description
              "List of IP addresses in the neighbor set.";
          }
        }
      }
      container tag-sets {
        description
          "Data definitions for a list of tags that can
           be matched in policies.";
        list tag-set {
          key "name";
          description
            "List of tag set definitions.";
          leaf name {
            type string;
            description
              "Name of the tag set; this is used as a label to
               reference the set in match conditions.";
          }
          leaf-list tag-value {
            type tag-type;
            description
              "Value of the tag set member.";
          }
        }
      }
    }
    container policy-definitions {
      description
        "Enclosing container for the list of top-level policy
         definitions.";
      leaf match-modified-attributes {
        type boolean;
        config false;
        description
          "This boolean value dictates whether matches are performed
           on the actual route attributes or route attributes
           modified by policy statements preceding the match.";
      }
      list policy-definition {
        key "name";
        description
          "List of top-level policy definitions, keyed by unique
           name.  These policy definitions are expected to be
           referenced (by name) in policy chains specified in
           import or export configuration statements.";
        leaf name {
          type string;
          description
            "Name of the top-level policy definition; this name
             is used in references to the current policy.";
        }
        container statements {
          description
            "Enclosing container for policy statements.";
          list statement {
            key "name";
            ordered-by user;
            description
              "Policy statements group conditions and actions
               within a policy definition.  They are evaluated in
               the order specified.";
            leaf name {
              type string;
              description
                "Name of the policy statement.";
            }
            container conditions {
              description
                "Condition statements for the current policy
                 statement.";
              leaf call-policy {
                type leafref {
                  path "../../../../../../"
                     + "rt-pol:policy-definitions/"
                     + "rt-pol:policy-definition/rt-pol:name";
                  require-instance true;
                }
                description
                  "Applies the statements from the specified policy
                   definition and then returns control to the current
                   policy statement.  Note that the called policy
                   may itself call other policies (subject to
                   implementation limitations).  This is intended to
                   provide a policy 'subroutine' capability.  The
                   called policy SHOULD contain an explicit or a
                   default route disposition that returns an
                   effective true (accept-route) or false
                   (reject-route); otherwise, the behavior may be
                   ambiguous. The call-policy MUST NOT have been
                   previously called without returning (i.e.,
                   recursion is not allowed).";
              }
              leaf source-protocol {
                type identityref {
                  base rt:control-plane-protocol;
                }
                description
                  "Condition to check the protocol / method used to
                   install the route into the local routing table.";
              }
              container match-interface {
                leaf interface {
                  type if:interface-ref;
                  description
                    "Reference to a base interface.";
                }
                description
                  "Container for interface match conditions";
              }
              container match-prefix-set {
                leaf prefix-set {
                  type leafref {
                    path "../../../../../../../defined-sets/"
                       + "prefix-sets/prefix-set/name";
                  }
                  description
                    "References a defined prefix set.";
                }
                uses match-set-options-restricted-group;
                description
                  "Match a referenced prefix-set according to the
                   logic defined in the match-set-options leaf.";
              }
              container match-neighbor-set {
                leaf neighbor-set {
                  type leafref {
                    path "../../../../../../../defined-sets/"
                       + "neighbor-sets/neighbor-set/name";
                    require-instance true;
                  }
                  description
                    "References a defined neighbor set.";
                }
                description
                  "Match a referenced neighbor set.";
              }
              container match-tag-set {
                leaf tag-set {
                  type leafref {
                    path "../../../../../../../defined-sets/"
                       + "tag-sets/tag-set/name";
                    require-instance true;
                  }
                  description
                    "References a defined tag set.";
                }
                uses match-set-options-group;
                description
                  "Match a referenced tag set according to the logic
                   defined in the match-set-options leaf.";
              }
              container match-route-type {
                description
                  "This container provides route-type match
                   condition";
                leaf-list route-type {
                  type identityref {
                    base proto-route-type;
                  }
                  description
                    "Condition to check the protocol-specific type
                     of route.  This is normally used during route
                     importation to select routes or to set
                     protocol-specific attributes based on the route
                     type.";
                }
              }
            }
            container actions {
              description
                "Top-level container for policy action
                 statements.";
              leaf policy-result {
                type policy-result-type;
                description
                  "Select the final disposition for the route,
                   either accept or reject.";
              }
              container set-metric {
                leaf metric-modification {
                  type metric-modification-type;
                  description
                    "Indicates how to modify the metric.";
                }
                leaf metric {
                  type uint32;
                  description
                    "Metric value to set, add, or subtract.";
                }
                description
                  "Set the metric for the route.";
              }
              container set-metric-type {
                leaf metric-type {
                  type identityref {
                    base metric-type;
                  }
                  description
                    "Route metric type.";
                }
                description
                  "Set the metric type for the route.";
              }
              container set-route-level {
                leaf route-level {
                  type identityref {
                    base route-level;
                  }
                  description
                    "Route import level.";
                }
                description
                  "Set the level for importation or
                   exportation of routes.";
              }
              leaf set-route-preference {
                type uint16;
                description
                  "Set the preference for the route.  It is also
                   known as 'administrative distance' and allows for
                   selecting the preferred route among routes with
                   the same destination prefix.  A smaller value is
                   more preferred.";
              }
              leaf set-tag {
                type tag-type;
                description
                  "Set the tag for the route.";
              }
              leaf set-application-tag {
                type tag-type;
                description
                  "Set the application tag for the route.
                   The application-specific tag is an additional tag
                   that can be used by applications that require
                   semantics and/or policy different from that of the
                   tag.  For example, the tag is usually
                   automatically advertised in OSPF AS-External Link
                   State Advertisements (LSAs) while this
                   application-specific tag is not advertised
                   implicitly.";
              }
            }
          }
        }
      }
    }
  }
}

&lt;CODE ENDS&gt;</pre><a href="#section-7.2-2" class="pilcrow">¶</a>
</div>
</section>
</section>
</div>
<section id="section-8">
      <h2 id="name-security-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-8-1">The YANG module specified in this document defines a schema for data
      that is designed to be accessed via network management protocols such as
      NETCONF <span>[<a href="#RFC6241" class="xref">RFC6241</a>]</span> or RESTCONF <span>[<a href="#RFC8040" class="xref">RFC8040</a>]</span>.  The lowest NETCONF layer is the
      secure transport layer, and the mandatory-to-implement secure transport
      is Secure Shell (SSH) <span>[<a href="#RFC6242" class="xref">RFC6242</a>]</span>.  The
      lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure
      transport is TLS <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">The Network Configuration Access Control Model (NACM) <span>[<a href="#RFC8341" class="xref">RFC8341</a>]</span> provides the means to restrict access for particular
      NETCONF or RESTCONF users to a preconfigured subset of all available
      NETCONF or RESTCONF protocol operations and content.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">There are a number of data nodes defined in this YANG module that are
        writable/creatable/deletable (i.e., config true, which is the
        default). These data nodes may be considered sensitive or vulnerable
        in some network environments. Write operations (e.g., edit-config)
        to these data nodes without proper protection can have a negative
        effect on network operations. These are the subtrees and data nodes
        and their sensitivity/vulnerability:<a href="#section-8-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-8-4">
        <dt id="section-8-4.1">/routing-policy/defined-sets/prefix-sets
</dt>
        <dd style="margin-left: 1.5em" id="section-8-4.2">Modification to prefix sets could result in a Denial-of-Service (DoS)
attack. An attacker may try to modify prefix sets and redirect or drop
traffic. Redirection of traffic could be used as part of a more elaborate
attack to either collect sensitive information or masquerade a
service. Additionally, a control plane DoS attack could be accomplished by
allowing a large number of routes to be leaked into a routing protocol domain
(e.g., BGP).<a href="#section-8-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-8-4.3">/routing-policy/defined-sets/neighbor-sets
</dt>
        <dd style="margin-left: 1.5em" id="section-8-4.4">Modification to the neighbor sets could be used to mount a DoS attack or
more elaborate attack as with prefix sets. For example, a DoS attack could be
mounted by changing the neighbor set from which routes are accepted.<a href="#section-8-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-8-4.5">/routing-policy/defined-sets/tag-sets 
</dt>
        <dd style="margin-left: 1.5em" id="section-8-4.6">Modification to the tag sets could be used to mount a DoS attack. Routes
with certain tags might be redirected or dropped. The implications are similar
to prefix sets and neighbor sets. However, the attack may be more difficult to
detect as the routing policy usage of route tags and intent must be understood
to recognize the breach. Conversely, the implications of prefix set or
neighbor set modification are easier to recognize.<a href="#section-8-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-8-4.7">/routing-policy/policy-definitions/policy-definition/statements/statement/conditions
</dt>
        <dd style="margin-left: 1.5em" id="section-8-4.8">Modification to the conditions could be used to mount a DoS attack or
other attack.  An attacker may change a policy condition and redirect or drop
traffic.  As with prefix sets, neighbor sets, or tag sets, traffic redirection
could be used as part of a more elaborate attack.<a href="#section-8-4.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-8-4.9">/routing-policy/policy-definitions/policy-definition/statements/statement/actions
</dt>
        <dd style="margin-left: 1.5em" id="section-8-4.10">Modification to actions could be used to mount a DoS attack or other
attack. Traffic may be redirected or dropped.  As with prefix sets,
neighbor sets, or tag sets, traffic redirection could be used as part of a
more elaborate attack.  Additionally, route attributes may be changed to mount
a second-level attack that is more difficult to detect.<a href="#section-8-4.10" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-8-5">Some of the readable data nodes in the YANG module may be
        considered sensitive or vulnerable in some network environments.
        It is thus important to control read access (e.g., via get,
        get-config, or notification) to these data nodes. These are the
        subtrees and data nodes and their sensitivity/vulnerability:<a href="#section-8-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-8-6">
        <dt id="section-8-6.1">/routing-policy/defined-sets/prefix-sets
</dt>
        <dd style="margin-left: 1.5em" id="section-8-6.2">Knowledge of these data nodes can be used to ascertain which local
prefixes are susceptible to a DoS attack.<a href="#section-8-6.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-8-6.3">/routing-policy/defined-sets/neighbor-sets
</dt>
        <dd style="margin-left: 1.5em" id="section-8-6.4">Knowledge of these data nodes can be used to ascertain local neighbors
against whom to mount a DoS attack.<a href="#section-8-6.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-8-6.5">/routing-policy/policy-definitions/policy-definition/statements/
</dt>
        <dd style="margin-left: 1.5em" id="section-8-6.6">Knowledge of these data nodes can be used to attack the local router with
a DoS attack.  Additionally, policies and their attendant
conditions and actions should be considered proprietary and disclosure could
be used to ascertain partners, customers, and suppliers. Furthermore, the
policies themselves could represent intellectual property and disclosure could
diminish their corresponding business advantage.<a href="#section-8-6.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-8-7">Routing policy configuration has a significant impact on network
      operations, and as such, other YANG data models that reference routing
      policies are also susceptible to vulnerabilities relating to the YANG
      data nodes specified above.<a href="#section-8-7" class="pilcrow">¶</a></p>
</section>
<section id="section-9">
      <h2 id="name-iana-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-9-1">IANA has registered the following URI in the "ns" subregistry of the  "IETF XML Registry" <span>[<a href="#RFC3688" class="xref">RFC3688</a>]</span>:<a href="#section-9-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-9-2">
        <dt id="section-9-2.1">URI:
</dt>
        <dd style="margin-left: 1.5em" id="section-9-2.2">urn:ietf:params:xml:ns:yang:ietf-routing-policy<a href="#section-9-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-2.3">Registrant Contact:
</dt>
        <dd style="margin-left: 1.5em" id="section-9-2.4">The IESG<a href="#section-9-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-2.5">XML:
</dt>
        <dd style="margin-left: 1.5em" id="section-9-2.6">N/A; the requested URI is an XML namespace.<a href="#section-9-2.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-9-3">IANA has registered the following YANG module in the "YANG Module Names"
       subregistry <span>[<a href="#RFC6020" class="xref">RFC6020</a>]</span> within the "YANG Parameters" registry:<a href="#section-9-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-9-4">
        <dt id="section-9-4.1">Name:
</dt>
        <dd style="margin-left: 1.5em" id="section-9-4.2">ietf-routing-policy<a href="#section-9-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-4.3">Maintained by IANA?
</dt>
        <dd style="margin-left: 1.5em" id="section-9-4.4">N<a href="#section-9-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-4.5">Namespace:
</dt>
        <dd style="margin-left: 1.5em" id="section-9-4.6">urn:ietf:params:xml:ns:yang:ietf-routing-policy<a href="#section-9-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-4.7">Prefix:
</dt>
        <dd style="margin-left: 1.5em" id="section-9-4.8">rt-pol<a href="#section-9-4.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-4.9">Reference:
</dt>
        <dd style="margin-left: 1.5em" id="section-9-4.10">RFC 9067<a href="#section-9-4.10" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
<section id="section-10">
      <h2 id="name-references">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-10.1">
        <h3 id="name-normative-references">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2328">[RFC2328]</dt>
        <dd>
<span class="refAuthor">Moy, J.</span>, <span class="refTitle">"OSPF Version 2"</span>, <span class="seriesInfo">STD 54</span>, <span class="seriesInfo">RFC 2328</span>, <span class="seriesInfo">DOI 10.17487/RFC2328</span>, <time datetime="1998-04" class="refDate">April 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2328">https://www.rfc-editor.org/info/rfc2328</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3101">[RFC3101]</dt>
        <dd>
<span class="refAuthor">Murphy, P.</span>, <span class="refTitle">"The OSPF Not-So-Stubby Area (NSSA) Option"</span>, <span class="seriesInfo">RFC 3101</span>, <span class="seriesInfo">DOI 10.17487/RFC3101</span>, <time datetime="2003-01" class="refDate">January 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3101">https://www.rfc-editor.org/info/rfc3101</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3688">[RFC3688]</dt>
        <dd>
<span class="refAuthor">Mealling, M.</span>, <span class="refTitle">"The IETF XML Registry"</span>, <span class="seriesInfo">BCP 81</span>, <span class="seriesInfo">RFC 3688</span>, <span class="seriesInfo">DOI 10.17487/RFC3688</span>, <time datetime="2004-01" class="refDate">January 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3688">https://www.rfc-editor.org/info/rfc3688</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>, and <span class="refAuthor">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="RFC5130">[RFC5130]</dt>
        <dd>
<span class="refAuthor">Previdi, S.</span>, <span class="refAuthor">Shand, M., Ed.</span>, and <span class="refAuthor">C. Martin</span>, <span class="refTitle">"A Policy Control Mechanism in IS-IS Using Administrative Tags"</span>, <span class="seriesInfo">RFC 5130</span>, <span class="seriesInfo">DOI 10.17487/RFC5130</span>, <time datetime="2008-02" class="refDate">February 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5130">https://www.rfc-editor.org/info/rfc5130</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5302">[RFC5302]</dt>
        <dd>
<span class="refAuthor">Li, T.</span>, <span class="refAuthor">Smit, H.</span>, and <span class="refAuthor">T. Przygienda</span>, <span class="refTitle">"Domain-Wide Prefix Distribution with Two-Level IS-IS"</span>, <span class="seriesInfo">RFC 5302</span>, <span class="seriesInfo">DOI 10.17487/RFC5302</span>, <time datetime="2008-10" class="refDate">October 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5302">https://www.rfc-editor.org/info/rfc5302</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6020">[RFC6020]</dt>
        <dd>
<span class="refAuthor">Bjorklund, M., Ed.</span>, <span class="refTitle">"YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)"</span>, <span class="seriesInfo">RFC 6020</span>, <span class="seriesInfo">DOI 10.17487/RFC6020</span>, <time datetime="2010-10" class="refDate">October 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6020">https://www.rfc-editor.org/info/rfc6020</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6241">[RFC6241]</dt>
        <dd>
<span class="refAuthor">Enns, R., Ed.</span>, <span class="refAuthor">Bjorklund, M., Ed.</span>, <span class="refAuthor">Schoenwaelder, J., Ed.</span>, and <span class="refAuthor">A. Bierman, Ed.</span>, <span class="refTitle">"Network Configuration Protocol (NETCONF)"</span>, <span class="seriesInfo">RFC 6241</span>, <span class="seriesInfo">DOI 10.17487/RFC6241</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6241">https://www.rfc-editor.org/info/rfc6241</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6242">[RFC6242]</dt>
        <dd>
<span class="refAuthor">Wasserman, M.</span>, <span class="refTitle">"Using the NETCONF Protocol over Secure Shell (SSH)"</span>, <span class="seriesInfo">RFC 6242</span>, <span class="seriesInfo">DOI 10.17487/RFC6242</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6242">https://www.rfc-editor.org/info/rfc6242</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6991">[RFC6991]</dt>
        <dd>
<span class="refAuthor">Schoenwaelder, J., Ed.</span>, <span class="refTitle">"Common YANG Data Types"</span>, <span class="seriesInfo">RFC 6991</span>, <span class="seriesInfo">DOI 10.17487/RFC6991</span>, <time datetime="2013-07" class="refDate">July 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6991">https://www.rfc-editor.org/info/rfc6991</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7950">[RFC7950]</dt>
        <dd>
<span class="refAuthor">Bjorklund, M., Ed.</span>, <span class="refTitle">"The YANG 1.1 Data Modeling Language"</span>, <span class="seriesInfo">RFC 7950</span>, <span class="seriesInfo">DOI 10.17487/RFC7950</span>, <time datetime="2016-08" class="refDate">August 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7950">https://www.rfc-editor.org/info/rfc7950</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8040">[RFC8040]</dt>
        <dd>
<span class="refAuthor">Bierman, A.</span>, <span class="refAuthor">Bjorklund, M.</span>, and <span class="refAuthor">K. Watsen</span>, <span class="refTitle">"RESTCONF Protocol"</span>, <span class="seriesInfo">RFC 8040</span>, <span class="seriesInfo">DOI 10.17487/RFC8040</span>, <time datetime="2017-01" class="refDate">January 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8040">https://www.rfc-editor.org/info/rfc8040</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8340">[RFC8340]</dt>
        <dd>
<span class="refAuthor">Bjorklund, M.</span> and <span class="refAuthor">L. Berger, Ed.</span>, <span class="refTitle">"YANG Tree Diagrams"</span>, <span class="seriesInfo">BCP 215</span>, <span class="seriesInfo">RFC 8340</span>, <span class="seriesInfo">DOI 10.17487/RFC8340</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8340">https://www.rfc-editor.org/info/rfc8340</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8341">[RFC8341]</dt>
        <dd>
<span class="refAuthor">Bierman, A.</span> and <span class="refAuthor">M. Bjorklund</span>, <span class="refTitle">"Network Configuration Access Control Model"</span>, <span class="seriesInfo">STD 91</span>, <span class="seriesInfo">RFC 8341</span>, <span class="seriesInfo">DOI 10.17487/RFC8341</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8341">https://www.rfc-editor.org/info/rfc8341</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8342">[RFC8342]</dt>
        <dd>
<span class="refAuthor">Bjorklund, M.</span>, <span class="refAuthor">Schoenwaelder, J.</span>, <span class="refAuthor">Shafer, P.</span>, <span class="refAuthor">Watsen, K.</span>, and <span class="refAuthor">R. Wilton</span>, <span class="refTitle">"Network Management Datastore Architecture (NMDA)"</span>, <span class="seriesInfo">RFC 8342</span>, <span class="seriesInfo">DOI 10.17487/RFC8342</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8342">https://www.rfc-editor.org/info/rfc8342</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8343">[RFC8343]</dt>
        <dd>
<span class="refAuthor">Bjorklund, M.</span>, <span class="refTitle">"A YANG Data Model for Interface Management"</span>, <span class="seriesInfo">RFC 8343</span>, <span class="seriesInfo">DOI 10.17487/RFC8343</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8343">https://www.rfc-editor.org/info/rfc8343</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8349">[RFC8349]</dt>
        <dd>
<span class="refAuthor">Lhotka, L.</span>, <span class="refAuthor">Lindem, A.</span>, and <span class="refAuthor">Y. Qu</span>, <span class="refTitle">"A YANG Data Model for Routing Management (NMDA Version)"</span>, <span class="seriesInfo">RFC 8349</span>, <span class="seriesInfo">DOI 10.17487/RFC8349</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8349">https://www.rfc-editor.org/info/rfc8349</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8446">[RFC8446]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-10.2">
        <h3 id="name-informative-references">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.ietf-idr-bgp-model">[IDR-BGP-MODEL]</dt>
        <dd>
<span class="refAuthor">Jethanandani, M.</span>, <span class="refAuthor">Patel, K.</span>, <span class="refAuthor">Hares, S.</span>, and <span class="refAuthor">J. Haas</span>, <span class="refTitle">"BGP YANG Model for Service Provider Networks"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-idr-bgp-model-09</span>, <time datetime="2020-06-28" class="refDate">28 June 2020</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-09">https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-09</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="W3C.REC-xml11">[W3C.REC-xml11]</dt>
      <dd>
<span class="refAuthor">Bray, T.</span>, <span class="refAuthor">Paoli, J.</span>, <span class="refAuthor">Sperberg-McQueen, M.</span>, <span class="refAuthor">Maler, E.</span>, <span class="refAuthor">Yergeau, F.</span>, and <span class="refAuthor">J. Cowan</span>, <span class="refTitle">"Extensible Markup Language (XML) 1.1 (Second Edition)"</span>, <span class="seriesInfo">W3C Consortium Recommendation REC-xml11-20060816</span>, <time datetime="2006-08-16" class="refDate">16 August 2006</time>, <span>&lt;<a href="https://www.w3.org/TR/2006/REC-xml11-20060816">https://www.w3.org/TR/2006/REC-xml11-20060816</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="augment">
<section id="appendix-A">
      <h2 id="name-routing-protocol-specific-p">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-routing-protocol-specific-p" class="section-name selfRef">Routing Protocol-Specific Policies</a>
      </h2>
<p id="appendix-A-1">
      Routing models that require the ability to apply routing policy
      may augment the routing policy model with protocol or other
      specific policy configuration.  The routing policy model
      assumes that additional defined sets, conditions, and actions
      may all be added by other models.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">
      The example below illustrates how another data 
      model can augment parts of this routing policy data model. It uses 
      specific examples from draft-ietf-idr-bgp-model-09 to show in a 
      concrete manner how the different pieces fit together. This example 
      is not normative with respect to <span>[<a href="#I-D.ietf-idr-bgp-model" class="xref">IDR-BGP-MODEL</a>]</span>. 
      The model similarly augments BGP-specific conditions and actions 
      in the corresponding sections of the routing policy model. In the example below,
      the XPath prefix "bp:" specifies import from the ietf-bgp-policy
      sub-module and the XPath prefix "bt:" specifies import from the ietf-bgp-types
      sub-module <span>[<a href="#I-D.ietf-idr-bgp-model" class="xref">IDR-BGP-MODEL</a>]</span>.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<div id="appendix-A-3">
<pre class="lang-yangtree sourcecode">
module: ietf-routing-policy
  +--rw routing-policy
     +--rw defined-sets
     |  +--rw prefix-sets
     |  |  +--rw prefix-set* [name]
     |  |     +--rw name        string
     |  |     +--rw mode?       enumeration
     |  |     +--rw prefixes
     |  |        +--rw prefix-list* [ip-prefix mask-length-lower
     |  |                            mask-length-upper]
     |  |           +--rw ip-prefix            inet:ip-prefix
     |  |           +--rw mask-length-lower    uint8
     |  |           +--rw mask-length-upper    uint8
     |  +--rw neighbor-sets
     |  |  +--rw neighbor-set* [name]
     |  |     +--rw name       string
     |  |     +--rw address*   inet:ip-address
     |  +--rw tag-sets
     |  |  +--rw tag-set* [name]
     |  |     +--rw name         string
     |  |     +--rw tag-value*   tag-type
     |  +--rw bp:bgp-defined-sets
     |     +--rw bp:community-sets
     |     |  +--rw bp:community-set* [name]
     |     |     +--rw bp:name      string
     |     |     +--rw bp:member*   union
     |     +--rw bp:ext-community-sets
     |     |  +--rw bp:ext-community-set* [name]
     |     |     +--rw bp:name      string
     |     |     +--rw bp:member*   union
     |     +--rw bp:as-path-sets
     |        +--rw bp:as-path-set* [name]
     |           +--rw bp:name      string
     |           +--rw bp:member*   string
     +--rw policy-definitions
        +--ro match-modified-attributes?   boolean
        +--rw policy-definition* [name]
           +--rw name          string
           +--rw statements
              +--rw statement* [name]
                 +--rw name          string
                 +--rw conditions
                 |  +--rw call-policy?
                 |  +--rw source-protocol?          identityref
                 |  +--rw match-interface
                 |  |  +--rw interface?        if:interface-ref
                 |  +--rw match-prefix-set
                 |  |  +--rw prefix-set?       prefix-set/name
                 |  |  +--rw match-set-options?
                 |  |                         match-set-options-type
                 |  +--rw match-neighbor-set
                 |  |  +--rw neighbor-set?
                 |  +--rw match-tag-set
                 |  |  +--rw tag-set?
                 |  |  +--rw match-set-options?
                 |  |                         match-set-options-type
                 |  +--rw match-route-type
                 |     +--rw route-type*     identityref
                 |  +--rw bp:bgp-conditions
                 |     +--rw bp:med-eq?       uint32
                 |     +--rw bp:origin-eq?    bt:bgp-origin-attr-type
                 |     +--rw bp:next-hop-in*  inet:ip-address-no-zone
                 |     +--rw bp:afi-safi-in*  identityref
                 |     +--rw bp:local-pref-eq?  uint32
                 |     +--rw bp:route-type?     enumeration
                 |     +--rw bp:community-count
                 |     +--rw bp:as-path-length
                 |     +--rw bp:match-community-set
                 |     |  +--rw bp:community-set?
                 |     |  +--rw bp:match-set-options?
                 |     +--rw bp:match-ext-community-set
                 |     |  +--rw bp:ext-community-set?
                 |     |  +--rw bp:match-set-options?
                 |     +--rw bp:match-as-path-set
                 |        +--rw bp:as-path-set?
                 |        +--rw bp:match-set-options?
                 +--rw actions
                    +--rw policy-result?         policy-result-type
                    +--rw set-metric
                    |  +--rw metric-modification?
                    |  +--rw metric?                uint32
                    +--rw set-metric-type
                    |  +--rw metric-type?   identityref
                    +--rw set-route-level
                    |  +--rw route-level?   identityref
                    +--rw set-route-preference?        uint16
                    +--rw set-tag?               tag-type
                    +--rw set-application-tag?   tag-type
                    +--rw bp:bgp-actions
                       +--rw bp:set-route-origin?
                       |                    bt:bgp-origin-attr-type
                       +--rw bp:set-local-pref?   uint32
                       +--rw bp:set-next-hop?     bgp-next-hop-type
                       +--rw bp:set-med?          bgp-set-med-type
                       +--rw bp:set-as-path-prepend
                       |  +--rw bp:repeat-n?   uint8
                       +--rw bp:set-community
                       |  +--rw bp:method?      enumeration
                       |  +--rw bp:options?
                       |  +--rw bp:inline
                       |  |  +--rw bp:communities*   union
                       |  +--rw bp:reference
                       |     +--rw bp:community-set-ref?
                       +--rw bp:set-ext-community
                          +--rw bp:method?      enumeration
                          +--rw bp:options?
                          +--rw bp:inline
                          |  +--rw bp:communities*   union
                          +--rw bp:reference
                             +--rw bp:ext-community-set-ref?
</pre><a href="#appendix-A-3" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="examples">
<section id="appendix-B">
      <h2 id="name-policy-examples">
<a href="#appendix-B" class="section-number selfRef">Appendix B. </a><a href="#name-policy-examples" class="section-name selfRef">Policy Examples</a>
      </h2>
<p id="appendix-B-1">
      Below, we show examples of XML-encoded configuration data using
      the routing policy and BGP models to illustrate both how policies
      are defined and how they can be applied.  Note that the XML <span>[<a href="#W3C.REC-xml11" class="xref">W3C.REC-xml11</a>]</span>
      has been simplified for readability.<a href="#appendix-B-1" class="pilcrow">¶</a></p>
<p id="appendix-B-2">The following example shows how prefix set and tag set can be
      defined. The policy condition is to match a prefix set and a
      tag set, and the action is to accept routes that match the condition.<a href="#appendix-B-2" class="pilcrow">¶</a></p>
<div id="appendix-B-3">
<pre class="lang-xml sourcecode">
  &lt;config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
    &lt;routing-policy
     xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy"&gt;

        &lt;defined-sets&gt;
          &lt;prefix-sets&gt;
            &lt;prefix-set&gt;
              &lt;name&gt;prefix-set-A&lt;/name&gt;
              &lt;mode&gt;ipv4&lt;/mode&gt;
              &lt;prefixes&gt;
                &lt;prefix-list&gt;
                  &lt;ip-prefix&gt;192.0.2.0/24&lt;/ip-prefix&gt;
                  &lt;mask-length-lower&gt;24&lt;/mask-length-lower&gt;
                  &lt;mask-length-upper&gt;32&lt;/mask-length-upper&gt;
                &lt;/prefix-list&gt;
                &lt;prefix-list&gt;
                  &lt;ip-prefix&gt;198.51.100.0/24&lt;/ip-prefix&gt;
                  &lt;mask-length-lower&gt;24&lt;/mask-length-lower&gt;
                  &lt;mask-length-upper&gt;32&lt;/mask-length-upper&gt;
                &lt;/prefix-list&gt;
              &lt;/prefixes&gt;
            &lt;/prefix-set&gt;
            &lt;prefix-set&gt;
              &lt;name&gt;prefix-set-B&lt;/name&gt;
              &lt;mode&gt;ipv6&lt;/mode&gt;
                &lt;prefixes&gt;
                &lt;prefix-list&gt;
                  &lt;ip-prefix&gt;2001:DB8::/32&lt;/ip-prefix&gt;
                  &lt;mask-length-lower&gt;32&lt;/mask-length-lower&gt;
                  &lt;mask-length-upper&gt;64&lt;/mask-length-upper&gt;
                &lt;/prefix-list&gt;
              &lt;/prefixes&gt;
            &lt;/prefix-set&gt;
           &lt;/prefix-sets&gt;
           &lt;tag-sets&gt;
            &lt;tag-set&gt;
             &lt;name&gt;cust-tag1&lt;/name&gt;
             &lt;tag-value&gt;10&lt;/tag-value&gt;
           &lt;/tag-set&gt;
         &lt;/tag-sets&gt;
       &lt;/defined-sets&gt;

       &lt;policy-definitions&gt;
        &lt;policy-definition&gt;
          &lt;name&gt;export-tagged-BGP&lt;/name&gt;
          &lt;statements&gt;
            &lt;statement&gt;
              &lt;name&gt;term-0&lt;/name&gt;
              &lt;conditions&gt;
                &lt;match-prefix-set&gt;
                  &lt;prefix-set&gt;prefix-set-A&lt;/prefix-set&gt;
                &lt;/match-prefix-set&gt;
                &lt;match-tag-set&gt;
                  &lt;tag-set&gt;cust-tag1&lt;/tag-set&gt;
                &lt;/match-tag-set&gt;
              &lt;/conditions&gt;
              &lt;actions&gt;
                &lt;policy-result&gt;accept-route&lt;/policy-result&gt;
              &lt;/actions&gt;
            &lt;/statement&gt;
          &lt;/statements&gt;
        &lt;/policy-definition&gt;
      &lt;/policy-definitions&gt;

      &lt;/routing-policy&gt;
&lt;/config&gt;
</pre><a href="#appendix-B-3" class="pilcrow">¶</a>
</div>
<p id="appendix-B-4">In the following example, all routes in the RIB that have been 
        learned from OSPF advertisements corresponding to OSPF 
        intra-area and inter-area route types should get advertised 
        into IS-IS level 2 advertisements.<a href="#appendix-B-4" class="pilcrow">¶</a></p>
<div id="appendix-B-5">
<pre class="lang-xml sourcecode">
&lt;config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
  &lt;routing-policy
   xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy"&gt;
   &lt;policy-definitions&gt;
    &lt;policy-definition&gt;
     &lt;name&gt;export-all-OSPF-prefixes-into-IS-IS-level-2&lt;/name&gt;
      &lt;statements&gt;
       &lt;statement&gt;
         &lt;name&gt;term-0&lt;/name&gt;
         &lt;conditions&gt;
           &lt;match-route-type&gt;
             &lt;route-type&gt;ospf-internal-type&lt;/route-type&gt;
           &lt;/match-route-type&gt;
         &lt;/conditions&gt;
         &lt;actions&gt;
           &lt;set-route-level&gt;
             &lt;route-level&gt;isis-level-2&lt;/route-level&gt;
           &lt;/set-route-level&gt;
           &lt;policy-result&gt;accept-route&lt;/policy-result&gt;
         &lt;/actions&gt;
       &lt;/statement&gt;
      &lt;/statements&gt;
    &lt;/policy-definition&gt;
   &lt;/policy-definitions&gt;
  &lt;/routing-policy&gt;
&lt;/config&gt;
</pre><a href="#appendix-B-5" class="pilcrow">¶</a>
</div>
</section>
</div>
<section id="appendix-C">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-C-1">The routing policy module defined in this document is based on the
      OpenConfig route policy model. The authors would like to thank
      OpenConfig for their contributions, especially those of <span class="contact-name">Anees Shaikh</span>, <span class="contact-name">Rob Shakir</span>, <span class="contact-name">Kevin D'Souza</span>, and <span class="contact-name">Chris Chase</span>.<a href="#appendix-C-1" class="pilcrow">¶</a></p>
<p id="appendix-C-2">The authors are grateful for valuable contributions to this document
      and the associated models from <span class="contact-name">Ebben Aires</span>,
      <span class="contact-name">Luyuan Fang</span>, <span class="contact-name">Josh George</span>,
      <span class="contact-name">Stephane Litkowski</span>, <span class="contact-name">Ina       Minei</span>, <span class="contact-name">Carl Moberg</span>, <span class="contact-name">Eric       Osborne</span>, <span class="contact-name">Steve Padgett</span>, <span class="contact-name">Juergen Schoenwaelder</span>, <span class="contact-name">Jim Uttaro</span>,
      <span class="contact-name">Russ White</span>, and <span class="contact-name">John       Heasley</span>.<a href="#appendix-C-2" class="pilcrow">¶</a></p>
<p id="appendix-C-3">Thanks to <span class="contact-name">Mahesh Jethanandani</span>, <span class="contact-name">John Scudder</span>, <span class="contact-name">Alvaro Retana</span>, <span class="contact-name">Chris Bowers</span>, 
      <span class="contact-name">Tom Petch</span>, and <span class="contact-name">Kris Lambrechts</span> for their reviews and comments.<a href="#appendix-C-3" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="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">Yingzhen Qu</span></div>
<div dir="auto" class="left"><span class="org">Futurewei</span></div>
<div dir="auto" class="left"><span class="street-address">2330 Central Expressway</span></div>
<div dir="auto" class="left">
<span class="locality">Santa Clara</span>, <span class="region">CA</span> <span class="postal-code">95050</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:yingzhen.qu@futurewei.com" class="email">yingzhen.qu@futurewei.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jeff Tantsura</span></div>
<div dir="auto" class="left"><span class="org">Microsoft</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jefftant.ietf@gmail.com" class="email">jefftant.ietf@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Acee Lindem</span></div>
<div dir="auto" class="left"><span class="org">Cisco</span></div>
<div dir="auto" class="left"><span class="street-address">301 Midenhall Way</span></div>
<div dir="auto" class="left">
<span class="locality">Cary</span>, <span class="region">NC</span> <span class="postal-code">27513</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:acee@cisco.com" class="email">acee@cisco.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Xufeng Liu</span></div>
<div dir="auto" class="left"><span class="org">Volta Networks</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:xufeng.liu.ietf@gmail.com" class="email">xufeng.liu.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>