<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.17 (Ruby 2.6.10) -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-opsawg-sbom-access-18" docName="draft-ietf-opsawg-sbom-access-1htmlwdiff 8" number="9472" submissionType="IETF" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" updates="" obsoletes="" xml:lang="en" version="3">

  <front>
    <title abbrev="Discovering abbrev="A YANG Data Model for SBOMs and &amp; Vuln. Info">Discovering and Retrieving Info">A YANG Data
    Model for Reporting Software Transparency Bills of Materials (SBOMs) and Vulnerability
    Information</title>
    <seriesInfo name="RFC" value="9472"/>
    <author initials="E." surname="Lear" fullname="Eliot Lear">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>Richtistrasse 7</street>
          <city>Wallisellen</city>
          <code>CH-8304</code>
          <code>8304</code>
          <country>Switzerland</country>
        </postal>
        <phone>+41 44 878 9200</phone>
        <email>lear@cisco.com</email>
      </address>
    </author>
    <author initials="S." surname="Rose" fullname="Scott Rose">
      <organization>NIST</organization>
      <address>
        <postal>
          <street>100 Bureau Dr</street>
          <city>Gaithersburg MD</city> Dr.</street>
          <city>Gaithersburg</city>
	  <region>MD</region>
          <code>20899</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone>+1 301-975-8439</phone>
        <email>scott.rose@nist.gov</email>
      </address>
    </author>
    <date year="2023" month="April" day="28"/>

    <keyword>Internet-Draft</keyword> month="October"/>
    <area>ops</area>
    <workgroup>opsawg</workgroup>
    <keyword>sbom</keyword>
    <keyword>discovery</keyword>
    <keyword>mud</keyword>
    <keyword>vex</keyword>
    <keyword>chaff</keyword>

    <abstract>
      <t>To improve cybersecurity posture, automation is necessary to locate
      the software a device is using, and whether that software has known
      vulnerabilities, and what, if any any, recommendations suppliers may have.
      This memo extends the MUD Manufacturer User Description (MUD) YANG schema to
      provide the locations of software bills of materials (SBOMS) (SBOMs) and to
      vulnerability information by introducing a transparency schema.</t>
    </abstract>
  </front>
  <middle>

    <section anchor="introduction"><name>Introduction</name> anchor="introduction">
      <name>Introduction</name>
      <t>A number of activities have been working taken place to improve the visibility to of
      what software is running on a system, system and what vulnerabilities that
      software may have <xref target="EO2021"/>.</t>
      <t>Put simply, this memo seeks to answer two classes of questions to the
scale of for
      tens of thousands of devices and a large variety of types of
devices. device types.  Those
      questions are as the following:</t>

<t><list style="symbols">
  <t>Is follows:</t>
      <ul spacing="normal">
        <li>Is this system vulnerable susceptible to a particular vulnerability?</t>
  <t>Which vulnerability?</li>
        <li>Which devices in a particular environment contain vulnerabilities
        that require some action?</t>
</list></t> action?</li>
      </ul>
      <t>This memo doesn't specify the format of this information, information but rather
      only how to locate and retrieve these objects.  That is, the model is
      intended to facilitate discovery, discovery and on its own provides no access to
      the underlying data.</t>
      <t>Software bills of materials (SBOMs) are descriptions of what
      software, including versioning and dependencies, a device contains.
      There are different SBOM formats such as Software Package Data Exchange
      <xref target="SPDX"/> or CycloneDX<xref target="CycloneDX12"/>.</t> CycloneDX <xref target="CycloneDX15"/>.</t>
      <t>System vulnerabilities may similarly be similarly described using several data
      formats, including the aforementioned CycloneDX, the Common Vulnerability
      Reporting Framework <xref target="CVRF"/>, and the Common Security Advisory
      Format <xref target="CSAF"/>.  This information is typically used to
      report to
administrators the state of any known vulnerabilities on a system.</t> system to administrators.</t>

      <t>SBOM and vulnerability information can be used in concert with other
      sources of vulnerability information.  For a  A network management tool could
      discover that a system makes use of uses a particular set of software components,
      searches a national vulnerability database to determine known
      vulnerabilities, and then applies information provided by the manufacturer
      through this mechanism to produce a vulnerability report.  That report
      may be used to indicate what what, if any any, versions of software correct that vulnerability,
      vulnerability or whether the system exercises the vulnerable code at
      all.</t>
      <t>Both classes of information elements are optional under the model
specified in this memo.  One can provide only an SBOM, only
vulnerability information, or both an SBOM and vulnerability
information.</t>
      <t>Note that SBOM formats may also carry other information, the most
common being any licensing terms.  Because this specification is
neutral regarding content, it is left for format developers such as
the Linux Foundation, OASIS, and ISO to decide what attributes they
will support.</t>
      <t>This memo does not specify how vulnerability information may be
retrieved directly from the endpoint.  That's  That is because vulnerability
information changes occur at different rates to software updates. updates at different rates.
However, some SBOM formats may also contain vulnerability information.</t>
      <t>SBOMs and vulnerability information are advertised and retrieved
through the use of a YANG augmentation of the Manufacturer User
Description (MUD) model <xref target="RFC8520"/>.  Note that the schema creates a
grouping that can also be used independently of MUD.  Moreover, other
MUD features, such as access controls, needn't be present.</t>
      <t>The mechanisms specified in this document are meant to address two
use cases:</t>

<t><list style="symbols">
  <t>A
      <ul spacing="normal">
        <li>A network-layer management system retrieving information from an IoT
        Internet of Things (IoT) device as part of its ongoing lifecycle. life
        cycle. Such devices may or may not have query interfaces available.</t>
  <t>An
        available.</li>
        <li>An application-layer management system retrieving vulnerability or
        SBOM information in order to evaluate the posture of an application
        server of some form.  These application servers may themselves be
        containers or hypervisors.  Discovery of the topology of a server is
        beyond the scope of this memo.</t>
</list></t> memo.</li>
      </ul>
      <t>To satisfy these two key use cases, objects may be found in one of
three methods:</t>

<t><list style="symbols">
  <t>on
      <ol spacing="normal">
        <li>on the devices themselves</t>
  <t>on themselves</li>
        <li>on a website (e.g., via URI)</t>
  <t>through a URI)</li>
        <li>through some form of out-of-band contact with the supplier.</t>
</list></t> supplier</li>
      </ol>
      <t>Using the first method, devices will have interfaces that permit
      direct retrieval.  Examples of these interfaces might be an HTTP <xref target="RFC9110"/>,
      target="RFC9110"/> or COAP Constrained Application Protocol (CoAP) <xref
      target="RFC7252"/> endpoint for retrieval.  There may also be private
      interfaces as well.</t>
      <t>Using the second method, when a device does not have an appropriate
      retrieval interface, but one is directly available from the
      manufacturer, a URI to that information is discovered through interfaces
      such as MUD via DHCP or bootstrapping and ownership transfer
      mechanisms.</t>
      <t>Using the third method, a supplier may wish to make an SBOM or
      vulnerability information available under certain circumstances, circumstances and may
      need to individually evaluate requests.  The result of that evaluation
      might be the SBOM or SBOM, the vulnerability itself or itself, a restricted
URL URL, or no
      access.</t>
      <t>To enable application-layer discovery, this memo defines a well-known
      URI <xref target="RFC8615"/>.  Management or orchestration tools can
      query this well-known URI to retrieve a system's SBOM information.
      Further queries may be necessary based on the content and structure of
      the response.</t>

<t>The

      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
        "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
        NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
        "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
        "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
        are to be interpreted as described in BCP 14 BCP&nbsp;14 <xref
        target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
        appear in all capitals, as shown here.</t> here.
        </t>
      </section>
      <section anchor="how-this-information-is-retrieved"><name>How anchor="how-this-information-is-retrieved">
        <name>How This Information Is is Retrieved</name>

<t>Section 4
        <t><xref target="the-mud-sbom-augmentation-to-the-mud-yang-model"/>
        describes a data model to extend the MUD file format to carry SBOM and
        vulnerability information.  Section 1.5 of RFC8520 <xref target="RFC8520" sectionFormat="of"
        section="1.5"/> describes mechanisms by which devices can emit a URL
        to point to this file.  Additionally, devices can share this URL
        either through documentation or within a QR code on a box.
