<?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-rfc version 1.7.29 (Ruby 3.4.4) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-linker-diem-requirements-00" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.29.0 -->
  <front>
    <title>DIEM Use Cases and Requirements</title>
    <seriesInfo name="Internet-Draft" value="draft-linker-diem-requirements-00"/>
    <author fullname="Felix Linker">
      <organization/>
      <address>
        <email>linkerfelix@gmail.com</email>
      </address>
    </author>
    <date year="2025" month="June" day="30"/>
    <area>Applications and Real-Time</area>
    <workgroup>Digital Emblems</workgroup>
    <keyword>next generation</keyword>
    <keyword>unicorn</keyword>
    <keyword>sparkling distributed ledger</keyword>
    <abstract>
      <?line 36?>

<t>The Digital Emblems (DIEM) working group (WG) will define an architecture and discovery mechanism to present and validate digital emblems.
This document lists use cases for the current and future scope of the DIEM WG and their associated requirements.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://felixlinker.github.io/diem-requirements/draft-linker-diem-requirements.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-linker-diem-requirements/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Digital Emblems Working Group mailing list (<eref target="mailto:diem@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/diem"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/diem/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/felixlinker/diem-requirements"/>.</t>
    </note>
  </front>
  <middle>
    <?line 41?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The Digital Emblems (DIEM) working group (WG) will define an architecture and discovery mechanism to present and validate digital emblems.
Digital emblems extend the range of existing, identifying marks (for examples, see the use cases below) from the physical (visual and tactile) to the digital realm.
This document lists use cases for the current and future scope of the DIEM WG and their associated requirements.
As of writing, the DIEM has an initial scope that limits WG work to digital emblems that can be discovered using the DNS and that identify their bearer by a Fully Qualified Domain Name (FQDN).
The WG intends to address use cases presented in <xref target="uc-initial"/> within the WG's initial scope, and presents use cases in <xref target="uc-other"/> for future WG work and reference.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

</section>
    <section anchor="uc-initial">
      <name>Use Cases and Requirements for Initial Scope</name>
      <t>Below listed use cases are intended to be addressed within the DIEM WG's initial scope (as chartered as of writing).
Every use case lists its associated requirements, which are specified in <xref target="reqs"/>.</t>
      <section anchor="digital-emblems-under-international-humanitarian-law">
        <name>Digital Emblems under International Humanitarian Law</name>
        <t>The Geneva Conventions and their Additional Protocols constitute the core of International Humanitarian Law (IHL) and establish legal rules on the conduct of armed conflict.
Some assets enjoy certain specific protections under IHL, including that they must not be attacked, and IHL codifies four types of protective emblems for armed conflict, which inform other parties that marked assets benefit from one or several of these specific protections.
Note that assets enjoy there protections irrespective of whether they are marked with the respective emblem.
The emblem only serves to inform others of these protections.</t>
        <ul spacing="normal">
          <li>
            <t>The emblems of the Red Cross, Red Crescent, and Red Crystal are applied to assets of the medical services as well as the assets of certain humanitarian operations.</t>
          </li>
          <li>
            <t>The Blue Shield emblem is applied to cultural property.</t>
          </li>
          <li>
            <t>The emblem for the protection of civil defense is applied to certain assets for the protection of the civilian population against the dangers of hostilities or disasters.</t>
          </li>
          <li>
            <t>The dangerous forces emblem is applied to works or installations containing dangerous forces, i.e., dams, dikes, and nuclear generating facilities.</t>
          </li>
        </ul>
        <t>Digital emblems under IHL will be borne by network-connected and network-addressable assets that enjoy aforementioned specific protections under IHL and whose disruption would violate these protections.</t>
        <section anchor="requirements">
          <name>Requirements</name>
          <t>Digital emblems under IHL <bcp14>MUST</bcp14> identify the issuing party and <bcp14>MUST</bcp14> provide a means for authorization by third parties.
Additionally, this use case has the following requirements:</t>
          <ul spacing="normal">
            <li>
              <t>Authenticity</t>
            </li>
            <li>
              <t>Authorization and Decentralized Authorization</t>
            </li>
            <li>
              <t>Accountability</t>
            </li>
            <li>
              <t>Revocation</t>
            </li>
            <li>
              <t>Undetectable Validation</t>
            </li>
          </ul>
        </section>
      </section>
      <section anchor="marking-of-the-press">
        <name>Marking of the Press</name>
        <t>TODO</t>
      </section>
      <section anchor="the-ramsar-convention">
        <name>The Ramsar Convention</name>
        <t>TODO</t>
      </section>
    </section>
    <section anchor="uc-other">
      <name>Other Use Cases and Requirements</name>
      <t>The initial DIEM efforts do not include the following use cases.
