<?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.6.24 (Ruby 3.2.0) -->
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-bormann-cbor-rfc-cddl-models-01" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <front>
    <title>CDDL models for some existing RFCs</title>
    <seriesInfo name="Internet-Draft" value="draft-bormann-cbor-rfc-cddl-models-01"/>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization>Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        <email>cabo@tzi.org</email>
      </address>
    </author>
    <date year="2023" month="February" day="25"/>
    <keyword>CDDL models</keyword>
    <abstract>
      <t>A number of CBOR- and JSON-based protocols have been defined before
CDDL was standardized or widely used.</t>
      <t>This short draft records some CDDL definitions for such protocols,
which could become part of a library of CDDL definitions available for
use in CDDL2 processors.  It focuses on CDDL in (almost) published
IETF RFCs.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro">
      <name>Introduction</name>
      <t>(Please see abstract.)
Add in <xref target="STD94"/> <xref target="STD90"/>
        <xref target="RFC8610"/> <xref target="RFC9165"/> <xref target="I-D.bormann-cbor-cddl-more-control"/></t>
    </section>
    <section anchor="cddl-definitions-for-almost-published-rfcs">
      <name>CDDL definitions for (almost) published RFCs</name>
      <t>This section is intended to have one subsection for each CDDL data
model presented for an existing RFC.
As a start, it is fleshed out with three such data models.</t>
      <section anchor="rfc-7071">
        <name>RFC 7071</name>
        <t><xref section="H" sectionFormat="of" target="RFC8610"/> contains two CDDL definitions for <xref target="RFC7071"/>,
which are not copied here.
Typically, the compact form would be used in applications using the
RFC 7071 format; while the extended form might be useful to
cherry-pick features of RFC 7071 into another protocol.</t>
      </section>
      <section anchor="rfc-8366">
        <name>RFC 8366</name>
        <t><xref target="RFC8366"/> defines a data model for a "Voucher Artifact", which can be
represented in CDDL as:</t>
        <sourcecode type="cddl"><![CDATA[
voucher-artifact = {
  "ietf-voucher:voucher": {
    created-on: yang$date-and-time
    ? (
        expires-on: yang$date-and-time
        ? last-renewal-date: yang$date-and-time
        //
        nonce: json-binary<bytes .size (8..32)>
      )
    assertion: assertion
    serial-number: text
    ? idevid-issuer: json-binary<bytes>
    pinned-domain-cert: json-binary<bytes>
    ? domain-cert-revocation-checks: bool
  }
}

assertion = "verified" / "logged" / "proximity"

yang$date-and-time = text .regexp cat3<"[0-9]{4}-[0-9]{2}-[0-9]{2}T",
                            "[0-9]{2}:[0-9]{2}:[0-9]{2}([.][0-9]+)?",
                            "(Z|[+-][0-9]{2}:[0-9]{2})">

cat3<A,B,C> = (A .cat B) .cat C

json-binary<T> = text .b64c T
]]></sourcecode>
        <t>The two examples in the RFC can be validated with this little patchup
script:</t>
        <sourcecode type="shell"><![CDATA[
sed -e s/ue=/uQ=/ -e s/'"true"'/true/ | cddl rfc8366.cddl vp -
]]></sourcecode>
      </section>
      <section anchor="bis">
        <name>7807bis</name>
        <t>The RFC to be published out of <xref target="_7807bis"/> defines a simple data model
that is reproduced in CDDL here:</t>
        <sourcecode type="cddl"><![CDATA[
problem-object = {
  ? type: ~uri
  ? title: text
  ? status: 100..599
  ? detail: text
  ? instance: ~uri
  * (text .regexp "\\*.*")
    .feature "standard-problem-object-extension" => any
  * text .feature "problem-object-extension" => any
}
]]></sourcecode>
        <t>Note that <xref section="B" sectionFormat="of" target="RFC9290"/> also defines a CBOR-specific data
model that may be useful for tunneling <xref target="RFC7807"/> problem details in
<xref target="RFC9290"/> Concise Problem Details.</t>
      </section>
      <section anchor="yang-sid">
        <name>YANG-SID</name>
        <t>The RFC to be published out of <xref target="YANG-SID"/> defines a data model for a