Section 2  <xref
        target="the-well-known-transparency-endpoint-set"/> describes a
        well-known URL from which an SBOM could be served from the local
        device.</t>
        <t>Note that vulnerability and SBOM information are likely to change
        at different rates.  MUD's cache-validity node provides a way for
        manufacturers to control how often tooling should check for those
        changes through the cache-validity node.</t>
      </section>
      <section anchor="formats"><name>Formats</name> anchor="formats">
        <name>Formats</name>
        <t>There are multiple ways to express both SBOMs and vulnerability
        information.  When these are retrieved either from the device or from
        a remote web server, tools will need to observe the Content-Type
        header to determine precisely which format is being transmitted.
        Because IoT devices in particular have limited capabilities, use of a
        specific Accept: header in HTTP or the Accept Option in CoAP is NOT RECOMMENDED.
        <bcp14>NOT RECOMMENDED</bcp14>.  Instead, backend tooling is
        encouraged to support all known formats, formats and SHOULD <bcp14>SHOULD</bcp14>
        silently discard SBOM information sent with a media type that is not
        understood.</t>
        <t>If multiple SBOMs are intended to be supported in the same file,
        the media type should properly reflect that.  For example, one might
        make use of application/{someformat}+json-seq.  It is left to those
        supporting those formats to make the appropriate registrations in this
        case.</t>
        <t>Some formats may support both vulnerability and software inventory
        information.  When both vulnerability and software inventory
        information is available from the same URL, both sbom-url and members
        of the vuln-url list MUST <bcp14>MUST</bcp14> indicate that. Network
        management systems
retrieving this information MUST <bcp14>MUST</bcp14> take note that of when the identical SBOM and
        vulnerability information are accessible via the same resource
is being retrieved rather than retrieving it twice.</t> and not
        retrieve the resource a second time.</t>
      </section>
    </section>
    <section anchor="the-well-known-transparency-endpoint-set"><name>The well-known transparency endpoint set</name> anchor="the-well-known-transparency-endpoint-set">
      <name>The Well-Known Transparency Endpoint Set</name>
      <t>A well-known endpoint is defined:</t>

<t><list style="symbols">
  <t>"/.well-known/sbom"
        <t indent="3">"/.well-known/sbom" retrieves an SBOM.</t>
</list></t> SBOM
      </t>
      <t>As discussed previously, the precise format of a response is based on
the Content-type Content-Type provided.</t>
    </section>
    <section anchor="the-mud-transparency-extension-model-extension"><name>The anchor="the-mud-transparency-extension-model-extension">
      <name>The mud-transparency extension model extension</name> Extension</name>
      <t>We now formally define the mud-transparency extension; this extension.  This is done in two parts.
First, parts.</t>
      <t>First, the extension name "transparency" is listed in the
      "extensions" array of the MUD file.  N.B.,  Note that this schema extension is
      intended to be used wherever it might be appropriate (e.g., not just
      with MUD).</t>
      <t>Second, the "mud" container is augmented with a list of SBOM sources.</t>
      <t>This is done as follows:</t>

<figure><artwork><![CDATA[
      <sourcecode type="yangtree"><![CDATA[
module: ietf-mud-transparency

  augment /mud:mud:
    +--rw transparency
       +--rw (sbom-retrieval-method)?
       |  +--:(cloud)
       |  |  +--rw sboms* [version-info]
       |  |     +--rw version-info    string
       |  |     +--rw sbom-url?       inet:uri
       |  +--:(local-well-known)
       |  |  +--rw sbom-local-well-known?   identityref
       |  +--:(sbom-contact-info)
       |     +--rw sbom-contact-uri?        inet:uri
       +--rw sbom-archive-list?             inet:uri
       +--rw (vuln-retrieval-method)?
          +--:(cloud)
          |  +--rw vuln-url*                inet:uri
          +--:(vuln-contact-info)
             +--rw vuln-contact-uri?        inet:uri
]]></artwork></figure>
]]></sourcecode>

      <t>See <xref target="RFC8340"/> for a description of YANG trees.</t>

    </section>
    <section anchor="the-mud-sbom-augmentation-to-the-mud-yang-model"><name>The anchor="the-mud-sbom-augmentation-to-the-mud-yang-model">

      <name>The mud-sbom augmentation Augmentation to the MUD YANG model</name>

<figure><artwork><![CDATA[
<CODE BEGINS>file "ietf-mud-transparency@2023-01-12.yang" Data Model</name>

      <t>This YANG module references <xref target="RFC6991"
      format="default"/>, <xref target="RFC7231" format="default"/>, <xref
      target="RFC7252" format="default"/>, <xref target="RFC8520"
      format="default"/>, and <xref target="RFC9110" format="default"/>.</t>

      <sourcecode name="ietf-mud-transparency@2023-09-08.yang" type="yang" markers="true"><![CDATA[
module ietf-mud-transparency {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-mud-transparency";
  prefix mudtx;

  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991"; 6991: Common YANG Data Types";
  }
  import ietf-mud {
    prefix mud;
    reference
      "RFC 8520"; 8520: Manufacturer Usage Description Specification";
  }

  organization
    "IETF OPSAWG (Ops Area) Working Group";
  contact
    "WG Web: https://datatracker.ietf.org/wg/opsawg/ <https://datatracker.ietf.org/wg/opsawg/>
     WG List: opsawg@ietf.org <opsawg@ietf.org>

     Editor: Eliot Lear lear@cisco.com <lear@cisco.com>
     Editor: Scott Rose scott.rose@nist.gov"; <scott.rose@nist.gov>";
  description
    "This YANG module augments the ietf-mud model to provide for
     reporting of SBOMs and vulnerability information.

     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) 2023 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 Revised 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 XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); 9472
     (https://www.rfc-editor.org/info/rfc9472);
     see the RFC itself for full legal notices.

     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.  "; notices.";

  revision 2023-01-12 2023-09-08 {
    description
      "Initial proposed standard.";
    reference
      "RFC XXXX: Discovering and Retrieving 9472: A YANG Data Model for Reporting Software Transparency Bills
       of Materials (SBOMs) and Vulnerability Information";
  }

  identity local-type {
    description
      "Base identity for local-well-known choices"; local well-known choices.";
  }

  identity http {
    base mudtx:local-type;
    description
      "Use http[RFC7231] http (RFC 7231) (insecure) to retrieve SBOM information.
        This method is NOT RECOMMENDED, RECOMMENDED but may be unavoidable for
        certain classes of deployment, deployment where TLS has not or
        cannot be implemented"; implemented.";
      reference
         "RFC 7231: Hypertext Transfer Protocol (HTTP/1.1):
          Semantics and Content";
  }

  identity https {
    base mudtx:local-type;
    description
      "Use https (secure) to retrieve SBOM information.  See
       RFC 9110.";
      reference
         "RFC 9110: HTTP Semantics";
  }

  identity coap {
    base mudtx:local-type;
    description
      "Use COAP [RFC7252] (RFC 7252) (insecure) to retrieve SBOM.  This method
       is NOT RECOMMENDED, although it may be unavoidable
       for certain classes of implementations/deployments.";
      reference
         "RFC 7252: The Constrained Application Protocol (CoAP)";
  }

  identity coaps {
    base mudtx:local-type;
    description
      "Use COAPS (secure) to retrieve SBOM [RFC7252]"; (RFC 7252).";
  }

  grouping transparency-extension {
    description
      "This grouping provides a means to describe the location of
       software bills of material and vulnerability descriptions.";
    container transparency {
      description
        "Container of methods to get SBOMs and vulnerability
         information.";
      choice sbom-retrieval-method {
        description
          "How to find SBOM information"; information.";
        case cloud {
          list sboms {
            key "version-info";
            description
              "A list of SBOMs tied to different software
               or hardware versions.";
            leaf version-info {
              type string;
              description
                "The version to which this SBOM refers.";
            }
            leaf sbom-url {
              type inet:uri {
                pattern '((coaps?)|(https?)):.*';
              }
              description
                "A statically located URL.";
            }
          }
        }
        case local-well-known {
          leaf sbom-local-well-known {
            type identityref {
              base mudtx:local-type;
            }
            description
              "Which communication protocol to choose.";
          }
        }
        case sbom-contact-info {
          leaf sbom-contact-uri {
            type inet:uri {
              pattern '((mailto)|(https?)|(tel)):.*';
            }
            description
              "This MUST be either a tel, an http, an https, or
               a mailto uri schema that customers can use to
               contact someone for SBOM information.";
          }
        }
      }
      leaf sbom-archive-list {
        type inet:uri;
        description
          "This URI returns a JSON list of URLs that consist of
           SBOMs that were previously published for this
           device.  Publication dates can be found inside
           the SBOMs.";
      }
      choice vuln-retrieval-method {
        description
          "How to find vulnerability information"; information.";
        case cloud {
          leaf-list vuln-url {
            type inet:uri;
            description
              "List of statically located URLs that reference
               vulnerability information"; information.";
          }
        }
        case vuln-contact-info {
          leaf vuln-contact-uri {
            type inet:uri {
              pattern '((mailto)|(https?)|(tel)):.*';
            }
            description
              "This MUST be either a tel, an http, an https, or
               a mailto uri schema that customers can use to
               contact someone for vulnerability information.";
          }
        }
      }
    }
  }

  augment "/mud:mud" {
    description
      "Add extension for software transparency.";
    uses transparency-extension;
  }
}
<CODE ENDS>
]]></artwork></figure>
]]></sourcecode>

    </section>
    <section anchor="examples"><name>Examples</name> anchor="examples">
      <name>Examples</name>
      <t>In this example MUD file that uses a cloud service, the modelX
      presents a location of the SBOM in a URL.  Note,  Note that the ACLs Access Control
      Lists (ACLs) in a MUD file are NOT required, although they are a very
      good idea for IP-based devices.</t>
      <section anchor="without-acls"><name>Without anchor="without-acls">
        <name>Without ACLS</name>
        <t>This first MUD file demonstrates how to get SBOM and