They are listed here for documentation and future reference.
The requirements of these use cases are not complete and would need to be investigated further when addressing the use cases.</t>
      <section anchor="marking-of-hazardous-materials">
        <name>Marking of Hazardous Materials</name>
        <t>The Organization for the Prohibition of Chemical Weapons (OPCW), the International Atomic Energy Agency (IAEA), and the Basel Convention require that certain, dangerous materials are marked during shipment.
Concretely:</t>
        <ul spacing="normal">
          <li>
            <t>The OPCW requires marking of Schedule 1 chemicals.</t>
          </li>
          <li>
            <t>The IAEA administers several treaties related to the shipment of atomic fuels and wasters across borders.</t>
          </li>
          <li>
            <t>The Basel Convention regulates the trans-boundary movement of hazardous wastes.</t>
          </li>
        </ul>
        <t>An emblem <bcp14>MUST</bcp14> provide a description, location, date, and quantity.
The description <bcp14>MUST</bcp14> be accessible only by authorized parties, e.g., customs agencies or material handlers.</t>
      </section>
      <section anchor="marking-of-brand-associated-shipments">
        <name>Marking of Brand-Associated Shipments</name>
        <t>World Intellectual Property Organization (WIPO) administers treaties, in particular the Madrid Protocol, that allow brands to mark their shipments with an emblem so that customs agents can identify legitimate products.</t>
        <t>An emblem <bcp14>MUST</bcp14> identify the copyright/brand image, provide a textual description of the shipment, and a chain-of-custody/provenance.</t>
      </section>
      <section anchor="marking-of-civil-aviation-flights">
        <name>Marking of Civil Aviation Flights</name>
        <t>The International Civil Aviation Organization (ICAO) requires that civil aviation flights are protected and that one can verify them to not be dual-use, e.g., not carrying military cargo.</t>
        <t>An emblem <bcp14>MUST</bcp14> carry a geographic description of the flight plan, its current location, and a textual description of the flight including its manifest, identifying characteristics, e.g., tail number.
An emblem may need to also reference a flight manifest.</t>
      </section>
    </section>
    <section anchor="reqs">
      <name>Requirements</name>
      <section anchor="authenticity">
        <name>Authenticity</name>
        <t>Validators <bcp14>MUST</bcp14> be able to verify that an emblem was issued for the respective bearer, issued by the claimed issuer (where applicable), and that none of its associated data was changed.</t>
      </section>
      <section anchor="authorization">
        <name>Authorization</name>
        <t>Validators <bcp14>MUST</bcp14> be able to verify that an emblem issuer was authorized to issue the emblem.
Authorizing parties <bcp14>MAY</bcp14> limit what emblems an issuer can issue, e.g., they <bcp14>MAY</bcp14> limit issuance to certain bearers.</t>
        <section anchor="decentralized-authorization">
          <name>Decentralized Authorization</name>
          <t>Anyone <bcp14>MUST</bcp14> be able to authorize an issuer.</t>
        </section>
      </section>
      <section anchor="accountability">
        <name>Accountability</name>
        <t>Emblem issuance and authorization of issuers (where applicable) <bcp14>MUST</bcp14> be attributable to issuers and authorizing parties.
Authorizing parties and emblem issuers <bcp14>MUST NOT</bcp14> be able to repudiate that they issued an emblem or authorization.</t>
      </section>
      <section anchor="revocation">
        <name>Revocation</name>
        <t>Emblems and authorizations (where applicable) <bcp14>MUST</bcp14> be revokable within reasonable windows of time.