"SID file" in YANG, to be transported as a YANG-JSON instance.</t>
        <t>An equivalent CDDL data model is given here:</t>
        <sourcecode type="cddl"><![CDATA[
sid-file = {
  "ietf-sid-file:sid-file": {
    module-name: yang$yang-identifier
    ? module-revision: revision-identifier
    ? sid-file-version: sid-file-version-identifier
    ? sid-file-status: "unpublished" / "published"
    ? description: text
    ? dependency-revision: [* dependency-revision]
    ? assignment-range: [* assignment-range]
    ? item: [*item]
  }
}

rep<RE>=cat3<"(", RE, ")*">
opt<RE>=cat3<"(", RE, ")?">
cat3<A,B,C> = (A .cat B) .cat C

id-re = "[a-zA-Z_][a-zA-Z0-9\\-_.]*"
yang$yang-identifier = text .regexp id-re
revision-identifier = text .regexp "[0-9]{4}-[0-9]{2}-[0-9]{2}"
sid-file-version-identifier = uint .size 4
sid = text .decimal (0..9223372036854775807)
plus-id<Prefix> = Prefix .cat id-re
schema-node-re = cat3<plus-id<"/">, plus-id<":">, ; qualified
                      rep<plus-id<"/"> .cat       ; optionally
                          opt<plus-id<":">> > >     ; qualified
schema-node-path = text .regexp schema-node-re

dependency-revision = {
  module-name: yang$yang-identifier
  module-revision: revision-identifier
}

assignment-range = {
  entry-point: sid
  size: sid
}

item = {
  ? status: "stable" / "unstable" / "obsolete"
  (
    namespace: "module" / "identity" / "feature"
    identifier: yang$yang-identifier
  //
    namespace: "data"
    identifier: schema-node-path
  )
  sid: sid
}
]]></sourcecode>
      </section>
      <section anchor="your-favorite-rfc-here">
        <name>Your favorite RFC here...</name>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document makes no requests of IANA.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security considerations</name>
      <t>The security considerations of <xref target="RFC8610"/>, <xref target="RFC9165"/>, <xref target="I-D.bormann-cbor-cddl-more-control"/>, <xref target="STD94"/> and <xref target="STD90"/> apply.