vulnerability information without ACLs.</t>

<figure><artwork><![CDATA[

        <sourcecode type="json"><![CDATA[
{
 "ietf-mud:mud": {
   "mud-version": 1,
   "extensions": [
     "transparency"
   ],
   "mudtx:transparency": {
     sboms: [ {
     "version-info": "1.2",
     "sbom-url": "https://iot.example.com/info/modelX/sbom.json", "https://iot.example.com/info/modelX/sbom.json"
     } ],
     "vuln-url" : [
       "https://iotd.example.com/info/modelX/csaf.json"
     ]
   },
   "mud-url": "https://iot.example.com/modelX.json",
   "mud-signature": "https://iot.example.com/modelX.p7s",
   "last-update": "2022-01-05T13:29:12+00:00",
   "cache-validity": 48,
   "is-supported": true,
   "systeminfo": "retrieving vuln and SBOM info via a cloud service",
   "mfg-name": "Example, Inc.",
   "documentation": "https://iot.example.com/doc/modelX",
   "model-name": "modelX"
 }
}
]]></artwork></figure>
}]]></sourcecode>

        <t>The second example demonstrates that just SBOM information is
        included from the cloud.</t>

<figure><artwork><![CDATA[

        <sourcecode type="json"><![CDATA[
{
 "ietf-mud:mud": {
   "mud-version": 1,
   "extensions": [
     "transparency"
   ],
   "mudtx:transparency": {
     sboms: [ {
     "version-info": "1.2",
     "sbom-url": "https://iot.example.com/info/modelX/sbom.json"
     } ],
   },
   "mud-url": "https://iot.example.com/modelX.json",
   "mud-signature": "https://iot.example.com/modelX.p7s",
   "last-update": "2022-01-05T13:29:12+00:00",
   "cache-validity": 48,
   "is-supported": true,
   "systeminfo": "retrieving only vuln and SBOM info via a cloud service",
   "mfg-name": "Example, Inc.",
   "documentation": "https://iot.example.com/doc/modelX",
   "model-name": "modelX"
 }
}
]]></artwork></figure>
}]]></sourcecode>
      </section>
      <section anchor="sbom-located-on-the-device"><name>SBOM anchor="sbom-located-on-the-device">
        <name>SBOM Located on the Device</name>
        <t>In the next example, the SBOM is located on the device, and there
        is no vulnerability information provided.</t>

<figure><artwork><![CDATA[

        <sourcecode type="json"><![CDATA[
{
  "ietf-mud:mud": {
    "mud-version": 1,
    "extensions": [
      "transparency"
    ],
    "mudtx:transparency": {
      "sbom-local-well-known": "https"
    },
    "mud-url": "https://iot.example.com/modelX.json",
    "mud-signature": "https://iot.example.com/modelX.p7s",
    "last-update": "2022-01-05T13:29:47+00:00",
    "cache-validity": 48,
    "is-supported": true,
    "systeminfo": "retrieving SBOM info from a local source",
    "mfg-name": "Example, Inc.",
    "documentation": "https://iot.example.com/doc/modelX",
    "model-name": "modelX"
  }
}
]]></artwork></figure>
}]]></sourcecode>

        <t>In this example, the SBOM is retrieved from the device, while
vulnerability information is available from the cloud.  This is likely
a common case, case because vendors may learn of vulnerability information
more frequently than they update software.</t>

<figure><artwork><![CDATA[

        <sourcecode type="json"><![CDATA[
{
 "ietf-mud:mud": {
   "mud-version": 1,
   "extensions": [
     "transparency"
   ],
   "mudtx:transparency": {
     "sbom-local-well-known": "https",
     "vuln-url" : [
       "https://iotd.example.com/info/modelX/csaf.json"
     ]
   },
   "mud-url": "https://iot-device.example.com/modelX.json",
   "mud-signature": "https://iot-device.example.com/modelX.p7s",
   "last-update": "2022-01-05T13:25:14+00:00",
   "cache-validity": 48,
   "is-supported": true,
   "systeminfo": "mixed example: SBOM on device, vuln info in cloud",
   "mfg-name": "Example, Inc.",
   "documentation": "https://iot-device.example.com/doc/modelX",
   "model-name": "modelX"
 }
}
]]></artwork></figure>
}]]></sourcecode>

      </section>
      <section anchor="further-contact-required"><name>Further contact required.</name> anchor="further-contact-required">
        <name>Further Contact Required</name>
        <t>In this example, the network manager must take further steps
to retrieve SBOM information.  Vulnerability information is
still available.</t>

<figure><artwork><![CDATA[

        <sourcecode type="json"><![CDATA[
{
"ietf-mud:mud": {
"mud-version": 1,
"extensions": [
  "transparency"
],
  "ietf-mud-transparency:transparency":
"mudtx:transparency": {
  "contact-info": "https://iot-device.example.com/contact-info.html",
    "vuln-url" : [
      "https://iotd.example.com/info/modelX/csaf.json"
    ]
},
"mud-url": "https://iot-device.example.com/modelX.json",
"mud-signature": "https://iot-device.example.com/modelX.p7s",
"last-update": "2021-07-09T06:16:42+00:00",
"cache-validity": 48,
"is-supported": true,
"systeminfo": "retrieving vuln and SBOM info via a cloud service",
"mfg-name": "Example, Inc.",
"documentation": "https://iot-device.example.com/doc/modelX",
"model-name": "modelX"
}
}
]]></artwork></figure>
}]]></sourcecode>

      </section>
      <section anchor="with-acls"><name>With anchor="with-acls">
        <name>With ACLS</name>
        <t>Finally, here is a complete example where the device provides
SBOM and vulnerability information, information as well as access-control access control
information.</t>

<figure><artwork><![CDATA[

        <sourcecode type="json"><![CDATA[
{
 "ietf-mud:mud": {
   "mud-version": 1,
   "extensions": [
     "transparency"
   ],
   "mudtx:transparency": {
     "sbom-local-well-known": "https",
     "vuln-url" : [
       "https://iotd.example.com/info/modelX/csaf.json"
     ]
   },
   "mud-url": "https://iot.example.com/modelX.json",
   "mud-signature": "https://iot.example.com/modelX.p7s",
   "last-update": "2022-01-05T13:30:31+00:00",
   "cache-validity": 48,
   "is-supported": true,
   "systeminfo": "retrieving vuln and SBOM info via a cloud service",
   "mfg-name": "Example, Inc.",
   "documentation": "https://iot.example.com/doc/modelX",
   "model-name": "modelX",
   "from-device-policy": {
     "access-lists": {
       "access-list": [
         {
           "name": "mud-65443-v4fr"
         }
       ]
     }
   },
   "to-device-policy": {
     "access-lists": {
       "access-list": [
         {
           "name": "mud-65443-v4to"
         }
       ]
     }
   }
 },
 "ietf-access-control-list:acls": {
   "acl": [
     {
       "name": "mud-65443-v4to",
       "type": "ipv4-acl-type",
       "aces": {
         "ace": [
           {
             "name": "cl0-todev",
             "matches": {
               "ipv4": {
                 "ietf-acldns:src-dnsname": "iotserver.example.com"
               }
             },
             "actions": {
               "forwarding": "accept"
             }
           }
         ]
       }
     },
     {
       "name": "mud-65443-v4fr",
       "type": "ipv4-acl-type",
       "aces": {
         "ace": [
           {
             "name": "cl0-frdev",
             "matches": {
               "ipv4": {
                 "ietf-acldns:dst-dnsname": "iotserver.example.com"
               }
             },
             "actions": {
               "forwarding": "accept"
             }
           }
         ]
       }
     }
   ]
 }
}

]]></artwork></figure>
}]]></sourcecode>

        <t>At this point, the management system can attempt to retrieve the
        SBOM,
and determine which format is in use through the content-type Content-Type
        header on the response to a GET request, independently repeat the
        process for vulnerability information, and apply ACLs, ACLs as
        appropriate.</t>
      </section>
    </section>

    <section anchor="security-considerations"><name>Security anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document describes a schema for discovering the location of
      information relating to software transparency, transparency and does not specify the
      access model for the information itself.  In particular, the YANG module
      specified in this document is not necessarily intended to be accessed
      via regular network management protocols, such as the NETCONF <xref target="RFC6241"></xref> target="RFC6241"/> or RESTCONF
      <xref target="RFC8040"></xref>, target="RFC8040"/>, and hence the regular security considerations
      for such usage are not considered here.</t>

