<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.4 (Ruby 2.6.6) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" number="9238" docName="draft-richardson-mud-qrcode-07" obsoletes="" updates="" submissionType="independent" category="info" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.12.0 -->
  <front>
    <title abbrev="QR-MUD">On loading abbrev="Loading MUD URLs from QR codes</title> Codes">Loading Manufacturer Usage Description (MUD) URLs from QR Codes</title>
    <seriesInfo name="Internet-Draft" value="draft-richardson-mud-qrcode-07"/> name="RFC" value="9238"/>
    <author initials="M." surname="Richardson" fullname="Michael Richardson">
      <organization>Sandelman Software Works</organization>
      <address>
        <email>mcr+ietf@sandelman.ca</email>
      </address>
    </author>
    <author initials="J." surname="Latour" fullname="Jacques Latour">
      <organization>CIRA Labs</organization>
      <address>
        <email>Jacques.Latour@cira.ca</email>
      </address>
    </author>
    <author initials="H." surname="Habibi Gharakheili" fullname="Hassan Habibi Gharakheili">
      <organization>UNSW Sydney</organization>
      <address>
        <email>h.habibi@unsw.edu.au</email>
      </address>
    </author>
    <date year="2022" month="March" day="21"/> month="May"/>
    <area>Internet</area>
    <keyword>Internet-Draft</keyword>

<keyword>RLA</keyword>
<keyword>ISOIEC189004</keyword>
<keyword>ANSI MH10.8.2</keyword>

    <abstract>
      <t>This informational document details a protocol to load MUD definitions
for devices which have no integrated Manufacturer Usage Description (MUD) as described in RFC8520.</t> definitions from RFC 8520
for devices that do not have them integrated.</t>
      <t>This document is published to inform the Internet community of this mechanism to allow
interoperability and to serve as a basis of other standards work if there is interest.</t>
      <t><cref anchor="track">RFC-EDITOR-please-remove: This work is tracked at https://github.com/mcr/mud-qrcode</cref></t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>The Manufacturer Usage Description (MUD) <xref target="RFC8520"/> defines a YANG data model to express what sort of access a device requires to operate correctly.
That document additionally defines three ways for the device to
to
communicate to a network enforcement point the MUD URL, i.e., URL (i.e., the URL of the resulting MUD file in JSON <xref target="RFC8259"/>: target="RFC8259"/>) to a network enforcement point: via DHCP, within an X.509 certificate extension, and via LLDP.</t> the Link Local Discovery Protocol (LLDP).</t>
      <t>Each of the above mechanism mechanisms conveys the MUD URL in-band, in band and requires modifications to the device firmware.
Most small IoT Internet of Things (IoT) devices do not have LLDP, LLDP and often have very restricted DHCP clients.
Adding the LLDP or DHCP options requires at least some minimal configuration change, change and possibly entire entirely new subsystems.
Meanwhile, use of the PKIX certification extension only makes sense as part of a larger IDevID deployment based on an Initial Device Identifier (IDevID) <xref target="ieee802-1AR"/> deployment such target="IEEE802-1AR"/>, for instance, as described in <xref target="RFC8995"/>.</t>
      <t>In the above cases cases, these mechanisms can only be implemented by persons with access to modify and update the firmware of the device.</t>
      <t>In the meantime meantime, there is a chicken or egg problem (<xref target="chickenegg"/>): <xref target="chickenegg"/>. That is, manufacturers are not motivated to (and thus likely do not) include MUD URLs in their products, as they believe that there are no gateways using those URLs.
At the same time, gateways have little incentive to (and thus likely do not) include code that processes MUD URLs, as it is believed that no products have and or disseminate them.</t> URLs.</t>
<t>The protocol described in this document allows any person with physical access to the device to affix a reference to a MUD URL that can later be scanned by an end user.</t>
      <t>The QR-based protocol is presented as a convenient alternative when the mechanisms from RFC 8520 <xref target="RFC8520"/>  are not available to use, use on the device or the gateway.</t>
      <t>Affixing a sticker can be done by</t> by:</t>
      <ul spacing="normal">
        <li>the marketing department of the Manufacturer,</li> manufacturer,</li>
        <li>an outsourced assembler plant,</li>
        <li>value added
        <li>value-added resellers (perhaps in response to a local RFP),</li> request for proposal (RFP)),</li>
        <li>a company importing the product (possibly to comply with a local regulation),</li>
        <li>a network administrator (perhaps before sending devices home with employees, employees or to remote sites),</li> sites), and</li>
        <li>a retailer as a value added value-added service.</li>
      </ul>
      <t>QRcodes
      <t>QR codes are informally described in <xref target="qrcode"/> and formally defined in <xref target="isoiec18004"/>.
The protocol described in this document uses a QRcode QR code to encode the MUD URL.  Specifically, the protocol leverages the data format from the Reverse Logistics Association's Standardized Quick Response for Logistics <xref target="SQRL"/>.</t>
      <t>SQRL codes are being put on devices via a sticker or via laser etching into the case in order to deal with many situations, situations but specifically for end-of-life processing for the device.
