<?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.39 (Ruby 3.2.2) -->
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-bormann-cbor-rfc-cddl-models-02" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.0 -->
  <front>
    <title>CDDL models for some existing RFCs</title>
    <seriesInfo name="Internet-Draft" value="draft-bormann-cbor-rfc-cddl-models-02"/>
    <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="August" day="27"/>
    <keyword>CDDL models</keyword>
    <abstract>
      <?line 45?>

<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>
    <?line 55?>

<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="rfc-9457">
        <name>RFC 9457</name>
        <t><xref target="RFC9457"/> defines a simple data model
that is reproduced in CDDL here:</t>
        <sourcecode type="cddl"><![CDATA[
problem-object = {
  ? type: preferably-absolute-uri
  ? title: text
  ? status: 100..599
  ? detail: text
  ? instance: preferably-absolute-uri
  * text .feature "problem-object-extension" => any
}

; RECOMMENDED: absolute URI or at least absolute path:
preferably-absolute-uri = ~uri
]]></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"/> or <xref target="RFC9457"/> 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..0x7fffffffffffffff); uint63 as text string
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"/>
            <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"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <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"/>
            <author fullname="C. Vigano" initials="C." surname="Vigano"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <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"/>
            <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="9" month="March" 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), operations on text, and deterministic encoding.


   // Revision -01 of this draft reflects comments from initial
   // discussion of the specification in the CBOR working group.  It is
   // intended to be ready for working group adoption.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-bormann-cbor-cddl-more-control-01"/>
        </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"/>
            <author fullname="E. Wilde" initials="E." surname="Wilde"/>
            <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"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <author fullname="M. Pritikin" initials="M." surname="Pritikin"/>
            <author fullname="T. Eckert" initials="T." surname="Eckert"/>
            <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="RFC9457">
          <front>
            <title>Problem Details for HTTP APIs</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <author fullname="E. Wilde" initials="E." surname="Wilde"/>
            <author fullname="S. Dalal" initials="S." surname="Dalal"/>
            <date month="July" 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.</t>
              <t>This document obsoletes RFC 7807.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9457"/>
          <seriesInfo name="DOI" value="10.17487/RFC9457"/>
        </reference>
        <reference anchor="RFC9290">
          <front>
            <title>Concise Problem Details for Constrained Application Protocol (CoAP) APIs</title>
            <author fullname="T. Fossati" initials="T." surname="Fossati"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <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"/>
            <author fullname="M. Kucherawy" initials="M." surname="Kucherawy"/>
            <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="1" month="March" year="2023"/>
            <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 (-20) is intended to address all IESG
   // feedback.  It has significantly progressed from -16, which was the
   // original submission to the IESG.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-sid-20"/>
        </reference>
      </references>
    </references>
    <?line 223?>