<t>We
      <t>Below, we describe below protections relating to both discovery and some
      advice on protecting the underlying SBOM/vulnerability SBOM and vulnerability
      information.</t>
      <t>The model specifies both encrypted and unencrypted means to retrieve
      information.  This is a matter of pragmatism.  Unencrypted
      communications allow for manipulation of information being retrieved.
      Therefore, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that implementations offer a
      means to configure endpoints so that they may make use of TLS or
      DTLS.</t>
      <t>The ietf-mud-transparency module has no operational impact on the
      element itself, itself and is used to discover state information that may be
      available on or off the element.  In as much as the module itself is
      made writeable, this only indicates a change in how to retrieve
      read-only elements.  There is are no means, for instance, to upload an SBOM.
      Additional risks are discussed below, below and are applicable to all nodes
      within the transparency container.</t>
      <t>If an attacker modifies the elements, they may misdirect automation
      to retrieve a different set of URLs than was intended by the designer.
      This in turn leads to two specific sets of risks:</t>

<t><list style="symbols">
  <t>the
      <ul spacing="normal">
        <li>the information retrieved would be false.</t>
  <t>the false</li>
        <li>the URLs themselves point to malware.</t>
</list></t> malware</li>
      </ul>

      <t>To address either risk, of these risks or any change in tampering of a URL, and in particular to the
authority section, two approaches may be used:</t>

<t><list style="symbols">
  <t>test URL:</t>
      <ul spacing="normal">
        <li>test any cloud-based URL against a reputation service.</t>
  <t>provide service</li>
        <li>provide the administrator an opportunity to approve further procesisng
        processing when the authority changes to one not known to be reputable.</t>
</list></t>
        reputable</li>
      </ul>
      <t>SBOMs provide an inventory of software.  Knowledge of which specific
      software is loaded on a system can aid an attacker in identifying an
      appropriate exploit for a known vulnerability or guide the development
      of novel exploit against this system.  However, if software is available
      to an attacker, the attacker may well already be able to derive this
      very same software inventory.  When this information resides on the
      endpoint itself, the endpoint SHOULD NOT <bcp14>SHOULD NOT</bcp14> provide
      unrestricted access to the well-known URL by default.</t>
      <t>Other servers that offer the data MAY <bcp14>MAY</bcp14> restrict access
      to SBOM information using appropriate authorization semantics within
      HTTP.  One way to do this would be to issue a certificate to the client
      for this purpose after a registration process has taken place.  Another
      approach would involve the use of OAUTH OAuth in combination.  In particular,
      if a system attempts to retrieve an SBOM via HTTP or COAP CoAP and the client
      is not authorized, the server MUST <bcp14>MUST</bcp14> produce an appropriate error,
      error with instructions on how to register a particular client.</t>
      <t>Another risk is a skew in the SBOM listing and the actual software
      inventory of a device/container. For example, a manufacturer may update
      the SBOM on its server, but an individual device has not been upgraded
      yet.  This may result in an incorrect policy being applied to a
      device. A unique mapping of a device's software version and its SBOM can
      minimize this risk.</t>
      <t>To further mitigate attacks against a device, manufacturers SHOULD
      <bcp14>SHOULD</bcp14> recommend network access controls.</t>
      <t>Vulnerability information is generally made available to such
      databases as NIST's National Vulnerability Database <xref
      target="NISTNVD"/>.  It is possible that vendors may wish to release
      information early to some customers.  We do not discuss here whether
      that is a good idea, but if it is employed, then appropriate access
      controls and authorization
SHOULD <bcp14>SHOULD</bcp14> be applied to that
      information.</t>
    </section>

    <section anchor="iana-considerations"><name>IANA anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="mud-extension"><name>MUD anchor="mud-extension">
        <name>MUD Extension</name>

<t>The IANA is requested to add
        <t>IANA has added "transparency" to the MUD
extensions "MUD Extensions"
        registry <xref target="RFC8520"/> as follows:</t>

<figure><artwork><![CDATA[
  Extension Name: transparency
  Standard reference: This document

]]></artwork></figure>
         <dl newline="false" spacing="compact">
	   <dt>Value:</dt>
	   <dd>transparency</dd>
	   <dt>Reference:</dt>
	   <dd>RFC 9472</dd>
	 </dl>
      </section>
      <section anchor="yang-registration"><name>YANG anchor="yang-registration">
        <name>YANG Registration</name>

<t>The

<t>IANA has registered the following YANG module should be registered in the "YANG Module
Names" registry:</t>

<figure><artwork><![CDATA[
   Name: ietf-mud
   URN: urn:ietf:params:xml:ns:yang:ietf-mud-transparency
   Prefix: mudtx
   Registrant contact: The IESG
   Reference: This memo
]]></artwork></figure> registry <xref target="RFC6020"/>:</t>
         <dl newline="false" spacing="compact">
	   <dt>Name:</dt>
	   <dd>ietf-mud-transparency</dd>
	   <dt>Namespace:</dt>
	   <dd>urn:ietf:params:xml:ns:yang:ietf-mud-transparency</dd>
	   <dt>Maintained by IANA:</dt>
	   <dd>N</dd>
	   <dt>Prefix:</dt>
	   <dd>mudtx</dd>
	   <dt>Reference:</dt>
	   <dd>RFC 9472</dd>
	 </dl>

        <t>The following URI has been registered in the "IETF XML registration is requested:</t>

<figure><artwork><![CDATA[
   URI: urn:ietf:params:xml:ns:yang:ietf-mud-transparency
   Registrant Contact: IESG
   XML: None. Registry" <xref target="RFC3688"/>:</t>
         <dl newline="false" spacing="compact">
	   <dt>URI:</dt>
	   <dd>urn:ietf:params:xml:ns:yang:ietf-mud-transparency</dd>
	   <dt>Registrant Contact:</dt>
	   <dd>IESG</dd>
	   <dt>XML:</dt>
	   <dd>None.  Namespace URIs do not represent an XML specification.
]]></artwork></figure> specification.</dd>
	 </dl>

      </section>
      <section anchor="well-known-prefix"><name>Well-Known anchor="well-known-prefix">
        <name>Well-Known Prefix</name>

<t>The
        <t>IANA has added the following well known URI is requested suffix to the "Well-Known URIs" registry
	in accordance with <xref target="RFC8615"/>:</t>

<figure><artwork><![CDATA[
  URI suffix: "sbom"
  Change controller: "IETF"
  Specification document: This memo
  Related information:  See
         <dl newline="false" spacing="compact">
	   <dt>URI Suffix:</dt>
	   <dd>sbom</dd>
	   <dt>Change Controller:</dt>
	   <dd>IETF</dd>
	   <dt>Reference:</dt>
	   <dd>RFC 9472</dd>
	   <dt>Status:</dt>
	   <dd>permanent</dd>
	   <dt>Related Information:</dt>
	   <dd>See ISO/IEC 5962:2021 and SPDX.org

]]></artwork></figure> SPDX.org</dd>
	 </dl>

      </section>
    </section>
<section anchor="acknowledgments"><name>Acknowledgments</name>

<t>Thanks to Russ Housley, Dick Brooks, Tom Petch, Nicolas Comstedt, who
provided review comments.</t>

</section>

  </middle>
  <back>

    <references title='Normative References'>

<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></author>
<date month='March' year='1997'/>
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>

<reference anchor='RFC6241' target='https://www.rfc-editor.org/info/rfc6241'>
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author fullname='R. Enns' initials='R.' role='editor' surname='Enns'><organization/></author>
<author fullname='M. Bjorklund' initials='M.' role='editor' surname='Bjorklund'><organization/></author>
<author fullname='J. Schoenwaelder' initials='J.' role='editor' surname='Schoenwaelder'><organization/></author>
<author fullname='A. Bierman' initials='A.' role='editor' surname='Bierman'><organization/></author>
<date month='June' year='2011'/>
<abstract><t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices.  It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages.  The NETCONF protocol operations are realized as remote procedure calls (RPCs).  This document obsoletes RFC 4741.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6241'/>
<seriesInfo name='DOI' value='10.17487/RFC6241'/>
</reference>

<reference anchor='RFC6991' target='https://www.rfc-editor.org/info/rfc6991'>
<front>
<title>Common YANG Data Types</title>
<author fullname='J. Schoenwaelder' initials='J.' role='editor' surname='Schoenwaelder'><organization/></author>
<date month='July' year='2013'/>
<abstract><t>This document introduces a collection of common data types to be used with the YANG data modeling language.  This document obsoletes RFC 6021.</t></abstract>
</front>
<seriesInfo name='RFC' value='6991'/>
<seriesInfo name='DOI' value='10.17487/RFC6991'/>
</reference>

<reference anchor='RFC7252' target='https://www.rfc-editor.org/info/rfc7252'>
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author fullname='Z. Shelby' initials='Z.' surname='Shelby'><organization/></author>
<author fullname='K. Hartke' initials='K.' surname='Hartke'><organization/></author>
<author fullname='C. Bormann' initials='C.' surname='Bormann'><organization/></author>
<date month='June' year='2014'/>
<abstract><t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t><t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t></abstract>
</front>
<seriesInfo name='RFC' value='7252'/>
<seriesInfo name='DOI' value='10.17487/RFC7252'/>
</reference>