An important idea behind the effort is that clearly identifying a product permits appropriate disposal, refurbishment refurbishment, or recycling of the components of the product.</t>
      <t>There are also use cases for SQRL described in which the codes are used as part of regular maintenance for a product.</t>
      <t>SQRL is an application of the 12N Data Identifier system specified by the ANSI MH10.8.2 Committee <xref target="mh10"/> in a format appropriate for QRcodes QR codes, as well as other things like NFCs Normalization Form C (NFC) transmissions.</t>
      <t>QRcode
      <t>QR code generators are available as web services <xref target="qrcodewebservice"/>,
      or as programs programs, such as <xref target="qrencode"/>.</t>
      <t><xref target="genericfirmware"/> summarizes the considerations contained in <xref target="I-D.ietf-opsawg-mud-acceptable-urls"/> section 6.1 ("Updating MUD URLs "Updating files vs Updating MUD files"). URLs" (<xref target="I-D.ietf-opsawg-mud-acceptable-urls" section="7.1" sectionFormat="of"/>).
Due to the immutable nature of the QRcode, QR code, MUD URLs in this document will need to
be non-firmware specific.</t>
    </section>
    <section anchor="Terminology">
      <name>Terminology</name>
      <t>Although this document is not an IETF Standards Track publication, it
adopts the conventions for normative language to provide clarity of
instructions to the implementer.
    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>
      <t>Readers should be familiar with the terminology in <xref target="RFC8520"/>, including: MUD file, MUD URL, Manufacturer and manufacturer, MUD manager manager, and controller.</t>
    </section>
    <section anchor="protocol">
      <name>Protocol</name>
      <t>This QRcode
      <t>The QR code protocol builds upon the work by <xref target="SQRL"/>.
That protocol is very briefly described in <xref target="sqrlsummary"/>.
Then
Then, the list of needed Data Records to be filled in is explained.</t>
      <section anchor="sqrlsummary">
        <name>The SQRL Protocol</name>
        <t><xref target="SQRL"/> documents an octet protocol that can be efficiently encoded into QRcodes QR codes using a sequence of ASCII US-ASCII bytes, plus six control codes (see section Section 3.1 of <xref target="SQRL"/>):</t>
        <ul spacing="normal">
          <li>&lt;RS&gt; Record Separator (ASCII (US-ASCII 30)</li>
          <li>&lt;EoT&gt; End of Transmission (ASCII (US-ASCII 4)</li>
          <li>&lt;FS&gt; Field Separator (ASCII (US-ASCII 28)</li>
          <li>&lt;GS&gt; Group Separator (ASCII (US-ASCII 29)</li>
          <li>&lt;US&gt; Unit Separator (ASCII 31),</li> (US-ASCII 31)</li>
          <li>Concatenation Operator (ASCII (US-ASCII 43: "+").</li> "+")</li>
        </ul>
        <t>Section 7.2 of <xref target="SQRL"/> gives the details, which can be summarized as:</t>
        <ol spacing="normal" type="1"><li>The type="1">
	  <li><t>The QR code header starts with:</li>
        </ol> with:</t>
        <artwork><![CDATA[
"[)>" <RS> "06" <GS> "12N"
]]></artwork>
        <ol spacing="normal" type="1"><li>Include
</li>
	  <li>Include one or more Data Records. This consists of a four letter four-letter Field Identifiers Identifier, followed by ASCII US-ASCII characters terminated with a &lt;Unit Separator&gt;.</li>
          <li>End with:</li>
        </ol>
          <li><t>End with:</t>
        <artwork><![CDATA[
<RS><EoT>
]]></artwork>
        <t>There
	  </li>
	</ol>
        <t>Additionally, there are additionally optional flags that may be present in every Data Record Record, as described in section Section 7.4 of <xref target="SQRL"/>.
These flags have no bearing on MUD processing.
A parser which that is only collecting MUD URLs will not need to parse those flags.
A general purpose general-purpose SQRL parser will need more complexity.</t>
        <t>Field Separator characters are used in SQRL to signify the beginning of a new unit of data.
A MUD specific MUD-specific parser that encounters a Field Separator and has not yet collected the right MUD information MUST <bcp14>MUST</bcp14> ignore the characters collected so far and then restart.</t>
        <t>Environment records, as described in Section 7.4 of <xref target="SQRL"/> section 7.4, target="SQRL"/>, look and act exactly as fields, with a special Field Identifier.
They serve no purpose when looking for MUD information, information and MAY <bcp14>MAY</bcp14> be ignored.</t>
      </section>
      <section anchor="manufacturer-usage-descriptions-in-sqrl">
        <name>Manufacturer Usage Descriptions in SQRL</name>
        <section anchor="b000-company-name">
          <name>B000 Company Name</name>
          <t>The B000 Data Record is mandatory in <xref target="SQRL"/>.
It MUST <bcp14>MUST</bcp14> be in ASCII US-ASCII representation.
It should be a representation of the company or brand name.
It SHOULD <bcp14>SHOULD</bcp14> match the ietf-mud/mud/mfg-name in the MUD file, however file; however, the MUD file can contain arbitrary UTF8 UTF-8 for this name, while the SQRL files are expected to be 7-bit US-ASCII.</t>
        </section>
        <section anchor="b001-product-name">
          <name>B001 Product Name</name>
          <t>The B001 Data Record is optional in <xref target="SQRL"/>.
It is the Product Name in ASCII. US-ASCII.
Its presence is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>.
Some third parties that create QRcode QR code stickers might not know the product name with 100% certainty, certainty and MAY <bcp14>MAY</bcp14> prefer to omit this rather than create further confusion.</t>
        </section>
        <section anchor="b002-model-number">
          <name>B002 Model Number</name>
          <t>The B002 Data Record is optional in <xref target="SQRL"/>, target="SQRL"/> but is MANDATORY in this profile.
It is the Model Name in ASCII. US-ASCII.
It SHOULD <bcp14>SHOULD</bcp14> match the optional ietf-mud/mud/model-name in the MUD file if that entry is present in the MUD file.   MUD files can contain arbitrary UTF8 UTF-8 for the model-name, while the SQRL files are expected to be 7-bit US-ASCII.</t>
          <t>If a third party that is creating QRcodes can not QR codes cannot locate an official model number when creating their MUD file and QRcode, QR code, then the third party SHOULD <bcp14>SHOULD</bcp14> make one up.</t>
        </section>
        <section anchor="mudurl">
          <name>MUD URL Data Record</name>
          <t>A new Field Identifier has been assigned by the Reverse Logistics Association (RLA), Association, which is "M180" "M180".
This record MUST <bcp14>MUST</bcp14> be filled with the MUD URL.</t>
          <t>Short URLs are easier to encode into QRcode a QR code because they require fewer pixels of
QRcode.
QR code.
More content in the QRcode QR code requires a bigger image.</t>
          <t>Use of URL shortening services (see <xref target="URLshorten"/>) can be useful useful, provided that the service is stable throughout the lifetime of the device and QRcode, QR code and that the privacy stance of the service is well understood.
The Security Considerations section of <xref target="RFC3986"/> applies, particularly section 7.1.</t> Section <xref target="RFC3986" section="7.1" sectionFormat="bare"/>.</t>
          <t>Section 8.1 of <xref target="SQRL"/> also has some good advice on longevity concerns with URLs.</t>
          <t>The URL provided MUST NOT <bcp14>MUST NOT</bcp14> have a query (?) portion present.
If one is present, the query portion MUST <bcp14>MUST</bcp14> be removed before processing.</t>
        </section>
        <section anchor="macaddress">
          <name>Device MAC Address</name>
          <t>If a MAC Media Access Control (MAC) address is used as a unique device identifier (which is RECOMMENDED <bcp14>RECOMMENDED</bcp14> if possible), then it MUST <bcp14>MUST</bcp14> be included in this Data Record.</t>
          <t><xref target="SQRL"/> section
          <t>Section 9.10 of <xref target="SQRL"/> defines the Data Record: Record "M06C" as the MAC address.
No format for the MAC address is provided in that document.</t>
          <t>This document RECOMMENDS
<t>In this document, it is <bcp14>RECOMMENDED</bcp14> that 12 (or 16) hex octets are used with no spaces or punctuation.
(16 octets are used in the IEEE OUI-64 64-bit Extended Unique Identifier (EUI-64) format used in 802.15.4, <xref target="IEEE.802.15.4" format="default"/> and some next generation Ethernet proposals)
This document RECOMMENDS use of upper-case proposals).
In this document, it is <bcp14>RECOMMENDED</bcp14> that uppercase hexadecimal letters.</t> letters be used.</t>
          <t>Parsers that find punctuation (such as colons (":"), dashes ("-"), or white space) MUST  US-ASCII Space (32), US-ASCII TAB (0), US-ASCII linefeed (10), or US-ASCII
  carriage return (13)) <bcp14>MUST</bcp14>
skip over it.
Parses MUST the punctuation.
Parsers <bcp14>MUST</bcp14> tolerate hexadecimal in both upper, lower uppercase, lowercase, and even mixed case. Systems SHOULD <bcp14>SHOULD</bcp14> canonicalize it to upper case.</t> uppercase.</t>
        </section>
      </section>
    </section>
    <section anchor="applicability">
      <name>Applicability</name>
      <t>The use of stickers to convey MUD URLs would appear to have little value when the stickers are applied by the end user end-user organization and consumed by the same.
This is particularly the case when the QR code does not include the device MAC address.
In such a situation situation, the installer handling the device would scan the QR code to get the appropriate MUD file reference, reference and have to input the associated MAC address as well.</t>
<t>In such a case, one might wonder why the installer couldn't just enter the appropriate MAC address and select the appropriate ACLs Access Control Lists (ACLs) for the device.
No Then a MUD file or QR code to convey it the MAC
   address would not be useful at all.</t>
      <t>The needed. However, the use of a MUD file (or
   QR code other or other way to convey it) has the advantage that MAC address) is advantageous
   because it offers several layers of indirection:</t> indirection:
</t>
      <ol spacing="normal" type="1"><li>The list of type="1">
	<li>The ACLs for a given device may be added or removed.</li>
        <li>The ACLs may refer to DNS names, which may map to IPv4 or IPv6 addresses.</li>
        <li>The entire file may be replaced, replaced and may also include supply chain information, such as Software Bill of Materials (SBOM).</li>
      </ol>
      <t>In addition, the mechanism to install a new device (MAC address) to MUD file mapping does not need  to permit any other network security settings to be alterable by the person doing the installation.</t>
    </section>
    <section anchor="genericfirmware">
      <name>Generic URL or Version Specific Version-Specific URL</name>
      <t>MUD URLs which that are communicated in-band in band by the device, device and which that are programmed into the device's firmware may provide a firmware specific firmware-specific version of the MUD URL.
This has the The advantage of this is that the resulting Access Control Lists (ACLs) ACLs enforced in the network are specific to the needs of that version of the firmware.</t>
      <t>A MUD URL which that is affixed to the device with a sticker, sticker or etched into the case can not cannot be changed.</t>
      <t>Given the considerations of <xref target="I-D.ietf-opsawg-mud-acceptable-urls"/> section 6.1 ("Updating "Updating MUD URLs vs Updating MUD files"), files" (<xref target="I-D.ietf-opsawg-mud-acceptable-urls" section="6.1" sectionFormat="of"/>), it is prudent to use a MUD URL which that points to a MUD file which that will only have new features added over time, time and never have features removed.
To recap, if a feature is removed from the firmware, firmware and the MUD file still permits it it, then there is a potential hole that could perhaps be exploited.
The opposite situation, where a MUD file wrongly forbids something something, leads to false positives in the  security system, and the evidence is that this results in the entire system being ignored.
Preventing attacks on core infrastructure may be more important than getting the ACL perfect.</t>
      <t>When the firmware eventually receives built-in MUD URL support, then a more specific more-specific URL may be used.</t>
      <t>Note that in many cases cases, it will be third parties who are generating these QRcodes, QR codes, so the MUD file may be hosted by the third party.</t>
    </section>
    <section anchor="crowd-supply-of-mud-files">
      <name>Crowd Supply of MUD Files</name>
      <t>At the time of writing, the IETF MUD is a new IETF Proposed Standard.
Hence, IoT device manufacturers have not yet provided MUD profiles for their devices.
A research group at the University of New South Wales (UNSW Sydney) has developed an open-source tool, called MUDgee (<xref target="MUDgee"/>), <xref target="MUDgee"/>, which automatically generates a MUD file (profile) for an IoT device from its traffic trace in order to make this process faster, easier, and more accurate.
Note that the generated profile completeness solely depends on the completeness of the input traffic traces.
MUDgee assumes that all the activity seen is intended and benign.</t>
      <t>UNSW researchers have applied MUDgee to about 30 consumer IoT devices from their lab testbed, testbed and publicly released their MUD files (<xref target="MUDfiles"/>). <xref target="MUDfiles"/>.
MUDgee can assist IoT manufacturers in developing and verifying MUD profiles, while also  helping adopters of these devices to ensure they are compatible with their organisational organizational policies.</t>
      <t>Similar processes have been done in a number of other public and private labs.
One of the strong motivations for this specification is to allow for this work to leave the lab, lab and to be applied in the field.</t>
    </section>
    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
      <t>The presence of the MUD URL in the QR code reveals the manufacturer of the device, the type or model of the device, and possibly the firmware version of the device.</t>
      <t>The MAC address of the device will also need to be present, and this is potentially Personally Identifiable Information (PII).
Such QRcodes QR codes should not be placed on the outside of the packaging, packaging and only on the device itself, ideally on a non-prominent part of the device. device (e.g., the bottom).</t>
      <t>The QR code sticker should not be placed on any part of the device that might become visible to machine vision systems in the same area.
This includes security systems, robotic vacuum cleaners, or anyone taking a picture with a camera.
Such systems may store the picture(s) in such a way that a future viewer of the image will be able to decode the QR code, possibly through an assembly of multiple pictures.
Of course, the QR code is not, however, a certain indicator that the device is present, only that the QR code sticker that came with the device is present.</t>
      <t>The use of URL shorting services discussed in <xref target="mudurl"/> may result in trading convenience and efficiency with privacy, since the service provider might leverage per-device or per-customer per-customer, short URLs to track and correlate requests.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <section anchor="qr-codes-are-not-assurances">
        <name>QR codes are not assurances</name> Codes Are Not Assurances</name>
        <t>The mere presence of a QRcode QR code on a device does not in itself create any security issues on its own.
Neither an attached paper sticker or nor a laser etched laser-etched code in a plastic case will affect the device operation.</t>
        <t>The QRcode QR code is not active, active; in general, it is not in general able to communicate on using nearby networks.
It is conceivable that something more active is concealed in the sticker: sticker, e.g., an NFC or RFID tag for instance. a Radio Frequency Identification (RFID) tag.
But, any sticker could contain such a thing: thing, e.g., on some university campuses campuses, stickers are often used as part of political campaigns, campaigns and can be found attached all over the place.</t>
        <t>Security issues that this protocol create creates are related to assumptions that the presence of the QRcode QR code might imply.
The presence of the QRcode QR code may imply to some owners or network operators that the behaviour behavior of the device has been vetted by some authority.
It is here that some caution is required.</t>
        <t>A possibly bigger risk from application of MUD file stickers to devices is that they may begin to convey a sense of safety to users of the device.
The presence of the sticker, possibly with the logo of the physical establishment in which the device is located located, could convey to occupants of the establishment that this device is an official device.
For device,
for instance, a university which that only deploys sensors on the university campus that have been vetted for compliance against a MUD definition.</t>
        <t>The risk is then of social engineering: engineering, e.g., any device with a reasonable looking QRcode reasonable-looking QR code may be seen as a trusted device (even though such trust is not justified based on that evidence.) evidence).
An attacker that wishes to infiltrate their own devices need only suitably camouflage the device with an appropriate sticker in order to convey legitimacy.</t>
      </section>
      <section anchor="mud-files-can-have-signatures">
        <name>MUD files can have signatures</name> Files Can Have Signatures</name>

        <t>The network operator who takes the MUD file designated by the QRcode QR code needs to be careful that they are validating the signature on the MUD file.
Not only
   The network operator needs to verify that the file is intact, but intact and
   that the signer of the file is authorized to sign MUD files
   for that vendor, or that the network operator has some trust if the a MUD file is a crowd sourced definition.
At the time of writing, crowd-sourced definition,
   they need to establish if it can be trusted.
<xref target="RFC8520"/> does not define any infrastructure to authenticate or authorize MUD file signers.</t>
      </section>
      <section anchor="url-shortening-services-can-change-content">
        <name>URL Shortening services can change content</name> Services Can Change Content</name>
        <t>If a URL shorterning shortening service is used, it is possible that the MUD Controller is controller will be redirected to another MUD file with different content.
The use of MUD signatures can detect attacks on the integrity of the file.
To do this, the MUD controller needs to be able to verify the signature on the file.</t>
        <t>If a Trust On First Use Trust-On-First-Use (TOFU) policy is used for signature trust anchors, then the URL shortening service can still attack, attack if it substitutes content and signature on the first use.
MUD controllers and the people operating them need to be cautious when using TOFU.</t>
      </section>
      <section anchor="mud-qr-code-stickers-could-be-confused">
        <name>MUD QR code stickers could be confused</name> Code Stickers Could Be Confused</name>
        <t>Another issue with the stickers is that the wrong sticker could be applied to a device by a reseller or other another trusted party, either in error, error or via some physical or socially engineered attack against that party.
The network operator now onboards a device, device and applies what they think is a legitimate network policy for the device in their hands, only it is in fact a policy for another kind of device.</t>
        <t>Careful examination of stickers is in order!</t>
      </section>
      <section anchor="qr-code-can-include-mac-address">
        <name>QR code can include Code Can Include a MAC address</name> Address</name>
        <t>Inclusion of the device specific device-specific MAC address (described in <xref target="macaddress"/>) in the QRcode QR code makes use of the MUD code much easier easier, as it identifies the device specifically.
If the MAC address is not included, then a network operator, having the device in their hands, has to associate the policy with the device through some other interface.</t>
        <t>Despite the significant advantage of having the MAC address included, it is unlikely that third party third-party stickers will include that. it.
Including the MAC address requires that a unique sticker with a QRcode QR code be created for each device.
This is possible if the sticker is applied by a manufacturer: manufacturer; it is already common to have a serial number and MAC address on the outside of the device.
In that case, if the QRcode QR code is part of that sticker, then the customization problem is not that complex.</t>
        <t>For cases where a third party has produced the QRcode, QR code, it is likely that every device of a particular model will have the same QRcode QR code applied, omitting the MAC address.
This increases the possibility that the wrong policy will be applied to a device.</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document makes has no request for IANA actions.</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>This work was supported by the Canadian Internet Registration Authority (cira.ca).</t>
    </section>
  </middle>
  <back>

    <displayreference target="I-D.ietf-opsawg-mud-acceptable-urls" to="MUD-URLS"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <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="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>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8520.xml"/>

        <reference anchor="SQRL" target="https://rla.org/resource/12n-documentation">
          <front>
            <title>SQRL Codes: Standardized Quick Response for Logistics, Using the 12N Data Identifier</title>
            <author>
              <organization>Reverse Logistics Association</organization>
            </author>
            <date year="2017" month="February"/>
          </front>
        </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>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>

      <references>
        <name>Informative References</name>

        <reference anchor="qrcode" target="https://en.wikipedia.org/wiki/QR_code"> target="https://en.wikipedia.org/w/index.php?title=QR_code&amp;oldid=1082559657">
          <front>
            <title>QR Code</title> code</title>
            <author>
              <organization>Wikipedia</organization>
            </author>
            <date year="2019" month="December"/> year="2022" month="April"/>
          </front>
        </reference>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8995.xml"/>

	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-opsawg-mud-acceptable-urls.xml"/>

        <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259"> anchor="IEEE802-1AR" target="https://standards.ieee.org/ieee/802.1AR/6995/">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <author fullname="T. Bray" initials="T." role="editor" surname="Bray">
              <organization/>
            </author>
            <date month="December" year="2017"/>
            <abstract>
              <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules
            <title>IEEE Standard for the portable representation of structured data.</t>
              <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, Local and offers experience-based interoperability guidance.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="90"/>
          <seriesInfo name="RFC" value="8259"/>
          <seriesInfo name="DOI" value="10.17487/RFC8259"/>
        </reference>
        <reference anchor="RFC8995" target="https://www.rfc-editor.org/info/rfc8995">
          <front>
            <title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title>
            <author fullname="M. Pritikin" initials="M." surname="Pritikin">
              <organization/>
            </author>
            <author fullname="M. Richardson" initials="M." surname="Richardson">
              <organization/>
            </author>
            <author fullname="T. Eckert" initials="T." surname="Eckert">
              <organization/>
            </author>
            <author fullname="M. Behringer" initials="M." surname="Behringer">
              <organization/>
            </author>
            <author fullname="K. Watsen" initials="K." surname="Watsen">
              <organization/>
            </author>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document specifies automated bootstrapping of an Autonomic Control Plane.  To do this, a Secure Key Infrastructure is bootstrapped.  This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline.  We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device.  The established secure connection can be used to deploy a locally issued certificate to the device as well.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8995"/>
          <seriesInfo name="DOI" value="10.17487/RFC8995"/>
        </reference>
        <reference anchor="I-D.ietf-opsawg-mud-acceptable-urls" target="https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-acceptable-urls-04.txt">
          <front>
            <title>Authorized update to MUD URLs</title>
            <author fullname="Michael Richardson">
              <organization>Sandelman Software Works</organization>
            </author>
            <author fullname="Wei Pan">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Eliot Lear">
              <organization>Cisco Systems</organization>
            </author>
            <date day="6" month="October" year="2021"/>
            <abstract>
              <t>   This document provides a way for an RFC8520 Manufacturer Usage
   Description (MUD) definitions to declare what are acceptable
   replacement MUD URLs for a device.

   RFCEDITOR-please-remove: this document is being worked on at:
   https://github.com/mcr/iot-mud-acceptable-urls

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-mud-acceptable-urls-04"/>
        </reference>
        <reference anchor="ieee802-1AR" target="http://standards.ieee.org/findstds/standard/802.1AR-2009.html">
          <front>
            <title>IEEE 802.1AR Metropolitan
              Area Networks - Secure Device Identifier</title> Identity</title>
            <author>
              <organization>IEEE Standard</organization>
              <organization>IEEE</organization>
            </author>
            <date year="2009"/> month="August" year="2018"/>
          </front>
	   <seriesInfo name="IEEE Std" value="802.1AR-2018"/>
        </reference>

        <reference anchor="chickenegg" target="https://en.wikipedia.org/wiki/Chicken_or_the_egg"> target="https://en.wikipedia.org/w/index.php?title=Chicken_or_the_egg&amp;oldid=1081728488">
          <front>
            <title>Chicken or the egg</title>
            <author>
              <organization>Wikipedia</organization>
            </author>
            <date year="2019" month="December"/>
          </front>
        </reference>
        <reference anchor="qrcodewebservice" target="https://duckduckgo.com/?q=QR+code+web+generator">
          <front>
            <title>QR Code Generators</title>
            <author>
              <organization>Internet</organization>
            </author>
            <date year="2019" month="December"/> year="2022" month="April"/>
          </front>
        </reference>

	  <reference anchor="qrencode" target="https://fukuchi.org/works/qrencode/index.html.en"> target="https://github.com/fukuchi/libqrencode">
          <front>
            <title>QR encode</title>
            <author initials="K." surname="Fukuchi">
            <title>libqrencode</title>
            <author>
              <organization/>
            </author>
            <date year="2019" month="December"/> year="2020" month="September"/>
          </front>
         <refcontent>commit 715e29f</refcontent>
        </reference>

        <reference anchor="mh10" target="https://webstore.ansi.org/Standards/MHIA/ANSIMH102016">
          <front>
            <title>ANSI MH10.8.2 Committee</title>
            <title>Data Identifier and Application Identifier Standard</title>
            <author>
              <organization/>
              <organization>ANSI</organization>
            </author>
            <date year="2021" month="May"/> month="June" year="2016"/>
          </front>
	 <seriesInfo name="ANSI" value="MH10.8.2-2016"/>
        </reference>

        <reference anchor="MUDgee" target="https://github.com/ayyoob/mudgee">
          <front>
            <title>MUDgee</title>
            <author initials="A." surname="Hamza">
            <author>
              <organization/>
            </author>
            <date year="2019" month="July"/>
          </front>
	  <refcontent>commit f63a88d</refcontent>
        </reference>

        <reference anchor="MUDfiles" target="https://iotanalytics.unsw.edu.au/mud/">
          <front>
            <title>MUD Profiles</title>
            <author initials="" surname="UNSW Sydney">
              <organization/>
            <author>
              <organization>UNSW Sydney</organization>
            </author>
            <date year="2019" month="July"/>
          </front>
        </reference>

        <reference anchor="isoiec18004">
          <front>
            <title>Information technology - Automatic identification and data capture techniques - QR Code bar code symbology specification (ISO/IEC 18004)</title> specification</title>
            <author>
              <organization>ISO/IEC</organization>
            </author>
            <date year="2015" month="February"/>
          </front>
	  <seriesInfo name="ISO/IEC" value="18004:2015"/>
        </reference>

        <reference anchor="URLshorten" target="https://en.wikipedia.org/wiki/URL_shortening"> target="https://en.wikipedia.org/w/index.php?title=URL_shorteningg&amp;oldid=1084979184">
          <front>
            <title>URL shortening</title>
            <author>
              <organization>Wikipedia</organization>
            </author>
            <date year="2021" month="May"/> year="2022" month="April"/>
          </front>
        </reference>

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

	<reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3986"> anchor="IEEE.802.15.4" target="https://ieeexplore.ieee.org/document/7460875">
	  <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee">
              <organization/>
            </author>
            <author fullname="R. Fielding" initials="R." surname="Fielding">
              <organization/>
            </author>
            <author fullname="L. Masinter" initials="L." surname="Masinter">
              <organization/>
	    <title>IEEE Standard for Low-Rate Wireless Networks</title>
	    <author>
	      <organization>IEEE</organization>
	    </author>
	    <date month="January" year="2005"/>
            <abstract>
              <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.  [STANDARDS-TRACK]</t>
            </abstract> year="2016" month="April"/>
	  </front>
	  <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/> name="IEEE Std." value="802.15.4-2015"/>
	  <seriesInfo name="DOI" value="10.17487/RFC3986"/> value="10.1109/IEEESTD.2016.7460875"/>
	</reference>

      </references>

    </references>
        <section anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>This work was supported by the Canadian Internet Registration Authority (cira.ca).</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAO9AOGIAA7Vc/3LbyJH+n08x0dZdpFuSluxdr63LJdFK1lobS7Yl+Tap
1N3WEBiScwIBLgaQzFX5nuWe5Z7s+uvuGQCUvNlU6rYqMQUCMz398+sf4GQy
GTW+KdyheVuaorK5Lxfm/MOJ+XD5Jph5Xa3M+0uTVbkLIzub1e72kC5M6I5R
XmWlXdGTeW3nzaT22dLWeajKyarNJz/VeGiy/81oFBpb5j/aoirp5qZu3Wjk
1zV/DM3T/f2X+09Htnb20JyVjatL14xu7ro/JidYf5TZ5tD4cl6NRmt/aOi/
L0xmS9MGZ2xd243Z9XNji8JsXNgzVW2WNizN0tVuZExTZYf4gj6Gqm5qNw+H
vETu5rYtmkB3xO83K/kaf45s2yyr+nA0mtDmdPF8ai7TSeluYcE5Lrli+FVV
Lw7NFZ3dFSsi9KqaN3d0TvNDVd9gI7eyvjg0q6z+0rtm/scQb51mNu33/dS8
sU3V1mmv7232U+tCd5n3OT67PKJLs97CeuNUbvxj5mvbX/n11Ly2Mz/z5jui
2d4snS982uW1DUTP43fwhh8urn4wV5u8dJtuy+V0yQ/8sS3D3dTl7dS2o9Go
rOqVbfytO6RbL0+Pnx4cvNSPL75+uo+PV+8v3+BfEpWtF45kvbNsmnU4fPKk
LuyUtnxSu0DnyNyTg6flhLSvXbmyoWWrckceFEXewVLmGCpL7IfukUT8zy43
71uf3ZhLF9ZVSVozJx15Uy18aHwWxuZDgO43S2cOnl6YE9tYc5bTDn7uXS07
RGUw/B+zYefS3bqaVksrmaMQqsz3CMttA7pO3axubb0xT/cPvtkhtkCbe4wR
k/kME1w5vfM3fu1yL9zAX0/eX/6IZ4bnJ4M9ThcfI/mHuNCAvBOXudXM1SDv
5Y5K5+nXSVAvX359aL69vPrTGV04m5xMobSTah3s3YJN3maZWzd2VrhJWxcB
z3nn3Iv9p5ODo8tHzkXHCiqfMMWtfLC5L/PQ5CF994RWmNIKE/iK6bJZFcPz
nr169croPebKZS3Z2Im79Zn7VQLkx6Oe9DmC7ejPbEla40q3WPxdojmWx36s
6h9Jp36kx4dU6/dwVNC59P0/IDBRoDs3C67G8T9Db95mN/jfoppm1erJH376
t/eXX+LJL+nRLxd01Jo8Rv2oUpnv4tfhFziqnvtvUevKX1D4eXvTEuuFofCY
T+IDT0hB3EdWhKkrH5ApNz1GHbu9nT9Nzams/cv0rZYH+5+hDSwmFripLYNQ
GPUnPDl/fXb05Oji6uz89cE+rfV8SCC+Mfhq+mL6lFi6WvmmcW5AyrmFj3h6
gIsUaRfuczxa+GbZzliKdrOpqtkTssOF2/IHssTnGXKEQLD6eahc37fFJrGC
Vpj7woXPkOErOr0tNvB+057nBzVPHtBi3tUVr/Z5inqx5fNE+VB5lx282N//
6nDoD6JbrUrTuGxZVkW12JiJOWqbCtcz49UvZHIXyQ5bWAIU6wbugx/zHGYn
Jqr+zNaMhIAQZrJmWLusW2b37Ortk7NXx4aJ2vsFA5H7BmejY309IVe5z2IH
/KLHGlcOz0bXjX5B0Wrn73FI9OiP24/+emcDfZzsfz05eIbINZlMDGGNprZZ
MxpdL30wvuO6LUwMz4SvGkIGwVizritCYVUBpAWkyTCT4JcvPR4KI8TjnP12
MHfkHQm82VtnyorWbtyCvA7F8HNbtnPalaRUU8i2C/j6kNV+LSKgRfeMDbQQ
Ls7oCV9GnDFVUhNx9HndzgoflnRfU+kZ2B9HH0YSX61aInFjqjl9Q4+sSDls
6cMKjxDgrO5GILCu1uQZZwSR6F5oFH0LR+xAjiXtCfQsrVHR8rVJgc/AuRmP
tQmqGuYkLeZCQ+T+9T/B4pv/6D4d4jCTVydn128vJ+vC2eAmtVtVBCEMH06W
IzyL2+lYtjGPuAsCnU86mC4CXfk8L+jzFzh8XVGIAEvBM/fr2H5/r4z+9EkE
63DwvxxdfCfWtaKtWPzu45oOCCkTdcDj4AvgQ8ADogOmdj+1nm7DA8zaxpEw
6tplTbGZElX0bJKkzXMvqkceIu7dLGvnzJ3dBMZ6EKuu3VQjWlVFm2FliNKQ
vJl9DnpA4QArryuSBz+radHY+KmbjvkSzJHVAuQGyiNi+gQHB837/urthfKF
oNSnT4fm5PXxu7G5I1F4OB7z5+nX+y9N5mr1RwQFPpKJBjrMmNXo1lvz5s3J
O1KHV5aMQvezM5J5Txezqrx1m9CnlAiYzGgJWSfxk8SQfBZzt8eYua9XSFKm
o/MqkGxWSKjOqutkmHlFBtmIZYIqWZtSG4IyfJHQ8AbMaCghhMHivCYrPPEy
TEdHeR5RNp4G+uEbqrVQk4gk4UK5oR4rOiY5CSIFh5z7RVuLv8XRF04oWFch
+BkJH46d7Kh0dya0s7AJjVvRxufOluRUCrodGaMy8d2fzv7c4z0WTdw3VUnL
rewNURMcEgay47VVZTUFvG5tzghpnp3Auums9/c9wMtGsC6qDatRIMCBBe7v
J4yhP30ieZ6VPVFmtASLL/TEGjjHZUpmpFArsngsR3vNNoaMIoBpUKZoPiRO
lq+4oHads3IvO8nGo4tAOyJWxKDGr1znh2yEvpAS4VN4cAL3K7N7f9+B4k+f
9iiH7bkHehD8JyVZVZTasNcmqnbZJS7bYAp/42ClrEl7pKRZ0eauqzp4JsjX
2A9OiHIzy4wBD0iRbkEj6YdSKruZBW3Ept5qHlcFtk8ondhvsDgdHXHc3cwq
Sx67YXPNoDy37leRy0iA6SAywXoSXjwCE+w5vijFudxKdMZDydaMPDw9TBqu
klpNxeWmeDkIZc0ggHH0IYaXURlEF9bLTSB9LnpKMXB+xs7n/iMJuHZzB1St
/i/6DaYVilcQTTU0L9BfpWgdXXZQLYptSun7y4nofyIZgZWsWDSVwx+7p9IL
0QitnPZSBHBR/ZLGc9WJPKZBKDFJm+wtAQlkl6CVdh+bquwfSz28ipZIO8Ih
oQvWIDG/oZPgTHSavCoJzm1Go3+RvW1949h1k8GSgTNr1Uz6gW+MB2CObSOV
CJyNREc0kbIWZD98x60tWoeI5OB0gysKGMUuCWhp16zedSxBMNeLCqK6PH23
JxsgLq0hUjJ3io3RX6ri0ELR1UkIW9Mn8QC6Uu0WbcHOLC4Y45rN4UgB2yh7
6SiaOQp3Dk4uFyaIq1/C8/LKbgU/5hwpNrhcGSAO0tbgGxfiJjUjPeIEy7vP
BE1HSSTvL7mUyDJVwCgBu6fh9/cCSsh/wjp6NyGq6y098A9P+mvtpQ0MSYQM
RiKl2nHyP1NjriKqp23HkfeydoFqD6EfibOMagT2itbi4i8WhH4bfn1Jio6J
UhZHCq5pdbybOQhq3TawgSgvAIWo6LQO/izILMl3N+Su6X4CMuIIEGrAnKrO
Hcszd6Q3LOoVFI/k2go8GJsZbRJ6DGEaSVMm1XxS+LmL7g8bDFEWOd5SddgC
bNMmRDhRkkvFYz4H8gNUZXdD4b6m5TU124jhRqUnVaVEmQ6/pivr2sNXkt8k
U7DFGG6srWcE48Vya7qQbQhz0BJqxrATMnrCIPGKriwuTMOILQK7Fo3FOA4z
fqBRkprIolEebRA/F+GBmGBN3ASYLy08LFazvW15ZYTZEqcqIv5Q8h6pQRoB
M1Ea4o1x72dqCqQ/qGGQHQFpRj3tcxAkJZMkHEGuCv9KhgKAupDwZy5Ojzmj
KMOKghUUIxmzSQUjYUXnpnnFWbT+kAy7K1B9+jQeVewwiCZK8Mj5dzgplntY
/+/veRufRRhDpwrtijw3mVFQaRBsy12tuJb+JH+UHMavKFhiScc5j3k+PTC7
Ox+AngYNkdtgBheljrE3HZ20LkZZT0kFL2ooxrUd4BJ2jbdwTt873Xnif+kY
L41miHrlJMG2aINTJGjXMAeta6T/7r/oXf5E8a8gENQullu70GcOp6U5e3V9
mtxRMNfIGCUhFl2kTKcZ2ZyweeLwLZQR7IXqpLI++Zly0SIpbBjg3HoAJDIA
SZspPaaYI+lk6NgUsWwt/vuG8B1FKSJk5/zD1fXOWP41F2/58+Wr9x/OLl+d
4PPV66M3b9KHkd5x9frthzcn3afuyeO35+evLk7kYbpqBpdGO+dHf9mRNGLn
7bvrs7cXR292HgFbNZ8POBxUE8ARdDMauIdvj9/97/8cfEUq9xvtdJBeyR8v
Dr6haMWYR9Mm4Hr5E/B2RLZJTpDNlTQhs2vfkEtiNBmW1V3J3SxSgNGlszlA
BV1tixwkze3KF54eZi8OBjc9HWETSMn5WEEsafFhUuNxl98Okn3QiW8oMNiF
/g3bqivgGtbGdxodtbyifiHFzFnrC5Jqu1a8xlCEXFcX3q4VRifwyEnkrPZu
/hAdhJ/IVtn0Nxr6ZdmCoiZsDQaEvBPO89JlrFEiNjpmIavQFu4jITb4BxyB
LIpWYI8cD0Pm1N8JLkjITQrBrruiJLdHe0LOMw5wPgPi5awUPMklBEeXK5kK
BW1KehmEE/VHV8dnZ8SdBmBrXVD+EQipK8M14uwG55Krekauip6L1O0dAo39
c9H86+XV7/X85gqwVjCfrP9sfy/e9qq6/r15xTk8PEDy8PHWr9Kdp7TgqXfF
I+s9fZHu+o7u+q6u2vUjd71Md32guz6UlCI9JO1AAOVxVaIaUkpUfLt2g7u+
enZodr6E5x1dKSO+odjXY4RZkGNSmCY1yLGGbhVPCh+wYeLawdRIMiOp3ZJN
DHW6upEUm+75b/pvtPPXvd/vmN+Bvzv7z+kTjrxDAXtHvh89nZozzRKRaBDV
K+DrvkZOpVjHMSsIKEGEbmtCmA1yLmF0F/zhcZHsSdQXJqDXTGaKL8XYOdfW
XIC5PODw74lZz6Ys6/5xcJDfQQuU+h4c6hfVpEJDMHFe2IVitpXlsoSmejAs
x5bbO+mDWmxI4vqqLy42ZCBgXj0WfmfkDhnFleyDOqhJ2BJgC+hWhIraKrxp
BreUDaO2xFWKeRpb5UktEfCGWE5wTEEBsF7jC/YGcY8UmVmSnHW5jxTdiKXb
JtGTSoKGdG5eDiVhvyhRnoFiztzCl6XCVMs1K5Sa8RdSC1CFQ8TQH6lh3sOj
tKVs88As4aSXVgL9hovYzBUnyLv2i2XDK/eK9oaDLRGHA3K0787RPU74eG5l
/QaOF4U+MhDUJstbX1clR8palHz8QPjJOHtaMKa0tbrhJWk78ssWBV48Osep
wjhqNLOBBLRtGqw6G621o8KiAuTaAtaOqcnWiSUGU+znkM4H12Dwy9XuEMWJ
e78w3+7v7wN0c8p+YVdOiiJ8uW8I6BwAapF8Nn1eTEdnjTCfkYXadu3UqphU
vqcL9nbr636WAyrorLMah8MsBz+riIgOrrkLY2H05/h/88UEt2rprYcJCHXA
pAdX2YEqvCYVn3lKDOhIH65PX2gGCIhpUWfjiis/zOrPcJmtgqKv6iNH5m8m
tIr5cDXhw08TYw8QjjkBHDD2YJuxyTlt89VLBOivkniMG2KdKuOKZw8WTkdX
FRdDPe2AtM67mKjWDrmTohxNuEm2bFQwuJuyuhtUbJi1rMQH+/v/xPVm5IWb
TgHXXIjjTgflbsJBsmRJw8Bt2ZOyXL6GMngbWC8ip56ac+6uXLRoYidOPf01
nJIkn748P7o4Obp+e/mXBH7X0qvt81L32ebkQxXrthroGh5/VNukCcaurYGJ
hH5g6d84NabLvv62NjrT7fkPqOQZXHSnDxuhFUEcwoGPibgOFEERUI5rHKNE
hoLECmmBlSwkcVDpaal5J2ZANWLK2ESM298+8ftGYEa7Vm2IVdy+5O+/IN5T
kou0kOPMthPlcDFztI8NCFFddeEX61lm9/LN0d64C8I75wcv9nckEZAwkHyb
wu+UoMSCG0E4tKUlVrMkbPBiDVqe66FmWiizLUdvt4ntIjN3dyjB+o+uAJbS
0gSaWBytUYNJWqTrdJ0mM/MLZDZ+RY6eqPkg/aFhq70rYzD6vr/vOvQEuiOm
JMLmbRFTYC36c+9BngaHghQHmmWN5LxqG81e5o7bL4P2zEALJOjqguva39ps
w33kLD3V24aLOW2JNLGpqlxybJ6OQlJ+PCyWxHDMgOwPlCg+e/niOQqwKExx
JgIPmKGmVWx6wfugh79fDBMRKaZBq7iDtyAaCFBKpR5huVzQCRsANqK/jl0s
adgwreB/YmSsBGjXxFDCREa++4c9wyVyWlF9xRR2CnPo3IeUcOWJeHfUSWmd
57EE3geYbEs6R3Z+dGyO8pyb1mRKNrPyxyd1C/heL2HjWA60gHO0cZSm78xt
N1lML+jAA2p13+2p2fs+OOCkoqtr9yx82ktQo3xeTg/2e83wQQaCWZz958c7
2lrrn2A6uqhSVVs96NYBk1yYkl4j/sGIRTrdlTl4anZpuYPne5RcfZTMuYeR
Wf4E38LawszoznVbZlqIno52D54/eEQtmif43n44mzz/KtIdv+axwK8BMmE9
rIml+9jEoiW49AohtZQknuvJYe/zZ9DecbumfHTCZXQ6CiWKGbenJXeDAr9j
pK6IARON/cOQC9EqJwFrmN/uzuEOyTu3YQkHszPBXxWnNuiygCF7rAWjcOPX
pgIi88Rr3iWIfjRVITMSfYKIA7OK2Mr0AmjfaQWHfHpJkOUjcQmnmJoraZTH
qEL+rMJkREH5MVQQLTesIXej6HMkNWuZdxGLVeYkSMT9KUwl9FIxhrBa52qq
Qf9VWkapI5iW4VSUHVGKSbEBiZElW/qfuzEuZNQktXRnYAQsE0ph6MZSJyRt
GXP/vHKSO8Vmb88jDwzlrNSCddcyEXRdkl9GfYwOWOZFbOHpEsIEtFQHuxI7
Fk68e79InxBBataONb+TTrUv1xpDrMZl+MuevWplX1r9Si7OPWY/Kbj1rkKk
IE5stujPQGv528b8VxsYmWkyMKCwt5nYmUO6+OC+o+M325M47GvSCbkdkZih
uuMbZVgXXy13vqcDrbPdMru9daSXIf9/ZzeDdfc4PDGV+a0lBLnQjj6n4HMu
sHK/jyzbbvAn7UO27GtxsF3RKNYe0wktl59iby4WSqQdyv0pDjtTlIrwPD+H
m1IecHJxxXlDqlrh25Vd47uzd7dfYRX693lkvCNtfCaL6QQMs0I3pnSxICei
k0C4yNE5qncg20btZAkMPciQo6NKLy98i0oInfQckwGEaMldXX379nxPtCtW
jMbDnr6oKauUljmUL7s91dnDXUmGdNQ1N6OjKXL1hYs33ArkmQcRa+xuhwhu
Arlh7l0Jkud5A8Zc6hN0VCKvol0qbRppyLl9J80mme+qzb/TAzDt2Bjm6/df
bLekRqPOz7HMrNSK4pBZHgeyIiHCBRFK94T2wlaxXNzd+dvQjfFAiLHVYs2D
NhFK6KFXGkhgm13hZ/S+GcyxHcnwyLHWnt9woXIXqroXJ+RSCE4TBn0SlHZI
TtuutMcWXd3AmRa7wNqEjXhORVKyvv/UepAECI6UaHH3+cV+PeZhM6ejYkBJ
37FdPtIwZOz6/9omHOtM0LpuAQR1jqU3dyPn5onD0E3ksD3IV1yH5DqnVEjJ
kuaOu4whOheu1vCQExeAuHrDN6cbk/O5xiBHZtdj4E4bbzA+3dINNUQxxSyk
F5ZIDERUbNBz9UIYHKfI1hXSL2S/y6pQTeOwYroBFG7HVIR2NFGp1gTFvIyY
tOqL7qQw3eNJTVmETCTMfC6JBnetMTooXZ85eShneC1uB6i69nwF456xgiIA
dEmf1B6YF4FfENNH1btqL14GMVLx8F3tuEOKtk7T2OwGVWlMrfK4S22lDdrW
yTFzObmbkeBiz0Lcl7T2j9+AS3PHIwM/RKCSzJ23a7lAT6J0fEb025qJL5Na
wb3TBppQWNk09H2ZUgPUTNtcVE0MhKUMhMg8hNcW9Wy7Lna3rNjyI6oW4kPM
tSmGhWqoNLrhsgpNh9V61Q32wsd1dZebKwlOiDn09ClMaRRH+mLGfEeypF3H
mg5cn0qtN2i04SvvGN7TbrHjPR29FjTVzbduDTJqG0Jq6L1c9CTWxRKc8Wl0
HUV75J22JntdcCNMPeuH0rPzk1HyC6LrirL/pfnBYqHd3ksPAkxoQVdUa6SS
JSagy4lMnZFeV8XYYBpHqFk4h5lM+fTpUyrH2Pi+A+uHCocrHh1U0oPsCWop
+7xg44dNNzX8cMYj5cO5IS4+xUIhR4s56Th8stRwFG9A38iLYm6XEV/TizeR
rDzyVLsr5DOwXiCXwT1gOn8e4sjf4BaNJIqD+7Ri7lfYQ9CYsgI1a8AQjn7k
xW8FMLgyTt6XOTMccLMku0Y9CIKJIk1qETMS3QDeeoZizrP9mIPUg8Hp6EpJ
Uwo7MySHZhYBmcxcsA3zRH++VQwMKl7+TAJOx0KEQ72O0Cf2GmqvL6MKsT/C
KDnBFZms6utwrIkyJKT0sZD7MfehmFeMOZ6E63KhrbUGpyBnTYoGjBXLez4m
ZyG+E7KuCvTDkR5f+ZXHfFQ3Oss85fojD2fyxJKWSdM7E8Im4VjNk8VgJa33
tuwqYA2CQhw9TqMqrKPDt3V8SO9vdLcwiMELKo6zqyXvMI6vc8w6sfvoiF2R
6xCEFOSGlbU4yqs9hiEY6yqSRkuStw6ImrFzvwU1qAmKk2s2a+0so6C8dcNg
IH4QL7bQVxoCv96q8QyrkOz1WT1iB7Xr+kZEoAl2jPW08TuG2fwx1pkZhfff
z9p9d3ZG6nyFNCOWz7XPpchNEpdo+Bi9BeKNQ3wUYu2CPX+apxlOBZP/csV8
zNOHhXxrebCKVG/lS37DQ4f2egwxu2660Hc8ZlVDbnQvzTqbft/ns8TySPaD
hcX/SMo9cxnKUbeey33iTTGnKZdoCX13IWoJj6/jPflYzpDkLWxjGbLnuiKi
kQPYrG1XPFpJThb92HID62rsjY5XekEjiqgz2qK2Ko64PUI1v+0oHJcndsMe
N/OlmsCJNXtWM295wVvPFfnomlFZT9ghznDnLs3eKlfHfa3l8ngcsOaQuUJi
Qn4/EgHLnwNK1kGtIkpHZtxS+3KMs0nXjfP3jJvkKQRFVelVjFmT0g3bQtcp
n1Xn7R6uMaxOpGbCoJWQ+5C1IcTeuLZoPmklALCThV/LzzKkEXrtC8T5okzn
v7UlQGDL80R/rx+g2KVW1YtTzICWk258nmuaLcl6JYodezLIqXg2UApsNUUp
+F50UCiKBXZ/n+kscDs9/oJEN8pP0bhG30L948rVQyeZRrTZXJXCXlVOzTr2
RXlmORLgaXHHSAHYpbqjEH7hPAcQREvAcqSKa7vm8Z40L92flkZZVBpPMBK6
DmuSWiG7wvk81rci99Z64uQmenooQMPF9E+PEOdNojn030Yj4kuCG4SLNbEO
sQPL7RKS8yxmUl3SozCLBzLjnbboYpWe9RBsuDg9xpkvT89OyBvIeARXQUqE
g29bduub7r0JdnKxy6pWz7seglauq7cdvCXTWPOo/aCGKy+JbY9KAxUwROWn
LEGuIM5cW2rzqsVkSBQbsFsVJxLY3UoLaiD7LnlLg3lRU2robRFfSmJYqEMd
vdbaMFqrLMV0MLa6mT4a1eN9diN38bQPOEM6yECqK1VV6zgynXadOYJAHhNg
w4iR+rK3aC5wrsSLyqu7PIIkmsHZcVIJYl8bYY62OnOusSQPq13P2ocbAadb
U+j9BD/V8yMG7DJkt9FkbgE1S9VVq+/MoR9g567ZaLWjDtvY4zFWptJOojY5
2qJaVCn8x/ecHDdV4wsAgyH9zjFLOz7vlBl0YuSCMpO17b0aMFytU6ZuqX5L
P57jtGdCY2n9RXsQajimyCuB8kYh5K9o5YHxyLYdKlbpw045+fHc9rULiy01
o+teplYvxLKVsQ0WKbcHiFslycq5ms0XZj6sq5GlALfBw8TpqZ5qY3JSxgTg
AvATPkRWLOc6qa1x5GYvwTdEp4cWgr64wElOpc3DWHeZ7uGNESmcxCh757kn
Ji9n+6Kp9S05pBd33bsvjEuZwaH1kB7zsWox3Tdo38gZy0FfInq5fmar6lGQ
WjcEX7KNToYNxk5YPJiWkMqaMH3bxrk60vBrpIMSCAVEfrKrfyiXpV4qIDuz
NXc8OmNjFG8Ln6c6S0dB1KY0KINcewvLyKQN57oUK2T0pxtTwORH8kDxVnU1
P4vPxD09PswjkiLR55VUY9N6D3iR5gFUMeZDnshbp1z2iW/Y9ZX6c1WfwYvn
ESVI45v1e6v2BsffwiYajbZ1d8Se22NeBJE78NvVI8MgPHzEteU4ZqITAd30
SN1/Ik4HpFKwdvs7lmH/4zRfL+5bOk4askpJhrsqKDQ693NuDjaRjGkfffIQ
aVJTJjp3DSBMr0opNRT80EL6sQOnWnRd4fVX+MBxorF7B2CgsBHNSKnhcfWU
RYVP16wHb0tz6mv6gNmb3eu3px/2pFywSeMU0LNuJVEf8oHE4tAbkHp8aIdP
LHVqOTBXvH3Db4g3vmlRFYtjQtzAfEgyqGvR+x4ePqSC+NpVyE0UCYpprvoJ
s0TkNki/WYb/cdTOs2zlGUFD1czpxJ/LKYKr/BnqdGExPdKLzFIg3wJxvRoG
dxjUL+LF3vS2KixCXwJTB89F2bFRHI1B77pWY+fXDmHSKRpDUhxp+MUHiTVO
MdxNilny7rQUex/1mxijrMpZxS8n2UFxQ+eS5Ack2C0CjN6I/4g+u+nWVF3a
+hWI9KI5mvRBkz6xS/oK1RfuXqRHo+ndeHldIlVPjtVLu4+Wp/AVQfVlEmPL
b/oZEetlev+9K7+gl0oXH1Zquqp9v1izuzVj3ZtP+rS3NfYmv2fQ+wkEUWd8
g3ito3f6+nocVwqPkQDx8rRVs3wwH9SbnchT22FbwGPEz63RiG2RcKOy6iYb
xNJEJNu5dywZCOZWRSX/O5ck4cSFtdcVZAifzsA/HRJ7oMSRHkWDI6WziHq0
pf4qQASHaSozyZwTxW5+xGIyLb519WD97rdOpIqiY2PRchWYpQlIzWbEKTr8
KEgHpmMdTuOKHwBqNpBulMYOyoyHejhb0Or5hhPSqkxTOkD06PjHsqzMLvdK
ho9W6CJhZ2WsmqBW4wcZkw+9Uhnyl4j+k1uXqkSc84m/Q6GKpg1FfiUD72NU
tfarYsOwL5+lvGyat5m+DBGnK+XsfbHKuywxwUew6saHtO7KQl7GUjFX6PRM
yuUxD3Q3j8i8q+IBb6uJidjkJ4S2vHhSei2iPfThXIc5O7o4eqQG3R9nExdQ
VrGAw1rEz1l5RVPmuzLMsRcuX/BbmnEVtuA7oDhpKnbo9diWNvdoIcWfTrp0
C/mxAQjtKOarZld/iRIlVfzu0Iyiwmj0f/WrQC+LVAAA

-->
</rfc>