This collection of CDDL models is not thought to create new security
considerations.
Errors in the models could -- if we knew of them, we'd fix those
errors instead of explaining their security consequences in this
section.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="STD90">
          <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 for the portable representation of structured data.</t>
              <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, 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="STD94">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman">
              <organization/>
            </author>
            <date month="December" year="2020"/>
            <abstract>
              <t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
              <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049.  It does not create a new version of the format.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="94"/>
          <seriesInfo name="RFC" value="8949"/>
          <seriesInfo name="DOI" value="10.17487/RFC8949"/>
        </reference>
        <reference anchor="RFC8610">
          <front>
            <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
            <author fullname="H. Birkholz" initials="H." surname="Birkholz">
              <organization/>
            </author>
            <author fullname="C. Vigano" initials="C." surname="Vigano">
              <organization/>
            </author>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <date month="June" year="2019"/>
            <abstract>
              <t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049).  Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8610"/>
          <seriesInfo name="DOI" value="10.17487/RFC8610"/>
        </reference>
        <reference anchor="RFC9165">
          <front>
            <title>Additional Control Operators for the Concise Data Definition Language (CDDL)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <date month="December" year="2021"/>
            <abstract>
              <t>The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point.</t>
              <t>The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed: , , and  for the construction of constants; / for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and for indicating the use of a non-basic feature in an instance.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9165"/>
          <seriesInfo name="DOI" value="10.17487/RFC9165"/>
        </reference>
        <reference anchor="I-D.bormann-cbor-cddl-more-control">
          <front>
            <title>More Control Operators for CDDL</title>
            <author fullname="Carsten Bormann" initials="C." surname="Bormann">
              <organization>Universität Bremen TZI</organization>
            </author>
            <date day="25" month="February" year="2023"/>
            <abstract>
              <t>   The Concise Data Definition Language (CDDL), standardized in RFC
   8610, provides "control operators" as its main language extension
   point.  RFCs have added to this extension point both in an
   application-specific and a more general way.

   The present document defines a number of additional generally
   application control operators for text conversion (Bytes, Integers,
   JSON) and operations on text.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-bormann-cbor-cddl-more-control-00"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC7807">
          <front>
            <title>Problem Details for HTTP APIs</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <author fullname="E. Wilde" initials="E." surname="Wilde">
              <organization/>
            </author>
            <date month="March" year="2016"/>
            <abstract>
              <t>This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7807"/>
          <seriesInfo name="DOI" value="10.17487/RFC7807"/>
        </reference>
        <reference anchor="RFC8366">
          <front>
            <title>A Voucher Artifact for Bootstrapping Protocols</title>
            <author fullname="K. Watsen" initials="K." surname="Watsen">
              <organization/>
            </author>
            <author fullname="M. Richardson" initials="M." surname="Richardson">
              <organization/>
            </author>
            <author fullname="M. Pritikin" initials="M." surname="Pritikin">
              <organization/>
            </author>
            <author fullname="T. Eckert" initials="T." surname="Eckert">
              <organization/>
            </author>
            <date month="May" year="2018"/>
            <abstract>
              <t>This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer.  This artifact is known as a "voucher".</t>
              <t>This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure.  Other YANG-derived formats are possible.  The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)).</t>
              <t>This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8366"/>
          <seriesInfo name="DOI" value="10.17487/RFC8366"/>
        </reference>
        <reference anchor="_7807bis">
          <front>
            <title>Problem Details for HTTP APIs</title>
            <author fullname="Mark Nottingham" initials="M." surname="Nottingham">
         </author>
            <author fullname="Erik Wilde" initials="E." surname="Wilde">
         </author>
            <author fullname="Sanjay Dalal" initials="S." surname="Dalal">
         </author>
            <date day="26" month="January" year="2023"/>
            <abstract>
              <t>   This document defines a "problem detail" to carry machine-readable
   details of errors in HTTP response content to avoid the need to
   define new error response formats for HTTP APIs.

   This document obsoletes RFC 7807.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/ietf-wg-httpapi/rfc7807bis.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-httpapi-rfc7807bis-05"/>
        </reference>
        <reference anchor="RFC9290">
          <front>
            <title>Concise Problem Details for Constrained Application Protocol (CoAP) APIs</title>
            <author fullname="T. Fossati" initials="T." surname="Fossati">
              <organization/>
            </author>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <date month="October" year="2022"/>
            <abstract>
              <t>This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational State Transfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9290"/>
          <seriesInfo name="DOI" value="10.17487/RFC9290"/>
        </reference>
        <reference anchor="RFC7071">
          <front>
            <title>A Media Type for Reputation Interchange</title>
            <author fullname="N. Borenstein" initials="N." surname="Borenstein">
              <organization/>
            </author>
            <author fullname="M. Kucherawy" initials="M." surname="Kucherawy">
              <organization/>
            </author>
            <date month="November" year="2013"/>
            <abstract>
              <t>This document defines the format of reputation response data ("reputons"), the media type for packaging it, and definition of a registry for the names of reputation applications and response sets.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7071"/>
          <seriesInfo name="DOI" value="10.17487/RFC7071"/>
        </reference>
        <reference anchor="YANG-SID">
          <front>
            <title>YANG Schema Item iDentifier (YANG SID)</title>
            <author fullname="Michel Veillette" initials="M." surname="Veillette">
              <organization>Trilliant Networks Inc.</organization>
            </author>
            <author fullname="Alexander Pelov" initials="A." surname="Pelov">
              <organization>Acklio</organization>
            </author>
            <author fullname="Ivaylo Petrov" initials="I." surname="Petrov">
              <organization>Google Switzerland GmbH</organization>
            </author>
            <author fullname="Carsten Bormann" initials="C." surname="Bormann">
              <organization>Universität Bremen TZI</organization>
            </author>
            <author fullname="Michael Richardson" initials="M." surname="Richardson">
              <organization>Sandelman Software Works</organization>
            </author>
            <date day="26" month="July" year="2022"/>
            <abstract>
              <t>   YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit
   unsigned integers used to identify YANG items, as a more compact
   method to identify YANG items that can be used for efficiency and in
   constrained environments (RFC 7228).  This document defines the
   semantics, the registration, and assignment processes of YANG SIDs
   for IETF managed YANG modules.  To enable the implementation of these
   processes, this document also defines a file format used to persist
   and publish assigned YANG SIDs.


   // The present version (-19) adds in draft text about objectives,
   // parties, and roles.  This attempts to record discussions at side
   // meetings before, at, and after IETF 113.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-sid-19"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>TBD</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA41Y/VLcOBL/X0+hcq4qQEZmGL6dADdAdo+rq2wu4a7qQqgt