<section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>TBD</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA41Y/VLcOBL/X0+hcq4qkIyGYSAEnAA3fOwuV7ckR9irurDU
lsbWMFo8lmPLwIQlT3Nvci92v5Zk4wHCLlubkeVWd6s/ft1tIQS7ivkaY1bb
TMV8h3G+f3DwTz4zqcoqPjElr8xMcXWjK6vzC37yw37FXnA5HpcKR/f3Ppzw
vJ6NVVmx1CS5nIFNWsqJFWNTzmSeiwQLUU4SkaRpJjxnMRiyVFrQDgfDNTHY
FMO37FLNr02Zxl0VWCJtzHU+MayypZKzmB8dnv7AWKFjfmZN0oOCJd5MKqzm
M79IzKyQiXWLmcptdc6YrO3UlDFuKPA/B88Kkvp8z6vp9rz6+7KsrMoX3pjy
Iua/5PoKF9X2f/+1fK9UYM1PPx85AtJOQdWPprITmUz52tpgfX3g3iXazuNw
wG/gbjE/EMPNtTdbYafObQmqHxUJnbvNYmpy0L1e3xLrw1UxXN0UG2tbw1X3
Us2kzmKeyLH5u/2q+9CQsZxUttCS7vnp9GBrEDtiEfPfK+OFb8fkxc2hk0w0
6y0NuapLs7VONLTaWB3gNRzon7dWN97g2UBnk5E+R+Kgv+Dw4OxSiUDVkg8Z
ubOjJ/i93Ry8jXlRmnGmZsJkaRC7trERKLbW33QoxroK20N/ReIxeLsa81IV
tXU3/c/o+Efx6eggdsppZSdQBfpUOmVMCIEghtMQJoyNQgxzM3EhjXd5yv/x
6cOxGMtKpSQXsWaQElN5pfhYwfOpmugc78YKt1HMBe21rBAJOCzLVH/FSyTQ
tUYgz3kNPn3GTqcaJIhE69MECkOrtPJ55pg4xtpqk4cMrBFOrQY9dj3V2EDE
ZCQ8oXOFBD8oL3mmx6Us5+4mD5nJK4SMhAGJLYNCSAJHNST2iaqQSlUfzrQg
SPC+4sYTEOGSzGYI7mVe1ONMV1OVMkpFBwl9b9GZhtcVY0fk6LROSCwPf7cv
NO3ese3OH2NLHzMFE/NKqdYh/WU2SlOSeXvrounujlYUwXd3jPYgxu81Ibjw
NAQVQOpJYz6+hce04BjldcYS2qo8xWtrvNORi3DFuCEhZooS3YuRVjIHWTCl
qoA5OEkkMl8Azz4bwQ8UIyXgSVuSNMmU08PUFsFip9xOgSXe7cQ3QCFs/OIF
8eAU6Qx2GBUFVNQ3/Cdyd0hTWILMIIFv3F6bp61wexsS5u6uiSdZKp4bi8OF
hjJTVao+O50XOpFZNu9BKdXgKrGY8esQgC6yyVmyKDJQeyl1RTfGIdZozH3S
v+OQhxAkfuom2NgxnOmLqQ0MJ3UGw7MEapRzASUu+URJW5cUk5PWCuQlAxsb
cCvbHLm3FAEIWSpgCWzjs5Z8cG9a7yge/dvUJJCPSquB4Tbq8ZBr8OJYMWBL
69uQOVxWMWPfvn3z4HjlOQgZOPBtfgsoihz6hJdx+I1i9w7Yj7oGlsLkMZ/L
/OJvVBkFQERYPVOOZJcvsSaR1E2hocZz5P5IJisrSpWra5kJX22foV9ZaZe5
yRPlKwaQNgecvB/PLYzWrwBqfGmz318bLu8E+mX3K6tKleT6+H7pC6MqNeR7
gI25hc/DlYCLVzoVuqpqevNInBdQ6BwoK1KDeofaAs7fJd3lHSrc/Mr4aBQw
d3KJcj82hgrYHQM+tFrCRxHKup4g7CO+wqPMXFyEJSLqRs9QviPGHtsOJ+k6
vF+qC3gFYWLX3kdnA7F1frt+J/xieL84jXqtjZ/6ixrC+NFi6ax/7tavl3f/
jMvS5z/OXovzRzyWox3GnI6j3l5vfwfqL414Hzt8b9n/7jPWte3pTnvF8cZ6
wk8p0tlt7Bql7QhNHWVVn0I/uiMIVQ5y1I2cFQA1ShJKc8pEn0L8SmaabJg2
SAf8y7RF94kaZpNpXbAqKXVhQ1YBGLOMEcAIIOJKrbZX6n9tr/inl5EtaxW9
XKGfFf6Hy0He1YpfFWj3SOkGEaiPCIhAywVEqDSp3QEGZqfSQTRlPhW0TuIT
QHZTv21exr+rNvF3uZ0XivoWNVElSu9coMiZrEYU1aX2FL73DomxS7XB1gjW
1cGg33+zteU2U2Vdu9dSAd7RZyTP8n4VfBeQ04VzR0fh4LdCCkR8e4dT1wkn
vuMnh/sffv758PjgEL1Tw5L/cnJE3QzsQQXb3r+A36Yx+44WsMM3UuZh3JDt
27g5NpbqAVh3atpewHnq8OAlmVWm4yrXpVWFSpC2Sbf6OjYzOe/UEUJ3WwNF
MipJvvSh3wTTphKGSAjmCcam8A2B4lXYByxqtCofA9mBJ/PVpuk2fRZQpKEw
QYf7NoPKO650e9uQPluNWAQKPkGljCjk6EwvsESPlFcFOkgwlXTWMaRutY0K
6DRC4/Gl1kg4FKz7JiXIQExfoP3OH4UxumNBUhcqV7MZN4u2doFbnSnhByeH
kPSPALTnlhC1DMAc6IDJunJFolk9Jm1kCDdrEe3DnWfONMkT1XlreY/k7VNT
KpQHGiehU5VSRQGo8mTe0fbs1VP75+EISom+yGnQFHDNhXL0DzcbYm3VjAjo
97wpRsCX9yeHO9u+giyh8Tg57PFo+RUg2xT2yXe7ePenaA67lOTL6EyKryPx
+bfzsEBN+PVX8Vv//FXEnvLbw9rmGLEnvPaQ8Jn6F7FnPAk+Nbq50GOsE2nL
OkWez2TGl4CIg5u3k8W/5Xfu5MYaZYM7gDECqc6KrK4g4f1HYJO+IQv5lbeO
v1GF3mAmRY6s8JZyJm1ORivRTo+3TzE9veNfalQxahe+U4fJm10OXp7/e8eN
izlqqp8p4+T0rtgdTv95Bvfiu8oTDD/0xeLlGHsihkOe/5U8/ks57DurhcgP
IhR94BCFgatcSmOLXO3XOEYJ0ZbNNo+xGBMGrlBKdx4MFRllFaXzUvvxpsJ4
Ao6RV9URet3QwdFDqIQeA+61/u6VQ1PcZU0g+vj8Q08w3xfjas39Fiqgk4T9
tgRSBTF1ySfyypSwhKsgbgbrA8vZ0eh4RPUHR1Bk3YS1MEc307QbYlPM7mR9
lMFL1JbcwFFfalVZNzoRK2L5SSUozHZO0+LzbFveNKU/ecjXtTCW9xbn8t7i
YN7rzPT0kaWd6934OO/7K2CIy8Kc3XzICJ8kdeWmVDs1NU2LqIh+fOIYc1r1
2KJ6fXZYlqZs+9HAyn9BEYLrCb9W/JI4QBooZhj81EuMpcAKSKoUUw2DyiqZ
EhnyK8OsEaZcXS7ahgyOOhxE6oqFzwbhQ8lYJpco0cllbq4zlV4o95Xyke1d
wLjBSaXbUW5ck713wP4PvjfasrkVAAA=

-->

</rfc>