Depending on the design, it may suffice to rely on expiration of short-lived emblems and authorization effectively as a revocation mechanism.</t>
      </section>
      <section anchor="undetectable-validation">
        <name>Undetectable Validation</name>
        <t>Bearers <bcp14>MUST NOT</bcp14> be able to detect whether someone is requesting or validating emblems issued for them.</t>
      </section>
      <section anchor="visual">
        <name>Visual</name>
        <t>An emblem <bcp14>MUST</bcp14> be capable of carrying a visual representation of the physical emblem it represents.</t>
      </section>
      <section anchor="law-carrying">
        <name>Law Carrying</name>
        <t>An emblem <bcp14>MUST</bcp14> carry an unambiguous indication of the international law or laws conferring the semantics of the emblem.</t>
      </section>
      <section anchor="proximity-based-distribution">
        <name>Proximity-Based Distribution</name>
        <t>An emblem <bcp14>MUST</bcp14> be presentable using an in-band, proximity-based protocol such as a QR code or RFID.</t>
      </section>
      <section anchor="physical-binding">
        <name>Physical Binding</name>
        <t>An emblem <bcp14>MUST</bcp14> be possible to associate with physical assets, e.g., buildings, vehicles, or containers.</t>
        <section anchor="quantifiable">
          <name>Quantifiable</name>
          <t>An emblem <bcp14>MUST</bcp14> be possible to associate with a range or specific quantity of associated, physical assets.</t>
        </section>
        <section anchor="geographic">
          <name>Geographic</name>
          <t>An emblem <bcp14>MUST</bcp14> be restrictable by geographic scope.</t>
        </section>
      </section>
      <section anchor="identity-binding">
        <name>Identity Binding</name>
        <t>An emblem <bcp14>MUST</bcp14> be possible to associate with a person or group of people.</t>
      </section>
      <section anchor="human-readable-validation-data">
        <name>Human-Readable Validation Data</name>
        <t>An emblem <bcp14>MUST</bcp14> be capable of providing additional relevant information (e.g., photographs, unique identifiers) which can be used to corroborate the association of the digital emblem with the entity bearing it.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TODO Security</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
    <section anchor="contributors">
      <name>Contributors</name>
      <t>Parts of this document are based on <xref target="I-D.draft-haberman-digital-emblem-ps-03"/> and <xref target="I-D.draft-linker-digital-emblem-02"/>.
As part of that, Brian Haberman (brian@innovationslab.net), Tommy Jensen (tojens@microsoft.com), and Bill Woodcock (woody@pch.net) contributed to writing this document.
Furhermore, Rohan Mahy (rohan.ietf@gmail.com) provided valuable feedback on contents and structure, and Samit D'Cunha (sdcunha@icrc.org) provided feedback on the IHL aspects of this document.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <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="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <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>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="I-D.draft-haberman-digital-emblem-ps-03">
          <front>
            <title>Problem Statement for Digitized Emblems</title>
            <author fullname="Brian Haberman" initials="B." surname="Haberman">
              <organization>JHU/APL</organization>
            </author>
            <author fullname="Tommy Jensen" initials="T." surname="Jensen">
              <organization>Microsoft</organization>
            </author>
            <author fullname="Bill Woodcock" initials="B." surname="Woodcock">
              <organization>PCH</organization>
            </author>
            <date day="18" month="November" year="2024"/>
            <abstract>
              <t>   International law defines a number of emblems, such as the blue
   helmets of United Nations peacekeeping forces, the blue and white
   shield of UNESCO, and the Red Cross of the International Committee of
   the Red Cross, as indicative of special protections under the Geneva
   Conventions.  Similar protections attach to journalists who wear
   "Press" protective emblems on the battlefield, under Article 79 of
   Protocol I of the Geneva Conventions and Resolution 2222 of the
   United Nations Security Council.  The emblems of national governments
   and inter-governmental organizations protect diplomatic pouches,
   couriers, and envoys under the Vienna Convention on Diplomatic
   Relations.  Other marks enjoy protections against mis-use under the
   Paris Convention, the Madrid Protocol, and the Trade-Related Aspects
   of Intellectual Property Rights.

   Such physical emblems have a number of weaknesses and do not
   translate to the digital realm.  This document provides a summary of
   the problems and documents identified requirements from a number of
   stakeholders for a digital emblem which addresses the shortcomings of
   the physical emblems and makes possible the indication of protections
   of digital assets under international law.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-haberman-digital-emblem-ps-03"/>
        </reference>
        <reference anchor="I-D.draft-linker-digital-emblem-02">
          <front>
            <title>Problem Statement for a Digital Emblem</title>
            <author fullname="Felix Linker" initials="F." surname="Linker">
              <organization>ETH Zurich</organization>
            </author>
            <author fullname="Mauro Vignati" initials="M." surname="Vignati">
              <organization>ICRC</organization>
            </author>
            <author fullname="Tommy Jensen" initials="T." surname="Jensen">
              <organization>Microsoft</organization>
            </author>
            <date day="28" month="June" year="2024"/>
            <abstract>
              <t>   In times of armed conflict, the protective emblems of the red cross,
   red crescent, and red crystal are used to mark _physical_ assets.
   This enables military units to identify assets as respected and
   protected under international humanitarian law.  This draft explores
   how one could apply the protective emblems to _digital_, network-
   connected infrastructure using a _digital emblem_, and defines the
   requirements of a digital emblem, emphasizing security requirements.

   Notably, a digital emblem has a unique combination of security
   requirements, namely, authentication, accountability, and a property
   that we call _covert inspection_. Covert inspection means that those
   wishing to authenticate assets as protected must be able to do so
   without revealing that they may attack unprotected entities.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-linker-digital-emblem-02"/>
        </reference>
      </references>
    </references>
    <?line 218?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA81a23IctxF9n69AVg8mU9ylZLsqDsuxtbxJdPEikZRZrlQe
