rfc9472xml2.original.xml		rfc9472.xml
	<?xml version="1.0" encoding="UTF-8"?>		<?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 [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<rfc ipr="trust200902" docName="draft-ietf-opsawg-sbom-access-18" category="std"		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRef		-ietf-opsawg-sbom-access-1htmlwdiff 8" number="9472" submissionType="IETF" categ
	s="true">		ory="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" upda
	<front>		tes="" obsoletes="" xml:lang="en" version="3">
	<title abbrev="Discovering SBOMs and Vuln. Info">Discovering and Retrieving
	Software Transparency and Vulnerability Information</title>
			<front>
			<title abbrev="A YANG Data Model for SBOMs &amp; Vuln. Info">A YANG Data
			Model for Reporting Software Bills of Materials (SBOMs) and Vulnerability
			Information</title>
			<seriesInfo name="RFC" value="9472"/>
	<author initials="E." surname="Lear" fullname="Eliot Lear">		<author initials="E." surname="Lear" fullname="Eliot Lear">
	<organization>Cisco Systems</organization>		<organization>Cisco Systems</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Richtistrasse 7</street>		<street>Richtistrasse 7</street>
	<city>Wallisellen</city>		<city>Wallisellen</city>
	<code>CH-8304</code>		<code>8304</code>
	<country>Switzerland</country>		<country>Switzerland</country>
	</postal>		</postal>
	<phone>+41 44 878 9200</phone>		<phone>+41 44 878 9200</phone>
	<email>lear@cisco.com</email>		<email>lear@cisco.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="S." surname="Rose" fullname="Scott Rose">		<author initials="S." surname="Rose" fullname="Scott Rose">
	<organization>NIST</organization>		<organization>NIST</organization>
	<address>		<address>
	<postal>		<postal>
	<street>100 Bureau Dr</street>		<street>100 Bureau Dr.</street>
	<city>Gaithersburg MD</city>		<city>Gaithersburg</city>
			<region>MD</region>
	<code>20899</code>		<code>20899</code>
	<country>USA</country>		<country>United States of America</country>
	</postal>		</postal>
	<phone>+1 301-975-8439</phone>		<phone>+1 301-975-8439</phone>
	<email>scott.rose@nist.gov</email>		<email>scott.rose@nist.gov</email>
	</address>		</address>
	</author>		</author>
			<date year="2023" month="October"/>
	<date year="2023" month="April" day="28"/>		<area>ops</area>
			<workgroup>opsawg</workgroup>
	<keyword>Internet-Draft</keyword>		<keyword>sbom</keyword>
			<keyword>discovery</keyword>
			<keyword>mud</keyword>
			<keyword>vex</keyword>
			<keyword>chaff</keyword>
	<abstract>		<abstract>
			<t>To improve cybersecurity posture, automation is necessary to locate
	<t>To improve cybersecurity posture, automation is necessary to locate		the software a device is using, whether that software has known
	the software a device is using, and whether that software has known		vulnerabilities, and what, if any, recommendations suppliers may have.
	vulnerabilities, and what, if any recommendations suppliers may have.		This memo extends the Manufacturer User Description (MUD) YANG schema to
	This memo extends the MUD YANG schema to provide the locations of software		provide the locations of software bills of materials (SBOMs) and
	bills of materials (SBOMS) and to vulnerability information by introducing		vulnerability information by introducing a transparency schema.</t>
	a transparency schema.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction"><name>Introduction</name>		<section anchor="introduction">
			<name>Introduction</name>
	<t>A number of activities have been working to improve visibility to what		<t>A number of activities have taken place to improve the visibility of
	software is running on a system, and what vulnerabilities that		what software is running on a system and what vulnerabilities that
	software may have <xref target="EO2021"/>.</t>		software may have <xref target="EO2021"/>.</t>
			<t>Put simply, this memo seeks to answer two classes of questions for
	<t>Put simply, this memo seeks to answer two classes of questions to the		tens of thousands of devices and a large variety of device types. Those
	scale of tens of thousands of devices and a large variety of types of		questions are as follows:</t>
	devices. Those questions are as the following:</t>		<ul spacing="normal">
			<li>Is this system susceptible to a particular vulnerability?</li>
	<t><list style="symbols">		<li>Which devices in a particular environment contain vulnerabilities
	<t>Is this system vulnerable to a particular vulnerability?</t>		that require some action?</li>
	<t>Which devices in a particular environment contain vulnerabilities		</ul>
	that require some action?</t>		<t>This memo doesn't specify the format of this information but rather
	</list></t>		only how to locate and retrieve these objects. That is, the model is
			intended to facilitate discovery and on its own provides no access to
	<t>This memo doesn't specify the format of this information, but rather		the underlying data.</t>
	only how to locate and retrieve these objects. That is, the model is		<t>Software bills of materials (SBOMs) are descriptions of what
	intended to facilitate discovery, and on its own provides no access to the		software, including versioning and dependencies, a device contains.
	underlying data.</t>		There are different SBOM formats such as Software Package Data Exchange
			<xref target="SPDX"/> or CycloneDX <xref target="CycloneDX15"/>.</t>
	<t>Software bills of materials (SBOMs) are descriptions of what software,		<t>System vulnerabilities may be similarly described using several data
	including versioning and dependencies, a device contains. There		formats, including the aforementioned CycloneDX, the Common Vulnerability
	are different SBOM formats such as Software Package Data Exchange		Reporting Framework <xref target="CVRF"/>, and the Common Security Advisor
	<xref target="SPDX"/> or CycloneDX<xref target="CycloneDX12"/>.</t>		y
			Format <xref target="CSAF"/>. This information is typically used to
	<t>System vulnerabilities may similarly be described using several data		report the state of any known vulnerabilities on a system to administrator
	formats, including the aforementioned CycloneDX, Common Vulnerability		s.</t>
	Reporting Framework <xref target="CVRF"/>, 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>
	<t>SBOM and vulnerability information can be used in concert with other
	sources of vulnerability information. For a network management tool
	could discover that a system makes use of a particular set of software
	components, searches a national vulnerability database to determine
	known vulnerabilities, and then applies information provided the
	manufacturer through this mechanism to produce a vulnerability report.
	That report may be used to indicate what if any versions of software
	correct that vulnerability, or whether the system exercises the
	vulnerable code at all.</t>
	<t>Both classes of information elements are optional under the model		<t>SBOM and vulnerability information can be used in concert with other
			sources of vulnerability information. A network management tool could
			discover that a system uses a particular set of software components,
			searches a national vulnerability database to determine known
			vulnerabilities, and applies information provided by the manufacturer
			through this mechanism to produce a vulnerability report. That report
			may be used to indicate what, if any, versions of software correct that
			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		specified in this memo. One can provide only an SBOM, only
	vulnerability information, or both an SBOM and vulnerability		vulnerability information, or both an SBOM and vulnerability
	information.</t>		information.</t>
			<t>Note that SBOM formats may also carry other information, the most
	<t>Note that SBOM formats may also carry other information, the most
	common being any licensing terms. Because this specification is		common being any licensing terms. Because this specification is
	neutral regarding content, it is left for format developers such as		neutral regarding content, it is left for format developers such as
	the Linux Foundation, OASIS, and ISO to decide what attributes they		the Linux Foundation, OASIS, and ISO to decide what attributes they
	will support.</t>		will support.</t>
			<t>This memo does not specify how vulnerability information may be
	<t>This memo does not specify how vulnerability information may be		retrieved directly from the endpoint. That is because vulnerability
	retrieved directly from the endpoint. That's because vulnerability		information changes occur to software updates at different rates.
	information changes occur at different rates to software updates.
	However, some SBOM formats may also contain vulnerability information.</t>		However, some SBOM formats may also contain vulnerability information.</t>
			<t>SBOMs and vulnerability information are advertised and retrieved
	<t>SBOMs and vulnerability information are advertised and retrieved
	through the use of a YANG augmentation of the Manufacturer User		through the use of a YANG augmentation of the Manufacturer User
	Description (MUD) model <xref target="RFC8520"/>. Note that the schema creates a		Description (MUD) model <xref target="RFC8520"/>. Note that the schema creates a
	grouping that can also be used independently of MUD. Moreover, other		grouping that can also be used independently of MUD. Moreover, other
	MUD features, such as access controls, needn't be present.</t>		MUD features, such as access controls, needn't be present.</t>
			<t>The mechanisms specified in this document are meant to address two
	<t>The mechanisms specified in this document are meant to address two
	use cases:</t>		use cases:</t>
			<ul spacing="normal">
	<t><list style="symbols">		<li>A network-layer management system retrieving information from an
	<t>A network-layer management system retrieving information from an IoT		Internet of Things (IoT) device as part of its ongoing life
	device as part of its ongoing lifecycle. Such devices may or may not		cycle. Such devices may or may not have query interfaces
	have query interfaces available.</t>		available.</li>
	<t>An application-layer management system retrieving vulnerability or		<li>An application-layer management system retrieving vulnerability or
	SBOM information in order to evaluate the posture of an application		SBOM information in order to evaluate the posture of an application
	server of some form. These application servers may themselves be		server of some form. These application servers may themselves be
	containers or hypervisors. Discovery of the topology of a server is		containers or hypervisors. Discovery of the topology of a server is
	beyond the scope of this memo.</t>		beyond the scope of this memo.</li>
	</list></t>		</ul>
			<t>To satisfy these two key use cases, objects may be found in one of
	<t>To satisfy these two key use cases, objects may be found in one of
	three methods:</t>		three methods:</t>
			<ol spacing="normal">
			<li>on the devices themselves</li>
			<li>on a website (e.g., via a URI)</li>
			<li>through some form of out-of-band contact with the 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"/> or 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 and may
			need to individually evaluate requests. The result of that evaluation
			might be the SBOM, the vulnerability itself, a restricted 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><list style="symbols">		<section anchor="requirements-language">
	<t>on devices themselves</t>		<name>Requirements Language</name>
	<t>on a website (e.g., via URI)</t>		<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	<t>through some form of out-of-band contact with the supplier.</t>		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	</list></t>		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
			"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	<t>Using the first method, devices will have interfaces that permit		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
	direct retrieval. Examples of these interfaces might be an HTTP		are to be interpreted as described in BCP&nbsp;14 <xref
	<xref target="RFC9110"/>, or COAP <xref target="RFC7252"/> endpoint for retrieva		target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
	l.		appear in all capitals, as shown here.
	There may also be private interfaces as well.</t>		</t>
			</section>
	<t>Using the second method, when a device does not have an appropriate		<section anchor="how-this-information-is-retrieved">
	retrieval interface, but one is directly available from the		<name>How This Information is Retrieved</name>
	manufacturer, a URI to that information is discovered through		<t><xref target="the-mud-sbom-augmentation-to-the-mud-yang-model"/>
	interfaces such as MUD via DHCP or bootstrapping and ownership		describes a data model to extend the MUD file format to carry SBOM and
	transfer mechanisms.</t>		vulnerability information. <xref target="RFC8520" sectionFormat="of"
			section="1.5"/> describes mechanisms by which devices can emit a URL
	<t>Using the third method, a supplier may wish to make an SBOM or		to point to this file. Additionally, devices can share this URL
	vulnerability information available under certain circumstances, and		either through documentation or within a QR code on a box. <xref
	may need to individually evaluate requests. The result of that		target="the-well-known-transparency-endpoint-set"/> describes a
	evaluation might be the SBOM or vulnerability itself or a restricted		well-known URL from which an SBOM could be served from the local
	URL or no access.</t>		device.</t>
			<t>Note that vulnerability and SBOM information are likely to change
	<t>To enable application-layer discovery, this memo defines a well-known		at different rates. MUD's cache-validity node provides a way for
	URI <xref target="RFC8615"/>. Management or orchestration tools can query this		manufacturers to control how often tooling should check for those
	well-known URI to retrieve a system's SBOM information. Further		changes through the cache-validity node.</t>
	queries may be necessary based on the content and structure of the		</section>
	response.</t>		<section anchor="formats">
			<name>Formats</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		<t>There are multiple ways to express both SBOMs and vulnerability
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",		information. When these are retrieved either from the device or from
	"MAY", and "OPTIONAL" in this document are to be interpreted as		a remote web server, tools will need to observe the Content-Type
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and		header to determine precisely which format is being transmitted.
	only when, they		Because IoT devices in particular have limited capabilities, use of a
	appear in all capitals, as shown here.</t>		specific Accept: header in HTTP or the Accept Option in CoAP is
			<bcp14>NOT RECOMMENDED</bcp14>. Instead, backend tooling is
	<section anchor="how-this-information-is-retrieved"><name>How This Information I		encouraged to support all known formats and <bcp14>SHOULD</bcp14>
	s Retrieved</name>		silently discard SBOM information sent with a media type that is not
			understood.</t>
	<t>Section 4 describes a data model to extend the MUD file format to carry SBOM		<t>If multiple SBOMs are intended to be supported in the same file,
	and vulnerability information. Section 1.5 of RFC8520 describes mechanisms by		the media type should properly reflect that. For example, one might
	which devices can emit a URL to point to this file. Additionally, devices can		make use of application/{someformat}+json-seq. It is left to those
	share this URL either through documentation or within a QR code on a box.		supporting those formats to make the appropriate registrations in this
	Section 2 describes a well-known URL from which an SBOM could be served from		case.</t>
	the local device.</t>		<t>Some formats may support both vulnerability and software inventory
			information. When both vulnerability and software inventory
	<t>Note that vulnerability and SBOM information are likely to change at		information is available from the same URL, both sbom-url and members
	different rates. MUD's cache-validity node provides a way for		of the vuln-url list <bcp14>MUST</bcp14> indicate that. Network
	manufacturers to control how often tooling should check for those		management systems <bcp14>MUST</bcp14> take note of when the SBOM and
	changes through the cache-validity node.</t>		vulnerability information are accessible via the same resource and not
			retrieve the resource a second time.</t>
	</section>		</section>
	<section anchor="formats"><name>Formats</name>		</section>
	<t>There are multiple ways to express both SBOMs and vulnerability		<section anchor="the-well-known-transparency-endpoint-set">
	information. When these are retrieved either from the device		<name>The Well-Known Transparency Endpoint Set</name>
	or from a remote web server, tools will need to observe the		<t>A well-known endpoint is defined:</t>
	Content-Type header to determine precisely which format is being		<t indent="3">"/.well-known/sbom" retrieves an SBOM
	transmitted. Because IoT devices in particular have limited		</t>
	capabilities, use of a specific Accept: header in HTTP or the Accept		<t>As discussed previously, the precise format of a response is based on
	Option in CoAP is NOT RECOMMENDED. Instead, backend tooling is		the Content-Type provided.</t>
	encouraged to support all known formats, and SHOULD silently discard		</section>
	SBOM information sent with a media type that is not understood.</t>		<section anchor="the-mud-transparency-extension-model-extension">
			<name>The mud-transparency Extension</name>
	<t>If multiple SBOMs are intended to be supported in the same file, the		<t>We now formally define the mud-transparency extension; this is done in
	media type should properly reflect that. For example, one might make		two parts.</t>
	use of application/{someformat}+json-seq. It is left to those		<t>First, the extension name "transparency" is listed in the
	supporting those formats to make the appropriate registrations in this		"extensions" array of the MUD file. Note that this schema extension is
	case.</t>		intended to be used wherever it might be appropriate (e.g., not just
			with MUD).</t>
	<t>Some formats may support both vulnerability and software inventory		<t>Second, the "mud" container is augmented with a list of SBOM sources.</
	information. When both vulnerability and software inventory		t>
	information is available from the same URL, both sbom-url and members		<t>This is done as follows:</t>
	of the vuln-url list MUST indicate that. Network management systems		<sourcecode type="yangtree"><![CDATA[
	retrieving this information MUST take note that the identical resource
	is being retrieved rather than retrieving it twice.</t>
	</section>
	</section>
	<section 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" retrieves an SBOM.</t>
	</list></t>
	<t>As discussed previously, the precise format of a response is based on
	the Content-type provided.</t>
	</section>
	<section anchor="the-mud-transparency-extension-model-extension"><name>The mud-t
	ransparency extension model extension</name>
	<t>We now formally define this extension. This is done in two parts.
	First, the extension name "transparency" is listed in the "extensions"
	array of the MUD file. N.B., this schema extension is intended to be
	used wherever it might be appropriate (e.g., not just 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[
	module: ietf-mud-transparency		module: ietf-mud-transparency
	augment /mud:mud:		augment /mud:mud:
	+--rw transparency		+--rw transparency
	+--rw (sbom-retrieval-method)?		+--rw (sbom-retrieval-method)?
	| +--:(cloud)		| +--:(cloud)
	| | +--rw sboms* [version-info]		| | +--rw sboms* [version-info]
	| | +--rw version-info string		| | +--rw version-info string
	| | +--rw sbom-url? inet:uri		| | +--rw sbom-url? inet:uri
	| +--:(local-well-known)		| +--:(local-well-known)
	| | +--rw sbom-local-well-known? identityref		| | +--rw sbom-local-well-known? identityref
	| +--:(sbom-contact-info)		| +--:(sbom-contact-info)
	| +--rw sbom-contact-uri? inet:uri		| +--rw sbom-contact-uri? inet:uri
	+--rw sbom-archive-list? inet:uri		+--rw sbom-archive-list? inet:uri
	+--rw (vuln-retrieval-method)?		+--rw (vuln-retrieval-method)?
	+--:(cloud)		+--:(cloud)
	| +--rw vuln-url* inet:uri		| +--rw vuln-url* inet:uri
	+--:(vuln-contact-info)		+--:(vuln-contact-info)
	+--rw vuln-contact-uri? inet:uri		+--rw vuln-contact-uri? inet:uri
	]]></artwork></figure>		]]></sourcecode>
	<t>See <xref target="RFC8340"/> for a description of YANG trees.</t>		<t>See <xref target="RFC8340"/> for a description of YANG trees.</t>
	</section>		</section>
	<section anchor="the-mud-sbom-augmentation-to-the-mud-yang-model"><name>The mud-		<section anchor="the-mud-sbom-augmentation-to-the-mud-yang-model">
	sbom augmentation to the MUD YANG model</name>
	<figure><artwork><![CDATA[		<name>The mud-sbom Augmentation to the MUD YANG Data Model</name>
	<CODE BEGINS>file "ietf-mud-transparency@2023-01-12.yang"
			<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" marke
			rs="true"><![CDATA[
	module ietf-mud-transparency {		module ietf-mud-transparency {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-mud-transparency";		namespace "urn:ietf:params:xml:ns:yang:ietf-mud-transparency";
	prefix mudtx;		prefix mudtx;
	import ietf-inet-types {		import ietf-inet-types {
	prefix inet;		prefix inet;
	reference		reference
	"RFC 6991";		"RFC 6991: Common YANG Data Types";
	}		}
	import ietf-mud {		import ietf-mud {
	prefix mud;		prefix mud;
	reference		reference
	"RFC 8520";		"RFC 8520: Manufacturer Usage Description Specification";
	}		}
	organization		organization
	"IETF OPSAWG (Ops Area) Working Group";		"IETF OPSAWG (Ops Area) Working Group";
	contact		contact
	"WG Web: https://datatracker.ietf.org/wg/opsawg/		"WG Web: <https://datatracker.ietf.org/wg/opsawg/>
	WG List: opsawg@ietf.org		WG List: <opsawg@ietf.org>
	Editor: Eliot Lear lear@cisco.com		Editor: Eliot Lear <lear@cisco.com>
	Editor: Scott Rose scott.rose@nist.gov";		Editor: Scott Rose <scott.rose@nist.gov>";
	description		description
	"This YANG module augments the ietf-mud model to provide for		"This YANG module augments the ietf-mud model to provide for
	reporting of SBOMs and vulnerability information.		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		Copyright (c) 2023 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject to		without modification, is permitted pursuant to, and subject to
	the license terms contained in, the Revised BSD License set		the license terms contained in, the Revised BSD License set
	forth in Section 4.c of the IETF Trust's Legal Provisions		forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(https://trustee.ietf.org/license-info).		(https://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX		This version of this YANG module is part of RFC 9472
	(https://www.rfc-editor.org/info/rfcXXXX);		(https://www.rfc-editor.org/info/rfc9472);
	see the RFC itself for full legal notices.		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. ";
	revision 2023-01-12 {		revision 2023-09-08 {
	description		description
	"Initial proposed standard.";		"Initial proposed standard.";
	reference		reference
	"RFC XXXX: Discovering and Retrieving Software Transparency		"RFC 9472: A YANG Data Model for Reporting Software Bills
	and Vulnerability Information";		of Materials (SBOMs) and Vulnerability Information";
	}		}
	identity local-type {		identity local-type {
	description		description
	"Base identity for local-well-known choices";		"Base identity for local well-known choices.";
	}		}
	identity http {		identity http {
	base mudtx:local-type;		base mudtx:local-type;
	description		description
	"Use http[RFC7231] (insecure) to retrieve SBOM information.		"Use http (RFC 7231) (insecure) to retrieve SBOM information.
	This method is NOT RECOMMENDED, but may be unavoidable for		This method is NOT RECOMMENDED but may be unavoidable for
	certain classes of deployment, where TLS has not or		certain classes of deployment where TLS has not or
	cannot be implemented";		cannot be implemented.";
			reference
			"RFC 7231: Hypertext Transfer Protocol (HTTP/1.1):
			Semantics and Content";
	}		}
	identity https {		identity https {
	base mudtx:local-type;		base mudtx:local-type;
	description		description
	"Use https (secure) to retrieve SBOM information. See		"Use https (secure) to retrieve SBOM information. See
	RFC 9110.";		RFC 9110.";
			reference
			"RFC 9110: HTTP Semantics";
	}		}
	identity coap {		identity coap {
	base mudtx:local-type;		base mudtx:local-type;
	description		description
	"Use COAP [RFC7252] (insecure) to retrieve SBOM. This method		"Use COAP (RFC 7252) (insecure) to retrieve SBOM. This method
	is NOT RECOMMENDED, although it may be unavoidable		is NOT RECOMMENDED, although it may be unavoidable
	for certain classes of implementations/deployments.";		for certain classes of implementations/deployments.";
			reference
			"RFC 7252: The Constrained Application Protocol (CoAP)";
	}		}
	identity coaps {		identity coaps {
	base mudtx:local-type;		base mudtx:local-type;
	description		description
	"Use COAPS (secure) to retrieve SBOM [RFC7252]";		"Use COAPS (secure) to retrieve SBOM (RFC 7252).";
	}		}
	grouping transparency-extension {		grouping transparency-extension {
	description		description
	"This grouping provides a means to describe the location of		"This grouping provides a means to describe the location of
	software bills of material and vulnerability descriptions.";		software bills of material and vulnerability descriptions.";
	container transparency {		container transparency {
	description		description
	"Container of methods to get SBOMs and vulnerability		"Container of methods to get SBOMs and vulnerability
	information.";		information.";
	choice sbom-retrieval-method {		choice sbom-retrieval-method {
	description		description
	"How to find SBOM information";		"How to find SBOM information.";
	case cloud {		case cloud {
	list sboms {		list sboms {
	key "version-info";		key "version-info";
	description		description
	"A list of SBOMs tied to different software		"A list of SBOMs tied to different software
	or hardware versions.";		or hardware versions.";
	leaf version-info {		leaf version-info {
	type string;		type string;
	description		description
	"The version to which this SBOM refers.";		"The version to which this SBOM refers.";
	skipping to change at line 409 ¶		skipping to change at line 409 ¶
	description		description
	"Which communication protocol to choose.";		"Which communication protocol to choose.";
	}		}
	}		}
	case sbom-contact-info {		case sbom-contact-info {
	leaf sbom-contact-uri {		leaf sbom-contact-uri {
	type inet:uri {		type inet:uri {
	pattern '((mailto)|(https?)|(tel)):.*';		pattern '((mailto)|(https?)|(tel)):.*';
	}		}
	description		description
	"This MUST be either a tel, http, https, or		"This MUST be a tel, an http, an https, or
	mailto uri schema that customers can use to		a mailto uri schema that customers can use to
	contact someone for SBOM information.";		contact someone for SBOM information.";
	}		}
	}		}
	}		}
	leaf sbom-archive-list {		leaf sbom-archive-list {
	type inet:uri;		type inet:uri;
	description		description
	"This URI returns a JSON list of URLs that consist of		"This URI returns a JSON list of URLs that consist of
	SBOMs that were previously published for this		SBOMs that were previously published for this
	device. Publication dates can be found inside		device. Publication dates can be found inside
	the SBOMs.";		the SBOMs.";
	}		}
	choice vuln-retrieval-method {		choice vuln-retrieval-method {
	description		description
	"How to find vulnerability information";		"How to find vulnerability information.";
	case cloud {		case cloud {
	leaf-list vuln-url {		leaf-list vuln-url {
	type inet:uri;		type inet:uri;
	description		description
	"List of statically located URLs that reference		"List of statically located URLs that reference
	vulnerability information";		vulnerability information.";
	}		}
	}		}
	case vuln-contact-info {		case vuln-contact-info {
	leaf vuln-contact-uri {		leaf vuln-contact-uri {
	type inet:uri {		type inet:uri {
	pattern '((mailto)|(https?)|(tel)):.*';		pattern '((mailto)|(https?)|(tel)):.*';
	}		}
	description		description
	"This MUST be either a tel, http, https, or		"This MUST be a tel, an http, an https, or
	mailto uri schema that customers can use to		a mailto uri schema that customers can use to
	contact someone for vulnerability information.";		contact someone for vulnerability information.";
	}		}
	}		}
	}		}
	}		}
	}		}
	augment "/mud:mud" {		augment "/mud:mud" {
	description		description
	"Add extension for software transparency.";		"Add extension for software transparency.";
	uses transparency-extension;		uses transparency-extension;
	}		}
	}		}
	<CODE ENDS>		]]></sourcecode>
	]]></artwork></figure>
	</section>
	<section 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, the 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 ACLS</name>
	<t>This first MUD file demonstrates how to get SBOM and		</section>
			<section 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 that the 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 ACLS</name>
			<t>This first MUD file demonstrates how to get SBOM and
	vulnerability information without ACLs.</t>		vulnerability information without ACLs.</t>
	<figure><artwork><![CDATA[		<sourcecode type="json"><![CDATA[
	{		{
	"ietf-mud:mud": {		"ietf-mud:mud": {
	"mud-version": 1,		"mud-version": 1,
	"extensions": [		"extensions": [
	"transparency"		"transparency"
	],		],
	"mudtx:transparency": {		"mudtx:transparency": {
	"sbom-url": "https://iot.example.com/info/modelX/sbom.json",		sboms: [ {
	"vuln-url" : [		"version-info": "1.2",
	"https://iotd.example.com/info/modelX/csaf.json"		"sbom-url": "https://iot.example.com/info/modelX/sbom.json"
	]		} ],
	},		"vuln-url" : [
	"mud-url": "https://iot.example.com/modelX.json",		"https://iotd.example.com/info/modelX/csaf.json"
	"mud-signature": "https://iot.example.com/modelX.p7s",		]
	"last-update": "2022-01-05T13:29:12+00:00",		},
	"cache-validity": 48,		"mud-url": "https://iot.example.com/modelX.json",
	"is-supported": true,		"mud-signature": "https://iot.example.com/modelX.p7s",
	"systeminfo": "retrieving vuln and SBOM info via a cloud service",		"last-update": "2022-01-05T13:29:12+00:00",
	"mfg-name": "Example, Inc.",		"cache-validity": 48,
	"documentation": "https://iot.example.com/doc/modelX",		"is-supported": true,
	"model-name": "modelX"		"systeminfo": "retrieving vuln and SBOM info via a cloud service",
	}		"mfg-name": "Example, Inc.",
	}		"documentation": "https://iot.example.com/doc/modelX",
	]]></artwork></figure>		"model-name": "modelX"
			}
			}]]></sourcecode>
	<t>The second example demonstrates that just SBOM information is included		<t>The second example demonstrates that just SBOM information is
	from the cloud.</t>		included from the cloud.</t>
	<figure><artwork><![CDATA[		<sourcecode type="json"><![CDATA[
	{		{
	"ietf-mud:mud": {		"ietf-mud:mud": {
	"mud-version": 1,		"mud-version": 1,
	"extensions": [		"extensions": [
	"transparency"		"transparency"
	],		],
	"mudtx:transparency": {		"mudtx:transparency": {
	"sbom-url": "https://iot.example.com/info/modelX/sbom.json"		sboms: [ {
	},		"version-info": "1.2",
	"mud-url": "https://iot.example.com/modelX.json",		"sbom-url": "https://iot.example.com/info/modelX/sbom.json"
	"mud-signature": "https://iot.example.com/modelX.p7s",		} ],
	"last-update": "2022-01-05T13:29:12+00:00",		},
	"cache-validity": 48,		"mud-url": "https://iot.example.com/modelX.json",
	"is-supported": true,		"mud-signature": "https://iot.example.com/modelX.p7s",
	"systeminfo": "retrieving only SBOM info via a cloud service",		"last-update": "2022-01-05T13:29:12+00:00",
	"mfg-name": "Example, Inc.",		"cache-validity": 48,
	"documentation": "https://iot.example.com/doc/modelX",		"is-supported": true,
	"model-name": "modelX"		"systeminfo": "retrieving vuln and SBOM info via a cloud service",
	}		"mfg-name": "Example, Inc.",
	}		"documentation": "https://iot.example.com/doc/modelX",
	]]></artwork></figure>		"model-name": "modelX"
			}
	</section>		}]]></sourcecode>
	<section anchor="sbom-located-on-the-device"><name>SBOM Located on the Device</n		</section>
	ame>		<section 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		<t>In the next example, the SBOM is located on the device, and there
	vulnerability information provided.</t>		is no vulnerability information provided.</t>
	<figure><artwork><![CDATA[		<sourcecode type="json"><![CDATA[
	{		{
	"ietf-mud:mud": {		"ietf-mud:mud": {
	"mud-version": 1,		"mud-version": 1,
	"extensions": [		"extensions": [
	"transparency"		"transparency"
	],		],
	"mudtx:transparency": {		"mudtx:transparency": {
	"sbom-local-well-known": "https"		"sbom-local-well-known": "https"
	},		},
	"mud-url": "https://iot.example.com/modelX.json",		"mud-url": "https://iot.example.com/modelX.json",
	"mud-signature": "https://iot.example.com/modelX.p7s",		"mud-signature": "https://iot.example.com/modelX.p7s",
	"last-update": "2022-01-05T13:29:47+00:00",		"last-update": "2022-01-05T13:29:47+00:00",
	"cache-validity": 48,		"cache-validity": 48,
	"is-supported": true,		"is-supported": true,
	"systeminfo": "retrieving SBOM info from a local source",		"systeminfo": "retrieving SBOM info from a local source",
	"mfg-name": "Example, Inc.",		"mfg-name": "Example, Inc.",
	"documentation": "https://iot.example.com/doc/modelX",		"documentation": "https://iot.example.com/doc/modelX",
	"model-name": "modelX"		"model-name": "modelX"
	}		}
	}		}]]></sourcecode>
	]]></artwork></figure>
	<t>In this example, the SBOM is retrieved from the device, while		<t>In this example, the SBOM is retrieved from the device, while
	vulnerability information is available from the cloud. This is likely		vulnerability information is available from the cloud. This is likely
	a common case, because vendors may learn of vulnerability information		a common case because vendors may learn of vulnerability information
	more frequently than they update software.</t>		more frequently than they update software.</t>
	<figure><artwork><![CDATA[		<sourcecode type="json"><![CDATA[
	{		{
	"ietf-mud:mud": {		"ietf-mud:mud": {
	"mud-version": 1,		"mud-version": 1,
	"extensions": [		"extensions": [
	"transparency"		"transparency"
	],		],
	"mudtx:transparency": {		"mudtx:transparency": {
	"sbom-local-well-known": "https",		"sbom-local-well-known": "https",
	"vuln-url" : [		"vuln-url" : [
	"https://iotd.example.com/info/modelX/csaf.json"		"https://iotd.example.com/info/modelX/csaf.json"
	]		]
	},		},
	"mud-url": "https://iot-device.example.com/modelX.json",		"mud-url": "https://iot-device.example.com/modelX.json",
	"mud-signature": "https://iot-device.example.com/modelX.p7s",		"mud-signature": "https://iot-device.example.com/modelX.p7s",
	"last-update": "2022-01-05T13:25:14+00:00",		"last-update": "2022-01-05T13:25:14+00:00",
	"cache-validity": 48,		"cache-validity": 48,
	"is-supported": true,		"is-supported": true,
	"systeminfo": "mixed example: SBOM on device, vuln info in cloud",		"systeminfo": "mixed example: SBOM on device, vuln info in cloud",
	"mfg-name": "Example, Inc.",		"mfg-name": "Example, Inc.",
	"documentation": "https://iot-device.example.com/doc/modelX",		"documentation": "https://iot-device.example.com/doc/modelX",
	"model-name": "modelX"		"model-name": "modelX"
	}		}
	}		}]]></sourcecode>
	]]></artwork></figure>
	</section>
	<section anchor="further-contact-required"><name>Further contact required.</name
	>
	<t>In this example, the network manager must take further steps		</section>
			<section 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		to retrieve SBOM information. Vulnerability information is
	still available.</t>		still available.</t>
	<figure><artwork><![CDATA[		<sourcecode type="json"><![CDATA[
	{		{
	"ietf-mud:mud": {		"ietf-mud:mud": {
	"mud-version": 1,		"mud-version": 1,
	"extensions": [		"extensions": [
	"transparency"		"transparency"
	],		],
	"ietf-mud-transparency:transparency": {		"mudtx:transparency": {
	"contact-info": "https://iot-device.example.com/contact-info.html",		"contact-info": "https://iot-device.example.com/contact-info.html",
	"vuln-url" : [		"vuln-url" : [
	"https://iotd.example.com/info/modelX/csaf.json"		"https://iotd.example.com/info/modelX/csaf.json"
	]		]
	},		},
	"mud-url": "https://iot-device.example.com/modelX.json",		"mud-url": "https://iot-device.example.com/modelX.json",
	"mud-signature": "https://iot-device.example.com/modelX.p7s",		"mud-signature": "https://iot-device.example.com/modelX.p7s",
	"last-update": "2021-07-09T06:16:42+00:00",		"last-update": "2021-07-09T06:16:42+00:00",
	"cache-validity": 48,		"cache-validity": 48,
	"is-supported": true,		"is-supported": true,
	"systeminfo": "retrieving vuln and SBOM info via a cloud service",		"systeminfo": "retrieving vuln and SBOM info via a cloud service",
	"mfg-name": "Example, Inc.",		"mfg-name": "Example, Inc.",
	"documentation": "https://iot-device.example.com/doc/modelX",		"documentation": "https://iot-device.example.com/doc/modelX",
	"model-name": "modelX"		"model-name": "modelX"
	}
	}		}
	]]></artwork></figure>		}]]></sourcecode>
	</section>
	<section anchor="with-acls"><name>With ACLS</name>
	<t>Finally, here is a complete example where the device provides		</section>
	SBOM and vulnerability information, as well as access-control		<section anchor="with-acls">
			<name>With ACLS</name>
			<t>Finally, here is a complete example where the device provides
			SBOM and vulnerability information as well as access control
	information.</t>		information.</t>
	<figure><artwork><![CDATA[		<sourcecode type="json"><![CDATA[
	{		{
	"ietf-mud:mud": {		"ietf-mud:mud": {
	"mud-version": 1,		"mud-version": 1,
	"extensions": [		"extensions": [
	"transparency"		"transparency"
	],		],
	"mudtx:transparency": {		"mudtx:transparency": {
	"sbom-local-well-known": "https",		"sbom-local-well-known": "https",
	"vuln-url" : [		"vuln-url" : [
	"https://iotd.example.com/info/modelX/csaf.json"		"https://iotd.example.com/info/modelX/csaf.json"
	]		]
	},		},
	"mud-url": "https://iot.example.com/modelX.json",		"mud-url": "https://iot.example.com/modelX.json",
	"mud-signature": "https://iot.example.com/modelX.p7s",		"mud-signature": "https://iot.example.com/modelX.p7s",
	"last-update": "2022-01-05T13:30:31+00:00",		"last-update": "2022-01-05T13:30:31+00:00",
	"cache-validity": 48,		"cache-validity": 48,
	"is-supported": true,		"is-supported": true,
	"systeminfo": "retrieving vuln and SBOM info via a cloud service",		"systeminfo": "retrieving vuln and SBOM info via a cloud service",
	"mfg-name": "Example, Inc.",		"mfg-name": "Example, Inc.",
	"documentation": "https://iot.example.com/doc/modelX",		"documentation": "https://iot.example.com/doc/modelX",
	"model-name": "modelX",		"model-name": "modelX",
	"from-device-policy": {		"from-device-policy": {
	"access-lists": {		"access-lists": {
	"access-list": [		"access-list": [
	{		{
	"name": "mud-65443-v4fr"		"name": "mud-65443-v4fr"
	}		}
	]		]
	}		}
	},		},
	"to-device-policy": {		"to-device-policy": {
	"access-lists": {		"access-lists": {
	"access-list": [		"access-list": [
	{		{
	"name": "mud-65443-v4to"		"name": "mud-65443-v4to"
	}		}
	]		]
	}		}
	}		}
	},		},
	"ietf-access-control-list:acls": {		"ietf-access-control-list:acls": {
	"acl": [		"acl": [
	{		{
	"name": "mud-65443-v4to",		"name": "mud-65443-v4to",
	"type": "ipv4-acl-type",		"type": "ipv4-acl-type",
	"aces": {		"aces": {
	"ace": [		"ace": [
	{		{
	"name": "cl0-todev",		"name": "cl0-todev",
	"matches": {		"matches": {
	"ipv4": {		"ipv4": {
	"ietf-acldns:src-dnsname": "iotserver.example.com"		"ietf-acldns:src-dnsname": "iotserver.example.com"
	}		}
	},		},
	"actions": {		"actions": {
	"forwarding": "accept"		"forwarding": "accept"
	}		}
	}		}
	]		]
	}		}
	},		},
	{		{
	"name": "mud-65443-v4fr",		"name": "mud-65443-v4fr",
	"type": "ipv4-acl-type",		"type": "ipv4-acl-type",
	"aces": {		"aces": {
	"ace": [		"ace": [
	{		{
	"name": "cl0-frdev",		"name": "cl0-frdev",
	"matches": {		"matches": {
	"ipv4": {		"ipv4": {
	"ietf-acldns:dst-dnsname": "iotserver.example.com"		"ietf-acldns:dst-dnsname": "iotserver.example.com"
	}		}
	},		},
	"actions": {		"actions": {
	"forwarding": "accept"		"forwarding": "accept"
	}		}
	}		}
	]		]
	}		}
	}		}
	]		]
	}		}
	}		}]]></sourcecode>
	]]></artwork></figure>
	<t>At this point, the management system can attempt to retrieve the SBOM,
	and determine which format is in use through the content-type header
	on the response to a GET request, independently repeat the process for
	vulnerability information, and apply ACLs, as appropriate.</t>
	</section>
	</section>
	<section anchor="security-considerations"><name>Security Considerations</name>
	<t>This document describes a schema for discovering the location of
	information relating to software 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> or RESTCONF <xref target="RFC8040"></xref>, and h
	ence the regular security
	considerations for such usage are not considered here.</t>
	<t>We describe below protections relating to both discovery and some
	advice on protecting the underlying SBOM/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 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, 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 no means, for instance, to upload an
	SBOM. Additional risks are discussed 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 information retrieved would be false.</t>
	<t>the URLs themselves point to malware.</t>
	</list></t>
	<t>To address either risk, any change in a URL, and in particular to the
	authority section, two approaches may be used:</t>
	<t><list style="symbols">
	<t>test any cloud-based URL against a reputation service.</t>
	<t>provide the administrator an opportunity to approve further procesisng
	when the authority changes to one not known to be reputable.</t>
	</list></t>
	<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 provide
	unrestricted access to the well-known URL by default.</t>
	<t>Other servers that offer the data MAY 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 in combination. In
	particular, if a system attempts to retrieve an SBOM via HTTP or COAP
	and the client is not authorized, the server MUST produce an
	appropriate 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
	recommend network access controls.</t>
	<t>Vulnerability information is generally made available to such
	databases as NIST's National Vulnerability Database <xref target="NISTNVD"/>. I
	t
	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 be applied to that information.</t>
	</section>
	<section anchor="iana-considerations"><name>IANA Considerations</name>
	<section anchor="mud-extension"><name>MUD Extension</name>
	<t>The IANA is requested to add "transparency" to the MUD
	extensions registry as follows:</t>
	<figure><artwork><![CDATA[
	Extension Name: transparency
	Standard reference: This document
	]]></artwork></figure>
	</section>
	<section anchor="yang-registration"><name>YANG Registration</name>
	<t>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>
	<t>The following XML registration is requested:</t>
	<figure><artwork><![CDATA[		<t>At this point, the management system can attempt to retrieve the
	URI: urn:ietf:params:xml:ns:yang:ietf-mud-transparency		SBOM, determine which format is in use through the Content-Type
	Registrant Contact: IESG		header on the response to a GET request, independently repeat the
	XML: None. Namespace URIs do not represent an XML specification.		process for vulnerability information, and apply ACLs as
	]]></artwork></figure>		appropriate.</t>
			</section>
			</section>
	</section>		<section anchor="security-considerations">
	<section anchor="well-known-prefix"><name>Well-Known Prefix</name>		<name>Security Considerations</name>
			<t>This document describes a schema for discovering the location of
			information relating to software 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 NETCONF <xref target="RF
			C6241"/> or RESTCONF
			<xref target="RFC8040"/>, and hence the regular security considerations
			for such usage are not considered here.</t>
			<t>Below, we describe protections relating to both discovery and some
			advice on protecting the underlying 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 <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 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 are no means, for instance, to upload an SBOM.
			Additional risks are discussed 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>
			<ul spacing="normal">
			<li>the information retrieved would be false</li>
			<li>the URLs themselves point to malware</li>
			</ul>
	<t>The following well known URI is requested in accordance with		<t>To address either of these risks or any tampering of a URL:</t>
	<xref target="RFC8615"/>:</t>		<ul spacing="normal">
			<li>test any cloud-based URL against a reputation service</li>
			<li>provide the administrator an opportunity to approve further
			processing when the authority changes to one not known to be
			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 already be able to derive this
			very same software inventory. When this information resides on the
			endpoint itself, the endpoint <bcp14>SHOULD NOT</bcp14> provide
			unrestricted access to the well-known URL by default.</t>
			<t>Other servers that offer the data <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 in combination. In particular,
			if a system attempts to retrieve an SBOM via HTTP or CoAP and the client
			is not authorized, the server <bcp14>MUST</bcp14> produce an appropriate
			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
			<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 <bcp14>SHOULD</bcp14> be applied to that
			information.</t>
			</section>
	<figure><artwork><![CDATA[		<section anchor="iana-considerations">
	URI suffix: "sbom"		<name>IANA Considerations</name>
	Change controller: "IETF"		<section anchor="mud-extension">
	Specification document: This memo		<name>MUD Extension</name>
	Related information: See ISO/IEC 5962:2021 and SPDX.org		<t>IANA has added "transparency" to the "MUD Extensions"
			registry <xref target="RFC8520"/> as follows:</t>
			<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 Registration</name>
	]]></artwork></figure>		<t>IANA has registered the following YANG module in the "YANG Module
			Names" 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>
	</section>		<t>The following URI has been registered in the "IETF XML Registry" <xre
	</section>		f target="RFC3688"/>:</t>
	<section anchor="acknowledgments"><name>Acknowledgments</name>		<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.</dd>
			</dl>
	<t>Thanks to Russ Housley, Dick Brooks, Tom Petch, Nicolas Comstedt, who		</section>
	provided review comments.</t>		<section anchor="well-known-prefix">
			<name>Well-Known Prefix</name>
			<t>IANA has added the following URI suffix to the "Well-Known URIs" regi
			stry
			in accordance with <xref target="RFC8615"/>:</t>
			<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</dd>
			</dl>
	</section>		</section>
			</section>
	</middle>		</middle>
	<back>		<back>
			<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
			119.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.36
			88.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.60
			20.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
			241.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
			991.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			231.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			252.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			040.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			174.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			110.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			520.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			615.xml"/>
			</references>
			<references>
			<name>Informative References</name>
	<references title='Normative References'>		<reference anchor="EO2021">
			<front>
	<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>		<title>Executive Order on Improving the Nation's Cybersecurity</titl
	<front>		e>
	<title>Key words for use in RFCs to Indicate Requirement Levels</title>		<author initials="J." surname="Biden" fullname="Joseph Biden">
	<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></a		<organization>The White House</organization>
	uthor>		</author>
	<date month='March' year='1997'/>		<date year="2021" month="May"/>
	<abstract><t>In many standards track documents several words are used to signify		</front>
	the requirements in the specification. These words are often capitalized. This		<refcontent>EO 14028</refcontent>
	document defines these words as they should be interpreted in IETF documents.		</reference>
	This document specifies an Internet Best Current Practices for the Internet Comm
	unity, 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'><organizat
	ion/></author>
	<author fullname='M. Bjorklund' initials='M.' role='editor' surname='Bjorklund'>
	<organization/></author>
	<author fullname='J. Schoenwaelder' initials='J.' role='editor' surname='Schoenw
	aelder'><organization/></author>
	<author fullname='A. Bierman' initials='A.' role='editor' surname='Bierman'><org
	anization/></author>
	<date month='June' year='2011'/>
	<abstract><t>The Network Configuration Protocol (NETCONF) defined in this docume
	nt provides mechanisms to install, manipulate, and delete the configuration of n
	etwork devices. It uses an Extensible Markup Language (XML)-based data encoding
	for the configuration data as well as the protocol messages. The NETCONF proto
	col operations are realized as remote procedure calls (RPCs). This document obs
	oletes 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='Schoenw
	aelder'><organization/></author>
	<date month='July' year='2013'/>
	<abstract><t>This document introduces a collection of common data types to be us
	ed 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/></aut
	hor>
	<author fullname='K. Hartke' initials='K.' surname='Hartke'><organization/></aut
	hor>
	<author fullname='C. Bormann' initials='C.' surname='Bormann'><organization/></a
	uthor>
	<date month='June' year='2014'/>
	<abstract><t>The Constrained Application Protocol (CoAP) is a specialized web tr
	ansfer protocol for use with constrained nodes and constrained (e.g., low-power,
	lossy) networks. The nodes often have 8-bit microcontrollers with small amount
	s of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireles
	s Personal Area Networks (6LoWPANs) often have high packet error rates and a typ
	ical throughput of 10s of kbit/s. The protocol is designed for machine- to-mach
	ine (M2M) applications such as smart energy and building automation.</t><t>CoAP
	provides a request/response interaction model between application endpoints, sup
	ports 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 inte
	rface with HTTP for integration with the Web while meeting specialized requireme
	nts 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/></a
	uthor>
	<author fullname='M. Bjorklund' initials='M.' surname='Bjorklund'><organization/
	></author>
	<author fullname='K. Watsen' initials='K.' surname='Watsen'><organization/></aut
	hor>
	<date month='January' year='2017'/>
	<abstract><t>This document describes an HTTP-based protocol that provides a prog
	rammatic interface for accessing data defined in YANG, using the datastore conce
	pts 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/></autho
	r>
	<date month='May' year='2017'/>
	<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
	pecifications. This document aims to reduce the ambiguity by clarifying that on
	ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
	tract>
	</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'><o
	rganization/></author>
	<author fullname='M. Nottingham' initials='M.' role='editor' surname='Nottingham
	'><organization/></author>
	<author fullname='J. Reschke' initials='J.' role='editor' surname='Reschke'><org
	anization/></author>
	<date month='June' year='2022'/>
	<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-l
	evel protocol for distributed, collaborative, hypertext information systems. Thi
	s document describes the overall architecture of HTTP, establishes common termin
	ology, and defines aspects of the protocol that are shared by all versions. In t
	his definition are core protocol elements, extensibility mechanisms, and the &qu
	ot;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'>		<reference anchor="SPDX" target="https://spdx.github.io/spdx-spec/v2.3/"
	<front>		>
	<title>Manufacturer Usage Description Specification</title>		<front>
	<author fullname='E. Lear' initials='E.' surname='Lear'><organization/></author>		<title>The Software Package Data Exchange (SPDX) Specification
	<author fullname='R. Droms' initials='R.' surname='Droms'><organization/></autho		</title>
	r>		<author>
	<author fullname='D. Romascanu' initials='D.' surname='Romascanu'><organization/		<organization>The Linux Foundation</organization>
	></author>		</author>
	<date month='March' year='2019'/>		<date year="2022"/>
	<abstract><t>This memo specifies a component-based architecture for Manufacturer		</front>
	Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devic		<refcontent>Version 2.3</refcontent>
	es to signal to the network what sort of access and network functionality they r		</reference>
	equire to properly function. The initial focus is on access control. Later wor
	k 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'>		<reference anchor="CycloneDX15" target="https://cyclonedx.org/docs/1.5/j
	<front>		son">
	<title>Well-Known Uniform Resource Identifiers (URIs)</title>		<front>
	<author fullname='M. Nottingham' initials='M.' surname='Nottingham'><organizatio		<title>CycloneDX v1.5 JSON Reference</title>
	n/></author>		<author>
	<date month='May' year='2019'/>		<organization>CycloneDX</organization>
	<abstract><t>This memo defines a path prefix for &quot;well-known locations&quot		</author>
	;, &quot;/.well-known/&quot;, in selected Uniform Resource Identifier (URI) sche		</front>
	mes.</t><t>In doing so, it obsoletes RFC 5785 and updates the URI schemes define		<refcontent>Version 1.5.0</refcontent>
	d in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI sche		</reference>
	mes 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>		<reference anchor="CSAF" target="https://docs.oasis-open.org/csaf/csaf/v
			2.0/csaf-v2.0.html">
			<front>
			<title>Common Security Advisory Framework Version 2.0</title>
			<author initials="L." surname="Rock" fullname="Langley Rock" role="e
			ditor">
			<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" ro
			le="editor">
			<organization>OASIS</organization>
			</author>
			<date year="2022" month="November"/>
			</front>
			<refcontent>OASIS Standard</refcontent>
			</reference>
	<references title='Informative References'>		<reference anchor="CVRF" target="https://docs.oasis-open.org/csaf/csaf-c
			vrf/v1.2/csaf-cvrf-v1.2.pdf">
			<front>
			<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="EO2021" >		<reference anchor="NISTNVD" target="https://nvd.nist.gov">
	<front>		<front>
	<title>Executive Order 14028, Improving the Nations Cybersecurity</title>		<title>National Vulnerability Database</title>
	<author initials="J." surname="Biden" fullname="President Joseph Biden">		<author>
	<organization>United States Of America</organization>		<organization>NIST</organization>
	</author>		</author>
	<date year="2021" month="May"/>		</front>
	</front>		</reference>
	</reference>
	<reference anchor="SPDX" target="https://spdx.github.io/spdx-spec/v2.3/">
	<front>
	<title>SPDX Specification V2.3</title>
	<author >
	<organization>The Linux Foundation</organization>
	</author>
	<date year="2022"/>
	</front>
	</reference>
	<reference anchor="CycloneDX12" >
	<front>
	<title>CycloneDX XML Reference v1.2</title>
	<author >
	<organization>cyclonedx.org</organization>
	</author>
	<date year="2020" month="May"/>
	</front>
	</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="edit
	or">
	<organization>OASIS</organization>
	</author>
	<date year="2022" month="November"/>
	</front>
	</reference>
	<reference anchor="CVRF" target="https://docs.oasis-open.org/csaf/csaf-cvrf/v1.2
	/csaf-cvrf-v1.2.pdf">
	<front>
	<title>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>
	</reference>
	<reference anchor="NISTNVD" target="https://nvd.nist.gov">
	<front>
	<title>National Vulnerability Database</title>
	<author >
	<organization>NIST</organization>
	</author>
	<date year="n.d."/>
	</front>
	</reference>
	<reference anchor='RFC8340' target='https://www.rfc-editor.org/info/rfc8340'>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<front>		340.xml"/>
	<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'><organ
	ization/></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 evolutio
	n 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>
			</references>
	</references>		</references>
			<section anchor="acknowledgments" toc="default" numbered="false">
	<section anchor="changes-from-earlier-versions"><name>Changes from Earlier Versi		<name>Acknowledgments</name>
	ons</name>		<t>Thanks to <contact fullname="Russ Housley"/>, <contact fullname="Dick
			Brooks"/>, <contact fullname="Tom Petch"/>, and <contact
	<t>[[This section to be removed by RFC Editor]]</t>		fullname="Nicolas Comstedt"/>, who provided review comments.</t>
			</section>
	<t>Please see https://github.com/elear/mud-sbom for changes.</t>
	</section>
	</back>		</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>		</rfc>
End of changes. 86 change blocks.
	1070 lines changed or deleted		698 lines changed or added
This html diff was produced by rfcdiff 1.48.