ja1htHgsx5aBCUue5t7kXux+LclmBggJW5uR5VZ3qz9+3W0hBLtK+DpjVttc
JXyfcX50fPwPPjWZyms+NhWvzVRxdaNrq4sL/uGXo5q94HI0qhSOHh3+9oEX
zXSkqpplJi3kFGyySo6tGJlqKotCpFiIapyKNMty4TmL/hrLpAXtoD9YF/2B
GGyySzW7NlWWzKvAUmkTrouxYbWtlJwm/OTt6S+MlTrhZ9akPShY4c24xmo2
9YvUTEuZWreYqsLW54zJxk5MleCGAv9z8KwhKeaHXk2359U/klVtVbHwxlQX
Cf9Xoa9wUW3/91/LDysF1vz004kjIO0UVH1vajuW6YSvr/c3NvruXartLAkH
/AbulvBjMdhZ39wNO01hK1D9qkjozG2WE1OA7tXGrtgYrInB2o7YWt8drLmX
aip1nvBUjsxf7VcdQ0PGClLZQku658fT491+4ohFwv+ojRe+l5AXdwZOMtFs
dDTkqnma3Q2iodXWWh+v4UD/vLu2tYlnA51NTvqciON4weHB2ZUSgaojHzBy
55ye4Le9098Oy531rS1a0tZIw0fEWis7FhNrS1lqiqXwMigz8NckPv3ttYRX
qmysu+1/hu9+FR9Pjue4pKRTrTPGhBAIZDgOocLYMMQxN2MX1nhXZPzvH397
J0ayVhkvK4N4M0iLibxSfKTg/UyNdYF3I4UbKeYC91rWiAYcllWmv+Ilkuha
I5hnvAGfmLHTiQYJotH6VIHC0Cqrfa45Jo6xttoUIQsbhFSnQY9dTzQ2EDU5
CU/pXCnBD8pLnutRJauZu8lDZvIKYSNHuSK2DAohERzVgNinqkY61TEcakGQ
4n3NjScgwiWZTxHgy7xsRrmuJypjlI4OFmJv0amG5xVjJ+TsrElJLA9/ty80
7d6xvbk/xpbe5wom5rVSnUPiZTbMMpJ5e+si6u6OVhTFd3eM9iDG77VhuPA0
ABWA6kljPr6Fx7XgGOV1xhLaqiLDa2u805GPcMWoJSFmipLdi5FWMgdbMKWq
gTs4SSSyWADQmA3hB4qRChClLUka58rpYRqLYLETbifAE+924hvgEDZ+8YJ4
cIp0BjsMyxIq6hv+N3J3SFVYgswggXHcXpunrXB7GxLm7q6NJ1kpXhiLw6WG
MhNVqZidzkqdyjyf9aCUarGVWEz5dQhAF9nkLFmWOai9lKamG+MQazXmPvFf
c8hDCBI/dRNs7BhO9cXEBobjJofhWQo1qpmAEpd8rKRtKorJcWcF8pKBjQ24
VV2O3FuKAIUsFbAFtvFZSz64N613FI/+bRoSyIeV1cBxG/V4yDV4caQYsKXz
bcgcLuuEsW/fvnmAvPIchAwc+B6/BRRFDn3CyyT8Rol7B/xHbQNLYYqEz2Rx
8ReqjgIgIqyeKkdywJdYm0jqptRQ4zlyfySXtRWVKtS1zIWvuM/Qr652y8IU
qfJVQ4x0ATh5M5pZGC2uAWp8aSeO1wfL+4F+2f3KulYVuT65X/riqCoN+R5g
E27h83Al4OKVzoSu64bePBLnBZS6AMqKzKDmob6A83dJD/gcFW5+ZXw0Cpg7
vUQ5GRlDReyOAR86LeGjCKVdjxH2EV/lUW4uLsISEXWjpyjhEWOPbYeTdB0e
V+oCXkGY2PU30Vlf7J7fbtwJvxjcL06jXmfjp/6iljB5tFg6i8/d+tXywY+4
LH368+yVOH/EYznaZ8zpOOwd9o72of7SkMfY4YfL/veIsXnbnu53VxxtbaT8
lCKd3SauWdqLUIwpq2IK/eiOIFQ5yFE3cloC1ChJKM0pE30K8SuZa7Jh1iId
8C/XFh0oaphNJ03J6rTSpQ1ZBWDMc0YAI4CIq43aW23+ubfqn15GtmpU9HKV
flb5ny4H+bxW/KpEy0dKEyK0nYNTlJQCdkCn+0pACAx0ub0NlAt4UWu61Bxs
MDuRDsAJF6jczcECwec8MIAAdXcqzOgP1cHCAbezEon2ram0f/SteMiRAyoT
tkHcrvX7cby5u+s2M2Vd99dRAenRcqT3jFb40kJcRp8/r8QrkU/UOOAoj9pG
RSwqJxwq18iMiO/tc9+QroQw6A7/8MzdYqwEi3ax8s5YqgEw4FwdOwzYTl0d
bC/z2sw5wHVmdalSpGo6X3Edm6mczdUOQnTbADlyKkO+3EEDMA2KBzNSjPr6
EGQeAfs0+pH3gezYk/mS0raUPxFBLemzJYdFoOBjlMOIIofO9AJLNEJFXaJN
BFNJZx1Dakk7f0OnIbqLL41GVqEq3XciQQZC8wJ9dvEoGtECC5K6UJ7azaRd
dAUK3JpcCT8hORikfwTwu7AEm1VA30AH4NW1qwTt6jFpK0O4oYpoH+48c6ZN
i6gpOst7uO6e2nqgPJo4CXOlJ1MUcapIZ3Panq08tX8ejqBe6IuCJkoB11wo
R/9wsyXWVk2JgH7P24oDmHjz4e3+ni8TS+guPrzt8Wh5BbhsSvvkuwO8+yFk
wy4V+TI6k+LrUHz6/TwsAPyfP4vf4/OViD3lt4cFzDFiT3jtIeEzRS5iz3gS
fBq0bKGR2CDSjnWGxJ7KnC8B63YHg/X17UF/fWtnc2N7exOpu8zKvKnB6817
DPr6hmzhV94OXvcapX4qRYH49zZxxmtPRqvRfo93Twk9veZfGhQlqv7fKavk
t3kOXp7/e82Niy7qkZ+pyuTeebH7nP7zDO7FzyuPajh5aPXFyzH2RLSGjP6Z
jP2pbPWN0kKMBxGKvlmI0sCdLnmxRU71axyj0O/qXJexWIwI7VYpeecezKg2
ubKKEnep+x5TY9oAx8ir6gi9bmjI6CFUI5/t91p/98qhx51nTXD5+PxDTzDf
5uJq7f0WipuThP2uulGtME3Fx/LKVLCEqxVupIqB2uxk+G5IlQZHVOUHpoWx
uB2O3UyaYRQn66PCXaKKFAaO+tKo2rpJiFgRy48qRfG3Mxr+nmfb8aah+8lD
voKFKbu3OGb3Fufs3tyITt9MujHdTYOz2F8BM1kexub2u0T4yqhrN3TaiWlo
+EPt89MQx9TSqccW1YvZ26oyVddeBlb+g4gQXI/5teKXxAHSQDHFHKdeYsoE
VkBSrZhqGdRWyYzIkF85RocwtOpq0TZkcFTcIBItZPgKEL57jGR6iWKcXhbm
OlfZhXIfHh/Z3gWMm4NUthcVxvXMh8fs/1HppzSMFQAA

-->

</rfc>