sDPYHZgzgzEws9RapX/Jt+TLcroBzGVJMeW8JC/SLhZodJ++HQCcTqdJo5tC
HYjJ8dnJhfjglDiSTjkhq0xcq99abVWpqsZNklQ2amXs5kDoammSJDNpJUss
zaxcNtNCV/fKTjOtyqkdLJy+fJm4dlFq57Spmk2NFWcnt6dCvBCycAZb6ypT
tcI/VTPZExOV6cZYLQv6cjY/xH/G4tP17ekkqdpyoexBkkGbgyQ1lVOVa92B
aGyrkvWB+CaRVklIndd1oaE0do3myGJ6q0s1SR6MvV9Z09ZkuF7pRhbipFwU
qoSh92qD37ODRExFpT42YqUqZVkQDbWVTo3lj66W9h6Gr0SmXWP1om1UJgqV
rZRN1qpqoaIQX9xICA/H5A7qkJQ3NJPGS6kLjBOYr7VqljNjVzQubZpjPG+a
2h3s79M0GtJrNYvT9mlgf2HNg1P7JIDWYeO8XWDlUhX6o3fV/iNX0cwCuLpm
sMdgxcyLmWnzeO3+81Ewy5uymCSJbJvcWIIWewmxbIvCB9EpbSPOeTn/pDwG
XiAr8XpFQ7PUlElSGVvCI2sAnFA49t9ms1mSTKdTIRdwiUybJLnNldgCX+xQ
vO+Kh4A8+0js3L3BkC4KkamlrhTChiHXjUqb1ioOI7g6NWtlN6JUaS4r7UrR
GFFbhVBseMpaFpoCFHP9rsrvOoMq2glkTkuowDjXONEi6VJOOtghGiibttZG
WcuWd8aetRJmyb9zrt694d/xXVshnTOplhR+I9g9FKXOskIlyQtxVjXWZG3K
wfz/BMzxeEAg75S3TlhZrdh09RF4Qak9oalW6OWGNCyRg1CbsFMfZVkXyu0J
pxSv7bFdqMI87IqlNSX/Uucbh/JQiJ21di3+ZzARL7pQu6Q3TYpqoqIU5f/A
e3NHix6s9mZ3q3NJJQ2FGD9APS++ySUpVWpoBfHkQbJjC2o/LcXqhepcho1b
R2DyDpc3QTdMjEgHTRcK1RX/bYQUp0jejXgP7PRSQ8KxQX5W4hL5LHZO3x9f
7s44wqCLrsibjtSRWYaAGOIWAgQSsPrTpzadBrs+f0bMNTlGGxbzlRtbvMdq
huVDiVGOwToLKeSZ4IkIDK20agnTq1TNKDWOTLUmW2O7OKZI1/zdZwr6Aq2F
GZOLDze31J3of3F5xZ+vT95/OLs+OabPN2/n5+fdhyTMuHl79eH8uP/Urzy6
urg4uTz2izEqRkPJ5GL+y8RbO7l6d3t2dTk/nwjGZRiQcA0hDL8S3hbAEKjS
JZlyKbqTR/jw6N2//vnqWyD0p+vTo69fvforEPJfvnv1l28J9FxVfjdTwcP+
K6DcJLKuEQAkRaIWpLKmyEK6IRxdbh4qAbwJzT//nZD5x4H4fpHWr779IQyQ
waPBiNlokDF7PPJosQfxiaEntunQHI1vIT3Wd/7L6HvEfTD4/Y8F1cLpq+9+
/CGhEPoyfeIQPAvBe8Pp+unFINKT5JDqE9cUTsYYyuRTnz0Y9s4NGYTvg+wI
RWU7RcQOXINibBtOcjmsJ0jPEy7XcbdQ0ah+fKEi7SEYdJqzVq5WqU98TjdM
c58/Uya9eNRTWmhP5kOJinkUfnvblmgRjQTRq8S5fPA59gZUay0f5aIvPvMs
02H1O2sak5oCxmEOOCyYly++xnKhfX4zsXP29nyXRYPtyAUMz8HbVlTqWzQQ
BH6QVlGzJIHSljAVA0uwymaW3BiUOcCkgJaqfjUbkSrbUAEMwKSoTIb6I1sR
IHh7juZVpUWb+WqLCkuJJcrWNaIyDfu3QRu6V5lPQSzBrhkhTVHUWiaN7Mco
f6264k5hNtY0usyzJMElUYC3NiSPFaAGyrHBtizggaVufKM0CG9IdApxAmx8
A3PqSRNnyaVpQhca4UI7qhEYGg2SRLDqFJC5YrUYCoqtoBLFt6cA/XRvqe8s
/rOvUk7ZteIOM7TU9TqPVE2mohcQJyFjM3FkjUOc+4+omwjDvZDONLJxFNik
o6TzhU/KYG6QAvSZWJBGOqUcduJBoV5Kx7/3s2PE5MPwRNb6wwbU9FoeFq0S
N7lWRRZNRtkf7J+2BZobtoSNWN1sZiP7OmbSQ8C767VmQocTlNqWGDQLuj4t
gDOEhJDatanbgvUWcoWlrvEMisibd0NukKiF5sCDPHAPiWJnOzP9VNPydoTb
k7ZS9+b1tAW6UDjgIdxJYT6LbclBxs3UbA/jJT5n+p6GyKNVmxbUzuL5DmuX
Mg0qIka2OWmXw54KI1UXOAgqYkOVakixKdSoABClE20QRkPFRp3pvM9p4vND
Qk0urzAEC58vHyz3AVAyebNtzYg/mBaxsdaGjm9PxvsLlOVhQ3rOOm7VQ+IH
F7iW4KG6sWEVeA62WGMeuGCpZBWqD5/w9O8+FBa0XtssVhxQ2q6IF5s9T2C6
/pOHDFmaAs2QNhw2nwPK2jnEk2Kpbjbha7+bp22UskgG/TvAHP1O89PUtIiU
BXmZBFyrtUnjrx8AAWHGjvrZn1X4oATwLqQ/EIW4f0cORc+6Or7inymArxFg
CKe+eXW/iyuub8/wA2YDnq/6ThjbODd2tQS0DVE9bhK+g6gtrDrSwMXRF9LA
J7gCk3ciV+zxCrx4wIVvueAOdOtK6JiWkCY4jOPA1fgDoI/CSnVMRQMI5PyK
ecSytQwC0cnIYeKRY6D6FtZv5e/SZpTMF5BCt0KBjV/ZFWpmcHysT6AFuV7o
WKCOclVyKb5TsqY02rl6d3S36w9SY4YwbwymihNUgtVGzFES0g1YwvxkvrsX
KYg4hIrFwL8RpnCm8jVzb1CAyqjzsKtlrSXjXK5rwneWQGBKXL3YHMTGRHpG
6Y4XBjxu0lxloCjiFWidt64roKQtkC0ROlxYu77d4PzKZdeqgn0RjrdRBeY3
HoBlqwofng++OguZUkekUpcNivUTUKxavjxiyUjAyk0XyLVM0oUADplxo7zz
KO9ALp9XsdZvlRV/cOEatyeKkKgEcBMOf7+1EttTw+MO0k/3kohNpSkFGmU0
8wQ6uoaioLqytCfUbIUWkYKGGdRCSf4PfSr6EIpXWcEQbMXoIYzNpvOeMt8E
XBGqd8YiJyjWioLuSjx35SY9DuGdu7N3V7sj90W3EWX0mqLRSx/pFzKzOut4
8F7gXVQLxIL0YSpEgRPIc/S186xKdpA7E8J3YDtm0Q1B1wNAjZFUhAQ5hyjx
E24bdQwcPjZWr/Jmn7URWLyCz3rXNuojozH0WaitUVXvYknnF11NzXLKKmab
fZKiKhlO7iNfHDGpma+1R/W0IB1CyRhn/NbMsTPOjuZwRpeAHiBeIOOCpRfN
mR16bWj7PJuoM2GIDAyY8G1Y4PgZTJ+i6sXA41oqrfU3WtScKG0wsjKPgeaJ
wGWlzMrKGvT+KRS9fqIuJDKGznTxXqrPIw/vM54IMvoTC8khrrpEXR9fw9Eh
U6aUKqj4aZdRqIiF8Jf2s4Edpdx0jYJeAfr+A4XCrnEfvp3ZapZ82mTfjwhB
Epq2QfZ0BYBSH9t0jqA86RRBDWJ2Qw0qNJHBYcNfd+3FGYsQ24XUdMTiUSt2
Hri9Sv/eAKldx5B0pqv4iLN1qIaOkvemi9KVymadLT1b+ePGBIVI7qDG0ZGI
fmDd4/EpbhVZHRW7i/kv/v4QPZrYaSCGVAi84DR+7LxLPKNfRr9RVg5PEB7C
SEGfY2cIjw2htW1rZ0qvSYBrTOaSkx4F1oLDe0QQyREswD3htX7jxr/lRAXi
kqG8AW5Pg8l3C0O3BCfSndPAOKtqZJaMB2cGNERb79dtWu3NH1DX5KTz1ZbJ
zxpqIeGeNQk3SWg4DsXRj1SZefDkD9E+S475jY7LrL8cQb3QK64tnM6uXeLU
EoxCo8Us9bHWtkPeQSt6IVqrbBBb2y4C1fXJBxEUx6ykN7N/V/AAfJGuH/qY
exJwv6S7cnCmVBR02nG1V/zAQICHpwr6FpUd14mgxM/8evCoRi+o+te8KR21
Y2mXIrw2wO/+3loO6233KBEjp+knBt5Bt1dHQdyXOkOFw5wsF3rVEs2CI8M7
aNxGjxphAYkwCf/xMRp12EZe7lRJ/Crt7jZi+SBNwD0+UtpvpkQGcfKKb6Ah
mbfxiAYTJv61gZ8wpgsEATODIG3B0urAbBBXdOFIkfD+mm7C+Ebq+vTsOGgR
ITvUHJ1P7mwCA/R3Nb4Iex7UIe7P5bGwLVpdkDQMrBUaLD8qYd9wzdAXtPdM
QJearPqDW8v4smX7M3/ks8zIu3axt61m2PxNRwCe2hpwwx8hPdC6BnSB74Y9
fmfcw7Hjf4efFOCyjkLLhrdCuphUBqdCL5+vXqfXSmZbaSqO0QP/Q954usih
0t/9orqoNWAS3cMvMTbvtzpH1LCV8FdbaWR0ZCkaeu6Gy9Dw/NW6cNtlrDU4
4ITLk87GQcqMX9H6m8kAHnU5z4+YrdwokC0axwHJYf9woefvA7pf+c3gbH45
fzxt9K5D1yKV8TNlf6NDq3zCgSEkyTtp41l9+1HIZ5Sha/ofz6bHM/9Wn0uQ
MnJOsG3qbZvWbvrym8+fuTaPFnSP+6PpL7+ma/+5487n95fghod8mfk27CF2
FvT9ta4qs/ZWFnIxq1QDsnRrynIjfqJrSExszK/49BqHUZw7zbKhB//AqA7p
2u3OmCw16T0aGz5tXtdpznI4N+PfYNBFoX/lGMMxS05bi7pfGgsSc23QTnB6
yHHUt/SZ/4qi/zuD3Xhe4ZfrlqNyCda6kNgecNKOTEhJOSRby4/hXtcbSYzo
+Kujtsql2HFZSh9ew6qU/kxjIHookS8m6JaPKehjd4YHfZpOETBP7yvzQH9w
4o+bnw481VbZ3yZL8Go1+RxiTnYzkZf/BiQ6x6T4IwAA

-->

</rfc>