<reference anchor='RFC8040' target='https://www.rfc-editor.org/info/rfc8040'>
<front>
<title>RESTCONF Protocol</title>
<author fullname='A. Bierman' initials='A.' surname='Bierman'><organization/></author>
<author fullname='M. Bjorklund' initials='M.' surname='Bjorklund'><organization/></author>
<author fullname='K. Watsen' initials='K.' surname='Watsen'><organization/></author>
<date month='January' year='2017'/>
<abstract><t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t></abstract>
</front>
<seriesInfo name='RFC' value='8040'/>
<seriesInfo name='DOI' value='10.17487/RFC8040'/>
</reference>

<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></author>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>

<reference anchor='RFC9110' target='https://www.rfc-editor.org/info/rfc9110'>
<front>
<title>HTTP Semantics</title>
<author fullname='R. Fielding' initials='R.' role='editor' surname='Fielding'><organization/></author>
<author fullname='M. Nottingham' initials='M.' role='editor' surname='Nottingham'><organization/></author>
<author fullname='J. Reschke' initials='J.' role='editor' surname='Reschke'><organization/></author>
<date month='June' year='2022'/>
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the &quot;http&quot; and &quot;https&quot; Uniform Resource Identifier (URI) schemes. </t><t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t></abstract>
</front>
<seriesInfo name='STD' value='97'/>
<seriesInfo name='RFC' value='9110'/>
<seriesInfo name='DOI' value='10.17487/RFC9110'/>
</reference>

<reference anchor='RFC8520' target='https://www.rfc-editor.org/info/rfc8520'>
<front>
<title>Manufacturer Usage Description Specification</title>
<author fullname='E. Lear' initials='E.' surname='Lear'><organization/></author>
<author fullname='R. Droms' initials='R.' surname='Droms'><organization/></author>
<author fullname='D. Romascanu' initials='D.' surname='Romascanu'><organization/></author>
<date month='March' year='2019'/>
<abstract><t>This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs).  The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function.  The initial focus is on access control.  Later work can delve into other aspects.</t><t>This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions.</t></abstract>
</front>
<seriesInfo name='RFC' value='8520'/>
<seriesInfo name='DOI' value='10.17487/RFC8520'/>
</reference>

<reference anchor='RFC8615' target='https://www.rfc-editor.org/info/rfc8615'>
<front>
<title>Well-Known Uniform Resource Identifiers (URIs)</title>
<author fullname='M. Nottingham' initials='M.' surname='Nottingham'><organization/></author>
<date month='May' year='2019'/>
<abstract><t>This memo defines a path prefix for &quot;well-known locations&quot;, &quot;/.well-known/&quot;, in selected Uniform Resource Identifier (URI) schemes.</t><t>In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space.  It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.</t></abstract>
</front>
<seriesInfo name='RFC' value='8615'/>
<seriesInfo name='DOI' value='10.17487/RFC8615'/>
</reference>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8520.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8615.xml"/>
      </references>

    <references title='Informative References'>
      <references>
        <name>Informative References</name>

<reference anchor="EO2021" > anchor="EO2021">
          <front>
            <title>Executive Order 14028, on Improving the Nations Nation's Cybersecurity</title>
            <author initials="J." surname="Biden" fullname="President Joseph fullname="Joseph Biden">
      <organization>United States Of America</organization>
              <organization>The White House</organization>
            </author>
            <date year="2021" month="May"/>
          </front>
	   <refcontent>EO 14028</refcontent>
           </reference>

        <reference anchor="SPDX" target="https://spdx.github.io/spdx-spec/v2.3/">
          <front>
    <title>SPDX
            <title>The Software Package Data Exchange (SPDX) Specification V2.3</title>
    <author >
            </title>
            <author>
              <organization>The Linux Foundation</organization>
            </author>
            <date year="2022"/>
          </front>
	    <refcontent>Version 2.3</refcontent>
        </reference>

        <reference anchor="CycloneDX12" > anchor="CycloneDX15" target="https://cyclonedx.org/docs/1.5/json">
          <front>
            <title>CycloneDX XML Reference v1.2</title>
    <author >
      <organization>cyclonedx.org</organization> v1.5 JSON Reference</title>
            <author>
              <organization>CycloneDX</organization>
            </author>
    <date year="2020" month="May"/>
          </front>
	  <refcontent>Version 1.5.0</refcontent>
        </reference>

        <reference anchor="CSAF" target="https://docs.oasis-open.org/csaf/csaf/v2.0/csaf-v2.0.html">
          <front>
            <title>Common Security Advisory Framework Version 2.0</title>
            <author initials="L." surname="Rock" fullname="Langley Rock" role="editor">
              <organization>OASIS</organization>
            </author>
            <author initials="S." surname="Hagen" fullname="Stefan Hagen" role="editor">
              <organization>OASIS</organization>
            </author>
            <author initials="T." surname="Schmidt" fullname="Thomas Schmidt" role="editor">
              <organization>OASIS</organization>
            </author>
            <date year="2022" month="November"/>
          </front>
	  <refcontent>OASIS Standard</refcontent>
        </reference>

        <reference anchor="CVRF" target="https://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/csaf-cvrf-v1.2.pdf">
          <front>
    <title>Common
            <title>CSAF Common Vulnerability Reporting Framework (CVRF) Version 1.2</title>
            <author initials="S." surname="Hagen" fullname="Stefan Hagen" role="editor">
              <organization>OASIS</organization>
            </author>
            <date year="2017" month="September"/>
          </front>
	  <seriesInfo name="Committee Specification" value="01"/>
        </reference>

        <reference anchor="NISTNVD" target="https://nvd.nist.gov">
          <front>
            <title>National Vulnerability Database</title>
    <author >
            <author>
              <organization>NIST</organization>
            </author>
    <date year="n.d."/>
          </front>
        </reference>

<reference anchor='RFC8340' target='https://www.rfc-editor.org/info/rfc8340'>
<front>
<title>YANG Tree Diagrams</title>
<author fullname='M. Bjorklund' initials='M.' surname='Bjorklund'><organization/></author>
<author fullname='L. Berger' initials='L.' role='editor' surname='Berger'><organization/></author>
<date month='March' year='2018'/>
<abstract><t>This document captures the current syntax used in YANG module tree diagrams.  The purpose of this document is to provide a single location for this definition.  This syntax may be updated from time to time based on the evolution of the YANG language.</t></abstract>
</front>
<seriesInfo name='BCP' value='215'/>
<seriesInfo name='RFC' value='8340'/>
<seriesInfo name='DOI' value='10.17487/RFC8340'/>
</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/>

      </references>
    </references>
    <section anchor="changes-from-earlier-versions"><name>Changes from Earlier Versions</name>

<t>[[This section anchor="acknowledgments" toc="default" numbered="false">
      <name>Acknowledgments</name>
      <t>Thanks to be removed by RFC Editor]]</t>

<t>Please see https://github.com/elear/mud-sbom for changes.</t> <contact fullname="Russ Housley"/>, <contact fullname="Dick
      Brooks"/>, <contact fullname="Tom Petch"/>, and <contact
      fullname="Nicolas Comstedt"/>, who provided review comments.</t>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA+09a3fbxpXf51fM8oulhKQelmOb2W0iS0qsVpZUUYqT4/js
AYEhhQoEWAxAmnXU3773MS+ApKwkTTfdrs9pQ4KDmTv3fe/cuer1eqJKq0wN
5HGq42KuyjSfyChP5JWqylTN8euwGFeLqFTyuoxyPYNPebykQd/VWa7KaJRm
abWUp/m4KKdRlRa5iEajUs2b0w5fXbzR7r0+jRdJEefRFABIymhc9VJVjXvF
TEeLSU+PimkvimOldW/vhdD1aJpqDbNfL2fwwunJ9Tcijio1KcrlQOoqEems
HMiqrHW1v7v7cndf3KnloigTGJxXqsxV1TvGZYTQFcDx31FW5DDTUmkxSwfy
XVXEXamLsirVWMOn5RQ/vBciqqvbohwI2RMS/qW5HsiTvjxTUUkPeAsnWVpU
/mFRTgbyCBEgh0tdqammxxpmV9VAXqXxbZXCt0hrJZ/Tb3GRwDxHr3svnu4e
8BPA7EC+jbIs1SrLVG7G1XmFux4u0upvqsxgN/TD7JZ21Pn8YE8eHMgXz1/I
l4CLDv2oplGaDWQGAH4dI1z9uJg29jTsy6tCq2BPw7ioKv+Q9nR+OrxubGVv
d1e+qksV1fK4DDbS2d998fJlJ9jIt1Fa3apSj+pyIt8cNzdzMzxsbmJPPt3d
6718/qz34uDpy8YmNMLVLwGur3NAYn9SzIXImf/maoBDr7452t/be2k/f7F/
sOc+v3zpPj/ff7ZvP7/YPdh1n/eeH9jPL/f2+LlILZObRU4u9nf3eS4pjSyd
fFBxjSPkRZmoUu4d7O6/6MrT6awsSKIABfKcBEXLo+UI8AEvlIAgnsZxG/8j
yvyxL1+liSG/o85lqTQ+reQfAROz2+YYItZNnlYqkcMKJEXLi7E8nII4xhEP
SuDpQL6Jll2J+8CHw8vj75v7wSdyOFNxOoYXEWz53X7/6Vpgac1r2N9Zmtcf
5DdA24RVQrAeLLVvVojKCXLQbVXN9GBnR8+SD/0J8Eg96qcFfe1pWHlnDgvu
4DtHyxil9vj7vf0mlO4H+f2bM9BfY4WKSsn5Xn9/M6gxvwWrwtd1ONmlRYeH
37RWK6ZTwMPQEE4eJvMUNMdSflMCZUDp3MnvgK6Iq/3+7rr1exYOJvAZil58
5x4ygc+ifJKpZfOnskAIVJJWReke0m4uDoenw/Xzg2i/jiaeOax8V2oc5a2f
ftEC131QFrfTNKlaS1zfFtNIr/z4qEXa/AHmQveLSKcarITKkWg7sY7G/H/A
JLv0qYef+rfVNAtJeg6WaArS1nUMePTd1Xq6Ni3blZqBUUDJ9dTdwne3HZE3
MdlvhPyfhZdePC8BOQCi/9rDr/1ZMg4RNFSzymFoj0wS6vrz746bSGLdFWUt
NB1HVTSKjKVYQUTTdKzsIJ8nfa/JRa/Xk9EIrWMM5vq6kClpTwUCG+hLOSt0
BYani6sV7HvIVMtcodcQgThWhcwK9BIEKl1tXZlIJuDcgHaAwbUGynbJMVnc
KjRPoKCjyg++Be69y4tFLubBflOl7UtR1ZXpGL4sZanApk6VUXpa6no2y1KA
WE6jJcw0V31xfQurTtW0kOpDBUM1GYQ3N8fyh8Pzb8G03YKRQ8jJXiSKfqZd
0JTF2IEmAJKMnsDeQa1H8GUL/azhNoEGc8wbJEq9jyZH+LUqi6SOAQECVgz9
O4aib0gBkptkSohT8wJp9P8K/glxKPMaeQehAaKlc0IRbVmOlMolig1ZP09M
0JmpgQyeIiKFwzrgqKzzHN8AYCPwxtCH8iiXLWIQ0fzrFt3y40e20ff3sJnL
GugKq2eg3CtHBq3UnUYIYP8LJP+ikHGGfhnh9q+10ox6GAK0EDqOMoW/APVo
BHB6rSOkJHxhzmJPN5IZ8rmcR+BNwy5xLHivOE6YcX2JGhJcQL8McShzxbjI
smIBSBgI8NTkqWawGRkOBQANQi+BeFUa17Bmk+5f4btvb8HjdNCleXO8yudp
WeRTdCbiIq8iGNDCMAouSUap/lqnJYrTVBGti/wrEbB1UiidPwFMk8+wNBtB
vmNkpTpkxK4cAVXKCCVPFHkGdCsWXnAJjyWHIyQKgKpi9BcVV4w6mDTVXVpj
Cl5nBt/AS0O5UiQA4yhG+HGmxEQjS+Yi1BUVkGKRW0kDzQFopJDD0hr8F/Cv
l8iGINMoEC4e2iR8epsoCNPFZTpzQrsIlUoXYIyzOsF552xDbOiVqBkCn8es
YaymMkThTYNvI2iNdEx+TkXRlUEyah2gNNpcC+plFN+BlSEVDf5pfAt+hRIf
P6Jrd38Putm7Tx8/Bi4WCc2wyWxW3lDCQJZS4B6g2chueARoJ5UKYgU7AyuB
eBMGNFCUbt9IsgieK2S6FL0wD0V3rSUW6ywxAAym+P6eeWCzY0YAwJ7RmYN9
IRqbjIgqB6QTfNwMNlRr5p+SloRPIkqmaU4RG5hmFk9NfFWw7icbsYKmQHkh
LpFMSOXNejkGlwCwSeuDEALdYwUAQKR3KwsSEl3UZcy6aeM0sD/YMSwNUS+h
aRrlwAEk31VRZALCrixxIsGCbQGFwXcKLSPvLdQTWlUNCwTmbgYUy5G0GiJL
MBsaV7UuQhPAxLgIiNhEgdQARpVYiziWUdgv4I9saJNWRmJphIC91SDn6Arg
Tsqintxa/Y68nuqpsadgu9D6N6FiEqNhJuVG9EbutlRAi5UnKWkjkmJj7I3g
6hZCSnACKkZoY50uypl3MZRFtvqgSojHyYQpEeh0jKIlkiXLgHVeAfFDsxRi
Q2VEWTYdxczgnnSX14yC9XHKfOXMH3DKRa6I7azDQVoYviO3dumb2MhotKsR
wmZeWGVvEfKlEOdFpRg9DaWFGAcdCqY3KkFeidWbC/FOdIVMh0I+UqwzlzID
DZmT0kGeQh35SsUR8i+by0bwCgYiV3WFqqlUk6gkZYTqFTAI+gnticzUuELI
rN0CJawycK1Lp1zJoWxHuV120pl3T4cXzOcx4pQYJ6rAjoG5Y1ovxQJMCPmI
xH8tEwrGyNtQtImbdQZzq7BmEuUamRCoOC6LKSEObMqsAMNojOYTDS8wijbS
SrKdAG6LQZsiJ3p7U1I+AbbnPK56hlGE7ovXxQI1f5f9gw00XuNiNPUX60r9
CWVJrlICq1UpSmroKyTCawLldRn52FE9QXnhOcgnAQc8VCI3GvTssbfgcgv8
823jYXz8+B+YIHq2v0t2xPMzCTW773GpCEORmAAQM7Z3MATFjDDgVbw1+Egu
gAUWgknfgF0sCIus8zE8GMOUAB1qWmPgja+C2IS4EX7IlUrQ9YLZZzASJiW2
Ul4ROmkI1ACEjzVZBvKcVUQ2AvCalOQJLQqB6ItBcWvwQz+Th9aq9LJoCdgK
bIvRaaXPH4fkIm4EDJwWGAYazwb2gQaGdBr6Y/mkwPeydKwwPaP6clgHnivy
UFHSf0BAYBpy88F7LimgUSUQERE/j8A1ATXaJ4iNFWEV8BiwmzxHsTixcsNh
AOahFB9gS82jrI4qjtZMXMqeQbgyzAKcNecwieQDZ2OfDlAcjDTjeL8w51Sr
bK5QaoW04oM/AypuIaQoyc1BzWdz7kvL2FUxK7JismT+N8un6M6P1LJgI4sJ
1Zly7jnZBYq7NQCj2YdHbQqR0Z0i54jZoWt9cWswx6gLCTE5TocyqJCnIERK
mHlga5aUflv8PJILNdIpIHFL9Sf9LgSIkby5Ot2Gn60wO6QhsEVd9Ypxb4Ry
TziJjaNEWzKxN2zkRluHc5yWujLwdB0gpIeJjwIOInmdoY9SCdanlj+iDPB8
8iGCQFKZABCxE7w7TSe3JIWY37m+vgS/0+SR0VFFf/vi8FLSQ0xAgw9u9TNZ
Hb+OIGffK04S7HSOjBYyO2xBkZfgd6pVjMS1W12QJ2VlztkX2jTzaFnAzJgq
cav7JThIQ5qiurDGxcmYMzMNVwyjF6Aeh1LoNjV9bet7khNHxBXBlqyKQ8WH
bHD8+uiSXY2iQh98NrMBEziPIAi36UxQBmOMku20XQMlwNulx0jkOITQu0j1
LYKKvq/zZUDuHzA+bvvsaaGfjkYtTkvQp3jGFBs/VpC2Ut6XBDerpjDDqQ0M
qpU2QS1+1XVm4mUIW8wwsvWWtXBHBsi2haxAqsaS/H+YCKgZV2APb67O8JmL
cVnCVU5bWFWPQbjscyWJGoPe0SSqWdbjvBgS2RjFL/aekVF843UrLFlQXICR
E+4A4w9NlpC1Ns4u/HSWZ1zQb8MS8FnaKhjDnLokC4lz2bgUsONzgBhwULSP
CDN+HjEOAFTHVk8j8wKuIJjRythM1HR4fqhl583N8LrT5f/K8wv6fHXy55vT
q5Nj/Dx8fXh25j4IM2L4+uLm7Nh/8m8eXbx5c3J+zC/DU9l4JDpvDn/osBfZ
ubi8Pr04PzzrrDfXFekEEhyw+HjWA76pD8XhnVcgOHsHrGzwRAyUDX3GEy74
jIrBJkSAIfkreafAEhDRUaoI1GMczdIqQicDpFLfIqFQNQGuwOHjYDo4AsZU
1ZXzxHqf+gfenqJEkjxweQRkMgwYjddV2XypS5eO08wlliobNyCHiAedRuAZ
u9he/xnS3nhzwcqBuzQCN72ROkPGVWAUSLudUWBJipvUHGABwYI1DpMk5UAM
s43By0LfEuFwLE6gUhMRsoGz1DXOaUkGjdJ1f77ikJAs5aj40JcOa/sNrDVk
6YyVM+/B6jWO/keK3YGEhgibZ84MtI1YrYlORPCKO4S7ytI7lVE6l4MHiBpE
K2pA7XBz/ARxAVqhB5otTXDOHPfmMnGwCxBkmLxhUijkMO4uxUQQfSjWKJRy
uqV9wbTxHRnSClOrwsYxYUCwZnHYL2eJdINhjQkm3xh0cgpGH2HTzJEz8pEp
AN4QsIgm771FQ8wOA07pYzbDBy5iYyKIwjxCVT5FcoCPZLy4rlGl5L5Y81KM
6EdSaEes7XpYMgHSGhlf1aVeMEjA1APJPfKHkaZUc3DNFhV4HfRKEFSD+x4m
koP0ELkTWTrFQ2cBGiNI57gIzEbj8hCs0AzPgBiwlF0lWXDOgn8VFzPrah8V
4DIBZC11CXCd5mAeIjDpoyi+Iw1h+AHsisqB10uwRYQcE2uTQmMBcYlJYmlW
0xokmMIxNIFRmYgVVsfIij1NUE8qAf8E8/rGzWHPinwCDZAkwFenY887hk1K
1to2Tz1SFjgbmMGDCH1dAKbLvpVfyDA6+myYngbWGGc262RSf4r90y55bew0
oGsjLB28vd/58SN61by7H+8//4sGH0CrvyJmfTaE1BtKkwGTnSo8ubDRvXWe
KLHr/UnMsqTW+GtrxQTGD5ROn6pGfsCSiERqVev4A6J8DkQoyrXy9Ytexq2u
urRMBdCjXZ6V6pLqMqMJp3ReqoUJtXBF+i2DDUtyFlzm0JDmfDUfq015UBB9
tg9JeK4KsZs30g1U/oEpa3T0KC8srPAGqoVPV/CtvBGawxwLVvTo7wRmo3EW
6EITrarGqd/af3gUGMzkXkbHhZzHhM+yOjt9P2wHsdpxEGtrqPpCikMOFWqN
bhworHla1JpP8JwCC86XyOUlN47UmHH+BB8OsDokEbIZZDzjpAxJnfSa20Zv
g0732QFx3z+NA4OIt0itBcOGzj7vn4nrZnMnEejYYYCVU5iNShU89G8wXuWt
eniwfEB2QmA7JKbAdF55dNx43RHgGkUuIWB9J+TG/qu+ce9N4sqvQhwYKihB
CasFWkNKIVRBmBuIu4ndUQf+pSYxON7uk4MH8ShvpQPI7vgsBgkep+RwAVar
JEIAMelec+Rhc6QWV+CJ8gkpphb+bv8JoFeNhQpUTtimKzCfXUzuwI8D/B8V
JXze65WLBuvb6gX+ZYtE30XHPQ4kt7+yo36igYOtOCvqZDt4+pOdASfQn8l3
5uSghxL+vjnQrRaOwacYxuWTDYOtUvrKlZ2oalCXaRs0cu96Xu42Qtlrj8SZ
WdlUS7A27YnpHZOCIZDDmZtg2lEAngV3Bd5gOJ4ppXPVQ35w4x94aYuU8GYq
ybVUksH+rRb/TLb+tRe0U9ELazcfAtYYtXbznoNBWrB04SuMTJ4e7EKYNqZo
PjhURtmgZDZWYeq+V2KItWaGm8+yfYkJHwc9rLsYjv88ujg+ka9Ovj09H/6B
4q3OWqH6en93/2lvd6+3t99fgrPdMTK4XgTlR8APDuvNXf3U3peC66JgUAzL
1GU+wJcH8E401YMP02yQ6wG+NVg7aQcnAHMwTj8gGqoPX6Kkp1NyJugNxHOP
6y8+cqUpj8bnX9KD0pYNGvp1AP8Sq0Vp8vvWfLBKcyJ48MA8GGKaeQTVQ0GA
+TdfHNnBimZ5cTk8fPut3LqYaXlYqmhbvjV1M9/iOQK9b3iI34LBb9UoKAWD
iBnLpu5U2UcoqRZsMdnhquodBgheOgNxGkh++rUdKPjnE6o+CyuaV6qGw2G+
SHhdXS6BHPAtg01q3DIjMophWD5Xd+h1ob89mhzbqrjSlQIYG/GJo6K+2dtR
MVuWZLa24m2sBHxKpeTyGuvG7Zkzpn01Oauk8eiwJNJhYZtN+1JEjtE+BBQ0
rUb3g4Jqu+IVuO2az/0oSs4TioXATLNVoyejNMdcFYILsQgf9pud4peirhAX
7hCziyaQc9NoMmd1qWs+tuFARteUlseyBZqDQns6JFV8ROqML/oLbJSvwLNC
A/9qeAzcwWPR46MJADAAKc1d6uSgH1sUePxBUH+mJuCMXiK5yPewOMiiylR/
0fBjk+Uwv29Z9qXyfaU86xqoWa1alBL3WN1hDy1Cbkr9mRKK3vfwr7XQYrHo
l+O4x5WWtBQusQPPcPQ2CzLWhjFyYBaTVqVj4RrondFWwc9J2TUxoIWJwyfo
tz/p8n8xcsXPNnGInylf6D7wFGYYB6P+k3/dxb74tRUOP+nyJE/eHP7whJnh
iU0hPvkZKUSaZF0ecQtRgXnEbf6IacTttVlEx3pL+bhUIugFUtro43PttLMq
RtG29QiqzTytUqADOqAF8i9d7oCovd95QBkjjX/+tRdr1h+8/eJ1vPWXOKvG
YcfGfbzCuhj3BjJZ2wWT8W2BrLZmAeRqMzXV15ABHPhlv9y06g0Mxpff0UnU
0733civNqb5WbTeS8CuZd+fimKoF9LLWpGf45MiW0+TRvEgTjq+D+mZ3cuLL
WxI1y4rllGoyKOSQ12dDqsXFwCJ8N8rxCXIw5js4iNiAIv2rcKQhAngMZkBH
Wl4jvYHHfv01EMVF9MuJRgeI78z54YNU6zdIZAFbR6koQ0szuaXQboVi9k1k
zTUEc9jnPM+OJ6DetPlfTg7c/fABcjjE+JV9HUYg0D0f7m4UTEKeeztIUGOl
hOZ8KqvJRqU2nn4bjOmNJaNrfJawbtSqMB8pr7jR64EGsI/cO7geH8AjsBNV
bcxU25cb7GxgkEb9yLVRsINlPTQAz2uu6h2na44O3BKSygokxWbBlJKzARQ+
Nx5LsrWdMFYO5toMDUF02MgxAHJSznT48wpX1dd8k4ouwMIQTW0VYL+1MHjM
42YQ/7E1DWdyKaz/svXTZqiJId2qXDePmXsy64RXsncr4NyvAucymWsBs1Hp
yq8Q7kQV3qeUT7a2SIy/2v6J/aqvtrcH/c+etHdz/3N2d0hVtaYKl2vAE0y/
PrQh//m+yUgrJrTBUw4JDw6z+PDJjxWUPKDA1uPgAa7kOn0scaxzWwsESqcq
4iLjc7UC3JwmNjbufyUtswEBQVpi7d438ULACXgxsyo8J/y0ValsHT88GhOk
eMlxBtVqTsciCF+yLplj/n8sQSrbXMSwSITYXqeh4juILYopniLiGS6Vhxbt
V20ZEZ6IYIoRrd2Khf8E8u1/PX7DJFaAxAZy/ZwbNOg1nxifoq2rS7woIv84
vDh3WgyExFQtwSY0Pwy3Z7QcDligQ+Vz6RBAjmCWWzwJpuO3VIcvmuNgKS9x
mOFJqva01eq27Auvo8rwVVukEugjix1jTtam636eOdkY9D/CrgCJmCru7OYB
/n+0aTkzJFmvyrS9R9MMTOy/x2znAZlfyUauynw7FfmzZP7fROg3Z5IeJf33
1u+0Zw0de9jQ2exqHiZJcACDUDjXMXT8LAQ1XRpY686y23tvErjg3w//IGxu
WdjSReHTvae5PZain3x9DeGQFoqM+GB2K41VcOfqe2GKjXFQ4P/6EjWqX0Ej
zuXS/O7h0Zm5iAarCVoNd4phiblilgQxCecR6PImVbdOCow3ExURnk4ve3TU
F1yrE+KtyZzBQsNmSQcfI3ExqNtqoqagNysubTeX0Ky3TFV8m0sBF34lzAS5
PD5S2mXMifgDQ308ArPpb3i4x9mS8NBuIN9Zvmjkuenh+66bBZyOxu8DJ7Ed
6+HBs45NfKVF1TdUxlQuZ72YjHQK28fj/07XTmHVYkd6eGRjtmTjdHjdmKcz
L/JZ172H/VPA8UQhSPSWTic51cI/4t3Zc21fhWAV1B3dU+hQe4r9fcwu7T67
3ns62H852Nv/fHd3sLtrxzdrhOCVgxfml1T3XLVGh5qOKPMLH+ZTIAJLtArK
m3VTVNfakiq3y/Gkh6chOMmJreQ4zeO+HdAoE3sIDTDQoMLNjd/c7OY3oy/8
CdS1ryG2SqEhIKQY6IB3tS5em2t+II+ujIK2+X9CNv6NmZiSu/8iDExgnhmv
y5T/HnNN3UOFqKc8Mgdu8zVU3pBp58iZKdnguOuKfHU9Lx4wFkHlye9KGNpR
sCPK75zjD57/hhzvmd1UYXKFLB/d/X6YveW/NTnWF4K1iksxtQ6ezwO8ur4k
jnW5L1ziql8RSXMzE+OQrr9gqPKkMDeZ8Bw5f/DmspgWJS6F9yGoCJOq1sj7
Yx5wPvG/jvz873lTPRO7/wrpfGCKRwvps8HewT9aSKfpB+V8k4G5CpM7ziZ/
iwSXzimAYf8h0roOG79UaM3VFRd+2qinv9lAbZD05i3/Uk7RL6Ny0bFZAzA3
0+Lhc6vWmWZTDwhdYZl5eK8ylL51wrdO9NYJ3orYkdCtrzRaL4KdMN/xCIqF
w6lR1G8lopgMIwn9FfL5a6VzjWyCYD7v7b683v1isPfF4CB0GTdJ5ia5/IdE
PJ+QyV8rkZvksSmOmC5o5wpASFNzhcf6dmTlYKFKucCID6i9XXWnhI9o+NG1
tzf9he6eueHSapzw/8bud+qDPt0dPN37900dmN/QOzSy2JsVWdpkGsPZmGrX
wfPmL52QUWQr89xxywIZv3h2cPC0Nz8Yl51gkE/G2qrq+wbbVMU/HcCqeBSA
zkyQWDfVAK08iOLMwwUwZQEsAbAbYOj6EZjdxxHpbH4AK/FhZTgA7183MMDP
Wntv7z5YO852exXwxjyY1QwBZYZXgVvTmx8RorW/eLxkSa4Huox78F+7HLAt
34cLmbezMkn7FPp+BTjuZbYBONDEC24Wg2tGdDutvUhzifCbq/L3xwTdxxEP
OPyfTrxx+dsRLwFF+q9PPGGfowvhLfNhxc45XXkyJyQrXUaoB0wFn2ZVo3LJ
huxdwX3g7CXN9tXM1BxjhbdZw5tNfJ9SmPyUuw1FLQK/Pbm2rQa6rd4zJXw2
t8rAfaHGMuOH+h9wygvvES7p3IMcmeAiEN/54TZsRwUdDZs7gJuuHvCpjKtN
Da80mxM9POpJgqLNdsFVGLKUQc3x2mM03kC71RLdFDONdbj8fGxupDbiIaoF
prunwf1XpjgWItv7Dw802zH3RG2jgjRbtu9bMRTwFa19qSZ0xXZNQzdbHhJ0
BqIe0yfXRxfn34h3pv31e6xbujoZ0lMqkcOG1+8ZDbfULZkZZmJavZmu1HGD
eHwsicvUGnsKIlZxH3aUSkxfAEkX4Fxt3EhlxYJA5Qpy3SAQXa10HSfMZc0p
oCAhf9rUwOCbhupBY0aUmZ2HCv+vXXNISw5zYxv2XC5nlekcVef+u6vts9LZ
umVqM18RlvJVXGQ3K6MJDtDY0OfGTyYaxTwaS6D5ViDSMJ3VmTsvbfRnbd7h
NJ1gsF+ibVIW1G6am8fNEkyYcUyn53YzSMlxOsGOF/ZapgY0u9ukS0rR0R1e
c0sYa24BzmP4r8Hj+gs9htu5PFfipWTbABBgwtQGKyNhGtUZ8WHOox68tvLO
tCPkxoohOghG0+fMZyS5QwLsk29I8uwslQDKNBAGezGAa/hTLaYRdmUDBlc4
k7kESecb9souhXrcxQCE1xwIO34oQcv2aLztvmdbc7JkM9a7ROc0524weGFf
1rOsiJDjhKnO9Z0iZJnqO74b7q+8kuAYZVu6Ri226WuWCexdoG2bCOpzE5LG
1Y7yNXS2PXQ/yNwo4UZMbhfdgBNSbRofBf2VgY2CzixBraRqFCHlchEFF0hH
SxMeY/wFsLAECQS4LnNMC3N1Kl59dQ0CYEqqliWs8K3hth72qe2FbWkxjjK8
WW4GG3hc/yzXq2MaZSaJfO17nZmCE1ywS50FPf0jvgMecXuroOeB6RTL94JQ
+WhWcF3aDBnEiNpiBj0lqRMWcFjFi2AYx/UL1LAjmmCn14quMs/qyvcDo7va
nzUaQze6kiJ1C4otQd1wV2Vaf+7zgGzaU01XSRemF4X0wLteGQU1DkDNbq6E
0y0RBojTf1xPZoGJcn+rPuyICaT+E0yQqWSiuA8uejOWxo2GzygXfLAWNXyl
NGmwLaDf3Mta8sUNEV4/Vh9AvtLKXJhc7S1K3eMmtcWf6eyIrI+3+HPAVebm
sIQImi7DdlyDw3QcdBTQgVqiXtIOYPYKvNRhsynK92SoQ4gnzFsCbFo6NzfE
yRBS84HVtgW+j0izT4Dgvwih7eGkv31vFG7job9XZKko6tw3jGq2Qm53lRnR
ffaozrDF4AXnmE3LOtLVbHwIxdjE583hD64XVTAxtesJBZp7B4cENbz5NysG
YDRB9JzCw54hfYEtTLFhDBoR04fHKQTsuaV1jeoK7y3wJTpltxVnqeK2a4Jd
97rEe0QyGleKG2j57hXOMUZDh+l1eJJFVBp5mHOjRivvZnmgWJEZ397Y1IvD
m+vX3Np3itf+jEdxmovQkUzHXghMsNDwR1wrH/QNbd8UvBYh7B1GszHjZlos
KnMF3/QBpEo71xi3JUllWZTmMiKKQVkbx60IrCEih/DkgRe8MjZWMFghhcru
kr5TC9uigODH5Ia9f8Wud1XTAaspvW8oFdvAbsdbtWazE/THgj6eIGvCnBr6
dmnc99u20MHrSaS7bFc2m8O1d42wez1MMilJOS1V5S7UREvbpw3tA85hu/9y
esl2qKUucwn1kHa1tIfgbqYQh8Es3Mou2N0T7UXeFvqT3am4xF+gVkS1PwV6
MrMjgtmUWUU/BZ9iQvJDikcHVsUekTU7K7E2EO5PGLhIo9VlFJZ56JxIThT+
hiWv5GI1tCLGDcJ2gaa+hfgnIWC/n/ibEvLjR/OnKKi73GklKMjWOh3ZGsXw
lNn28oMIQ9G1urBXMvUrp5gQ4gtXHYoaFfsiEsmN88Up/8ZfhSAedqWHzD0p
xJ30CwhpViyNhOVNJdbEIXtzoWITRhmPVMAvst03EX24w/PDR8TTglrGnrie
Ja1TRHTlaSYqD6B8AK8InlC7tYhvHyD8QYLVi8u1TTiw8NWtDcTFP3fSaqwx
NNc0fRn0QDbi/2Ayutp7FSji1QNS3pL7ewmN28CmW9JIOX0VtEmhgW9ooEBA
dcdtze4Hkz28Bxv94JObq/OB/NltCvDNS2oXMOAbI/jAbs3+8YW44r+idHoy
/JZ/b6IIWzGKoE7Pbxv/+FHDYoX0Dfdzc3X6C6EPgD2ywFpAYXn8Qzs59ZZx
zRxgLW1FCxxIrhVGhYnQNppz9+2u3qKz8SdyNhhbn6Y4+VS+g2SDsVE/x6Cc
E4zCyKKJsGGlY1zkW3xZ12OiEJ11YaLwiOMAI7+ZKgfcsAF/a/5tLMu+IanM
BXgCxMnyAPsQKmwTvnN6ciSfvfxif4BHs3zSc3n8PXdksIAdxnfGjeZ78yvy
fg0g8t8xuULd9RpvdqhlVx6n8Z18VRbFHcR218VUXqoqvu3K8zQuMhDeo2KK
OKJ7toVwjfXxcgiYajYG2IqI/hIMdlgDu35kogSqCDoBjYpdVM0fQ9qY3rOA
/vjux3eEGxMoudBiWsw5VMRbs9xd4sf3P74X4pLVOF7Gt2dV5q+E4TEVKvly
x7U+ofupDB8A/T9yXdOp5XAAAA==

-->
</rfc>