<?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.5.17 -->
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-kiesewalter-asdf-yang-sdf-01" category="info" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.11.1 -->
  <front>
    <title abbrev="Mapping between YANG and SDF">Mapping between YANG and SDF</title>
    <seriesInfo name="Internet-Draft" value="draft-kiesewalter-asdf-yang-sdf-01"/>
    <author initials="J." surname="Kiesewalter" fullname="Jana Kiesewalter">
      <organization>Universität Bremen</organization>
      <address>
        <email>jankie@uni-bremen.de</email>
      </address>
    </author>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann" role="editor">
      <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="2021" month="November" day="07"/>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <!-- (briefly explain what we are trying to do, e.g.:) -->

<t>YANG and SDF are two languages for modelling the interaction with and
the data interchanged with devices in the network.
As their areas of application (network management, IoT, resp.)
overlap, it is useful to be able to translate between the two.</t>
      <t>The present specification provides information about how models in one
of the two languages can be translated into the other.
This specification is not intended to be normative, but to help with
creating translators.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>YANG <xref target="RFC7950" format="default"/> and SDF <xref target="I-D.ietf-asdf-sdf" format="default"/> are two languages for modelling the interaction with and
the data interchanged with devices in the network.
As their areas of application (network management, IoT, resp.)
overlap, it is useful to be able to translate between the two.</t>
      <t>The present specification provides information about how models in one
of the two languages can be translated into the other.
This specification is not intended to be normative, but to help with
creating translators.</t>
    </section>
    <section anchor="pairing-sdf-and-yang-features" numbered="true" toc="default">
      <name>Pairing SDF and YANG features</name>
      <t><xref target="yang-to-sdf" format="default"/> gives an overview over how language features of YANG
can be mapped to SDF features. In many cases, several translations
are possible, and the right choice depends on the context. The mappings
in this draft often accommodate the use of the YANG parser Libyang
<xref target="LIBYANG" format="default"/>.</t>
      <t>For YANG statements that are not mentioned in the table no conversion to SDF
was found that preserves the statement's semantics.</t>
      <t>For possible
conversions of YANG's built-in types please refer to <xref target="yangtosdf" format="default"/>.
Please note that a 'type object' is not the same as an
sdfObject but refers to SDF's built-in type 'object', also called
compound-type. This built-in type makes use of the 'properties'
quality which is not to be confused with the sdfProperty class.
The data types number/decimal64, integer, boolean, string are also referred to
as simple (data) types. In turn, the types array and object are sometimes
referred to as complex (data) types. Concerning YANG, the expression
'schema tree' refers to the model's tree whereas 'data tree' describes
the tree of an instance of the model.</t>
      <table anchor="yang-to-sdf" align="center">
        <name>Mapping YANG to SDF</name>
        <thead>
          <tr>
            <th align="left">YANG statement</th>
            <th align="left">remark on YANG statement</th>
            <th align="left">converted to SDF</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">module</td>
            <td align="left"> </td>
            <td align="left">SDF model (i.e., info block, namespace section &amp; definitions)</td>
          </tr>
          <tr>
            <td align="left">submodule</td>
            <td align="left">included in supermodule</td>
            <td align="left">integrated into SDF model of supermodule</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">on its own</td>
            <td align="left">SDF model</td>
          </tr>
          <tr>
            <td align="left">container</td>
            <td align="left">top-level</td>
            <td align="left">sdfObject</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">one level below top-level</td>
            <td align="left">sdfProperty of type object (compound-type)</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">on any other level</td>
            <td align="left">property (type object) of the 'parent' definition of type object (compound-type)</td>
          </tr>
          <tr>
            <td align="left">leaf</td>
            <td align="left">on top-level and one level below</td>
            <td align="left">sdfProperty (type integer/number/boolean/string)</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">on any other level</td>
            <td align="left">property (type integer/number/boolean/string) of the 'parent' definition of type object (compound-type)</td>
          </tr>
          <tr>
            <td align="left">leaflist</td>
            <td align="left">on top-level and one level below</td>
            <td align="left">sdfProperty of type array</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">on any other level</td>
            <td align="left">property (type array) of the 'parent' definition of type object (compound-type)</td>
          </tr>
          <tr>
            <td align="left">list</td>
            <td align="left">on top-level and one level below</td>
            <td align="left">sdfProperty of type array with items of type object (compound-type)</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">on any other level</td>
            <td align="left">property (type array with items of type object (compound-type)) of the 'parent' definition of type object* (compound-type)</td>
          </tr>
          <tr>
            <td align="left">choice</td>
            <td align="left"> </td>
            <td align="left">sdfChoice</td>
          </tr>
          <tr>
            <td align="left">case</td>
            <td align="left">belonging to choice</td>
            <td align="left">element of the sdfChoice</td>
          </tr>
          <tr>
            <td align="left">grouping</td>
            <td align="left"> </td>
            <td align="left">sdfData of compound-type (type object) at the top level which can then be referenced</td>
          </tr>
          <tr>
            <td align="left">uses</td>
            <td align="left">referencing a grouping</td>
            <td align="left">sdfRef to the SDF definition corresponding to the referenced grouping</td>
          </tr>
          <tr>
            <td align="left">rpc</td>
            <td align="left"> </td>
            <td align="left">sdfAction at the top-level of the SDF model</td>
          </tr>
          <tr>
            <td align="left">action</td>
            <td align="left"> </td>
            <td align="left">sdfAction of the sdfObject corresponding to a container the action is a descendant node to</td>
          </tr>
          <tr>
            <td align="left">notification</td>
            <td align="left"> </td>
            <td align="left">sdfEvent</td>
          </tr>
          <tr>
            <td align="left">anydata</td>
            <td align="left"> </td>
            <td align="left">not converted</td>
          </tr>
          <tr>
            <td align="left">anyxml</td>
            <td align="left"> </td>
            <td align="left">not converted</td>
          </tr>
          <tr>
            <td align="left">augment</td>
            <td align="left"> </td>
            <td align="left">augment's target is converted with the augmentation already applied, mentioned in the description</td>
          </tr>
          <tr>
            <td align="left">type</td>
            <td align="left">referring to a built-in type</td>
            <td align="left">type with other data qualities (e.g., default) if necessary</td>
          </tr>
          <tr>
            <td align="left">type</td>
            <td align="left">referring to a typedef</td>
            <td align="left">sdfRef to the corresponding sdfData element</td>
          </tr>
          <tr>
            <td align="left">base</td>
            <td align="left"> </td>
            <td align="left">sdfRef to the sdfData definition corresponding to the base</td>
          </tr>
          <tr>
            <td align="left">bit</td>
            <td align="left"> </td>
            <td align="left">'parent' definition is of compound-type and gets one entry in the properties quality of type boolean for each bit</td>
          </tr>
          <tr>
            <td align="left">enum</td>
            <td align="left"> </td>
            <td align="left">each enum statement's argument is added as an element to the SDF enum quality's string array</td>
          </tr>
          <tr>
            <td align="left">fraction-digits</td>
            <td align="left"> </td>
            <td align="left">multipleOf quality</td>
          </tr>
          <tr>
            <td align="left">length</td>
            <td align="left">single length range</td>
            <td align="left">minLength/maxLength qualities</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">single value</td>
            <td align="left">minLength and maxLength qualities set to the same value</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">contains alternatives</td>
            <td align="left">sdfChoice with alternatives for minLength/maxLength qualities</td>
          </tr>
          <tr>
            <td align="left">path</td>
            <td align="left"> </td>
            <td align="left">sdfRef to the corresponding SDF definition</td>
          </tr>
          <tr>
            <td align="left">pattern</td>
            <td align="left">single pattern</td>
            <td align="left">pattern quality</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">multiple patterns</td>
            <td align="left">pattern quality, the regular expressions are combined using positive lookahead</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">invert-match</td>
            <td align="left">pattern quality, the regular expression is modified using negative lookahead</td>
          </tr>
          <tr>
            <td align="left">range</td>
            <td align="left">single range</td>
            <td align="left">minimum/maximum qualities</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">single value (constant)</td>
            <td align="left">const quality</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">contains alternatives</td>
            <td align="left">sdfChoice with either minimum/maximum or const quality as alternatives</td>
          </tr>
          <tr>
            <td align="left">typedef</td>
            <td align="left"> </td>
            <td align="left">sdfData definition, sdfRef where it is used</td>
          </tr>
          <tr>
            <td align="left">identity</td>
            <td align="left"> </td>
            <td align="left">sdfData definition, sdfRef where it is used</td>
          </tr>
          <tr>
            <td align="left">config</td>
            <td align="left">of a container that became an sdfObject</td>
            <td align="left">set writable for all elements in the sdfObject that can be marked as writable (i.e., that use the data qualities)</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">of any other YANG element</td>
            <td align="left">set writable</td>
          </tr>
          <tr>
            <td align="left">import</td>
            <td align="left"> </td>
            <td align="left">the module that the import references is converted (elements can now be referenced by sdfRef) and its prefix and namespace are added the to namespace section</td>
          </tr>
          <tr>
            <td align="left">revisions</td>
            <td align="left"> </td>
            <td align="left">first revision date becomes version in information block</td>
          </tr>
          <tr>
            <td align="left">namespace</td>
            <td align="left"> </td>
            <td align="left">added to namespace section</td>
          </tr>
          <tr>
            <td align="left">prefix</td>
            <td align="left"> </td>
            <td align="left">added to namespace section</td>
          </tr>
        </tbody>
      </table>
      <t><xref target="sdf-to-yang" format="default"/> provides the inverse mapping.</t>
      <table anchor="sdf-to-yang" align="center">
        <name>Mapping SDF to YANG</name>
        <thead>
          <tr>
            <th align="left">SDF quality</th>
            <th align="left">remark on SDF quality</th>
            <th align="left">converted to YANG</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">sdfThing</td>
            <td align="left"> </td>
            <td align="left">container node</td>
          </tr>
          <tr>
            <td align="left">sdfObject</td>
            <td align="left"> </td>
            <td align="left">container node</td>
          </tr>
          <tr>
            <td align="left">sdfProperty</td>
            <td align="left">type integer/number/boolean/string</td>
            <td align="left">leaf node</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">type array with items of type integer/number/boolean/string</td>
            <td align="left">leaf-list node</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">type array with items of type object (compound-type)</td>
            <td align="left">list node</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">type object (compound-type)</td>
            <td align="left">container node</td>
          </tr>
          <tr>
            <td align="left">sdfAction</td>
            <td align="left">at the top-level, <strong>not</strong> part of an sdfObject</td>
            <td align="left">rpc node</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">inside of an sdfObject</td>
            <td align="left">action node as child node to the container corresponding to the sdfObject</td>
          </tr>
          <tr>
            <td align="left">sdfEvent</td>
            <td align="left"> </td>
            <td align="left">notification node with child nodes that were translated like sdfProperty</td>
          </tr>
          <tr>
            <td align="left">sdfData</td>
            <td align="left">type integer/number/boolean/string</td>
            <td align="left">typedef</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">type array with items of type integer/number/boolean/string</td>
            <td align="left">grouping node with leaf-list child node</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">type array with items of type object (compound-type)</td>
            <td align="left">grouping node with list child node</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">type object (compound-type)</td>
            <td align="left">grouping node</td>
          </tr>
          <tr>
            <td align="left">sdfRef</td>
            <td align="left">referenced definition was converted to typedef</td>
            <td align="left">type is set to the typedef corresponding to the sdfData definition</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">referenced definition was converted to leaf or leaf-list node</td>
            <td align="left">leafref</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">referenced definition was converted to grouping node</td>
            <td align="left">"<tt>uses</tt>" node that references corresponding grouping (and refine if necessary)</td>
          </tr>
          <tr>
            <td align="left">sdfRequired</td>
            <td align="left">referenced definition was converted to a leaf or choice node</td>
            <td align="left">set the mandatory statement of the corresponding leaf/choice node to true</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left"> </td>
            <td align="left">find the first descendant node that is either a leaf/choice node and set their mandatory statement to true or that is a leaf-list/list node and set their min-elements statement to 1 (if not already &gt;= 0)</td>
          </tr>
          <tr>
            <td align="left">sdfChoice</td>
            <td align="left"> </td>
            <td align="left">choice node with one case node for each alternative of the sdfChoice, each alternative is converted like sdfProperty</td>
          </tr>
          <tr>
            <td align="left">type</td>
            <td align="left"> </td>
            <td align="left"> </td>
          </tr>
          <tr>
            <td align="left">const</td>
            <td align="left">corresponding YANG element has empty range</td>
            <td align="left">range statement with a single value</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">range not empty</td>
            <td align="left">add single value alternative to range statement (must be disjunct)</td>
          </tr>
          <tr>
            <td align="left">default</td>
            <td align="left">type is one of integer/number/boolean/string or array with items of these types</td>
            <td align="left">default statement of leaf/leaf-list nodes</td>
          </tr>
          <tr>
            <td align="left">minimum/maximum</td>
            <td align="left">corresponding YANG element has empty range</td>
            <td align="left">range statement</td>
          </tr>
          <tr>
            <td align="left"> </td>
            <td align="left">range not empty</td>
            <td align="left">add range alternative to range statement (must be disjunct)</td>
          </tr>
          <tr>
            <td align="left">multipleOf</td>
            <td align="left"> </td>
            <td align="left">fraction-digits statement</td>
          </tr>
          <tr>
            <td align="left">minLength/maxLength</td>
            <td align="left"> </td>
            <td align="left">length statement</td>
          </tr>
          <tr>
            <td align="left">pattern</td>
            <td align="left"> </td>
            <td align="left">pattern statement</td>
          </tr>
          <tr>
            <td align="left">minItems/maxItems</td>
            <td align="left"> </td>
            <td align="left">min-elements/max-elements statements</td>
          </tr>
          <tr>
            <td align="left">uniqueItems set to true</td>
            <td align="left">if the 'parent' SDF definition is converted to a list node</td>
            <td align="left">unique statement mentioning all of the leaf/leaf-list nodes in the list node's sub-tree</td>
          </tr>
          <tr>
            <td align="left">items</td>
            <td align="left"> </td>
            <td align="left">sub-statements of list/leaf-list node corresponding to the item quality's 'parent' definition</td>
          </tr>
          <tr>
            <td align="left">properties</td>
            <td align="left"> </td>
            <td align="left">child nodes of container/grouping node corresponding to the properties quality's 'parent' definition</td>
          </tr>
          <tr>
            <td align="left">unit</td>
            <td align="left"> </td>
            <td align="left">units statement</td>
          </tr>
          <tr>
            <td align="left">enum</td>
            <td align="left"> </td>
            <td align="left">type enumeration with enum statements for each string in the SDF enum quality</td>
          </tr>
          <tr>
            <td align="left">sdfType</td>
            <td align="left">has value 'byte-string'</td>
            <td align="left">built-in type 'binary'</td>
          </tr>
          <tr>
            <td align="left">writable</td>
            <td align="left"> </td>
            <td align="left">config statement</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="yangtosdf" numbered="true" toc="default">
      <name>Mapping from YANG to SDF</name>
      <t>This section specifies one possible mapping for each of the YANG statements to SDF in detail. For reference on the individual YANG statements see <xref target="RFC7950" format="default"/> and <xref target="I-D.ietf-asdf-sdf" format="default"/> for SDF. Examples have been included where they serve to assist the reader's understanding of the conversion.</t>
      <section anchor="design-module" numbered="true" toc="default">
        <name>Module</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.1" sectionFormat="bare" format="default">module</xref> of <xref target="RFC7950" format="default"/></li>
          <li>
            <t>SDF:
            </t>
            <ul spacing="normal">
              <li>Section <xref target="I-D.ietf-asdf-sdf" section="3.1" sectionFormat="bare" format="default">information block</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
              <li>Sections <xref target="I-D.ietf-asdf-sdf" section="3.2" sectionFormat="bare" format="default"/> and <xref target="I-D.ietf-asdf-sdf" section="4" sectionFormat="bare" format="default">namespaces section</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
            </ul>
          </li>
        </ul>
        <t>The <tt>module</tt> statement in YANG subsumes all other statements included in a module. After conversion the SDF model as a whole corresponds to the YANG module. The argument of the <tt>namespace</tt> statement of the YANG module is added to the SDF <tt>namespace</tt> quality together with the argument of the <tt>prefix</tt> statement of the YANG module which also becomes the entry of the <tt>defaultNamespace</tt> quality in the SDF model. Additionally, the namespaces and prefixes of each of the modules mentioned in the <tt>import</tt> statements are added to the <tt>namespace</tt> quality of the SDF model. Libyang loads the imported modules automatically and in the correct version. These modules are then also converted and stored so their definitions can be referenced via the <tt>sdfRef</tt> common quality when necessary. <xref target="lst-moduletosdf" format="default"/> and <xref target="lst-module" format="default"/> illustrate these mappings.</t>
        <t>The contents of the <tt>organization</tt>, <tt>contact</tt> and <tt>yang-version</tt> statements are stored alongside the description of the YANG module in a special <tt>sdfData</tt> definition designated to hold information on the module that does not fit into the SDF information block. This is done in with a conversion note to facilitate round trips in the future as described in <xref target="design-roundtrips" format="default"/>. To illustrate this conversion, <xref target="lst-moduletosdf" format="default"/> contains a converted model with an <tt>sdfData</tt> definition called <tt>ietf-foo-info</tt>. The original YANG module can be found in <xref target="lst-module" format="default"/>. The description of the module is scanned for information regarding copyright and licensing which are then transferred to the <tt>copyright</tt> and <tt>license</tt> qualities of the information block in the SDF model. The <tt>version</tt> quality of the information block is set to the first revision date given in the YANG <tt>revision</tt> statement. All other revision dates are ignored as of now.</t>
        <t>YANG modules can define features via the <tt>feature</tt> statement to make parts of the module conditional. The abilities of a server are checked against the features stated in the module. Nodes reference features as an argument to the <tt>if-feature</tt> statement. If a server does not support a certain feature, nodes that reference that feature are ignored by the server. Since this functionality cannot be represented in SDF yet, YANG features are stored in the description of the <tt>sdfData</tt> definition designated to hold information on the module. The conversion note that is added to the descriptions looks as described in <xref target="design-roundtrips" format="default"/>.</t>
        <t>If the <tt>deviation</tt> statement (introducing a deviation from the original YANG module) is present in the YANG module, Libyang applies the deviation directly and the converter converts the module that way. The presence of the deviation in the original YANG module is not indicated in the resulting SDF model as of now which might cause inconsistencies after round trips. This is not believed to be of great importance because deviations are supposed to only occur in unpublished modules.</t>
        <figure anchor="lst-module">
          <name>Example YANG module</name>
          <sourcecode type="yang"><![CDATA[
    module ietf-foo {
        namespace "urn:ietf:params:xml:ns:yang:ietf-foo";
        prefix "foo";
        organization "Foo Inc.";
        contact "foo@mail.com";
        description
            "This is an example module

             Copyright Foo Inc.

             License XY";
        revision 2016-03-20;
        feature bar;
        feature baz;

        // ... more statements
    }
]]></sourcecode>
        </figure>
        <figure anchor="lst-moduletosdf">
          <name>SDF conversion of YANG module from the last figure</name>
          <sourcecode type="json"><![CDATA[
    {
        "defaultNamespace": "foo",
        "info": {
            "copyright": "Copyright Foo Inc.",
            "license": "License XY",
            "title": "ietf-foo",
            "version": "2016-03-20"
        },
        "namespace": { "foo": "urn:ietf:params:xml:ns:yang:ietf-foo" },
        "sdfData": {
            "ietf-foo-info": {
                "description": "This is an example module\n\nCopyright Foo Inc.\n\nLicense XY\n!Conversion note: revision 2016-03-20!\n\n!Conversion note: organization Foo Inc.!\n\n!Conversion note: contact foo@mail.com!\n!Conversion note: feature bar!\n\n!Conversion note: feature baz!\n"
            }
        }
    }
]]></sourcecode>
        </figure>
      </section>
      <section anchor="submodule" numbered="true" toc="default">
        <name>Submodule</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.2" sectionFormat="bare" format="default">submodule</xref> of <xref target="RFC7950" format="default"/></li>
        </ul>
        <t>If a complex YANG module is composed of several components, the single components can be represented via the <tt>submodule</tt> statement. For conversion, the nodes of a submodule that is included into its super-module with the <tt>include</tt> statement are integrated into the super-module and converted that way. This is due to the way Libyang represents included submodules. Submodules on their own cannot be converted since Libyang does not parse files that solely contain a submodule.</t>
      </section>
      <section anchor="container-statement" numbered="true" toc="default">
        <name>Container Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.5" sectionFormat="bare" format="default">container</xref> of <xref target="RFC7950" format="default"/></li>
          <li>
            <t>SDF:
            </t>
            <ul spacing="normal">
              <li>Sections <xref target="I-D.ietf-asdf-sdf" section="2.2.1" sectionFormat="bare" format="default"/> and <xref target="I-D.ietf-asdf-sdf" section="5.1" sectionFormat="bare" format="default">sdfObject</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
              <li>Sections <xref target="I-D.ietf-asdf-sdf" section="2.2.6" sectionFormat="bare" format="default"/> and <xref target="I-D.ietf-asdf-sdf" section="6.3" sectionFormat="bare" format="default">sdfThing</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
            </ul>
          </li>
        </ul>
        <t>YANG uses <tt>container</tt> nodes to group together other nodes. Containers on the top-level of a module are converted to <tt>sdfObject</tt> definitions. This is illustrated in the definition called <tt>level0</tt> in <xref target="lst-container" format="default"/> and <xref target="lst-containertosdf" format="default"/>. A container that is a direct child node to a top-level container is converted to a compound-type <tt>sdfProperty</tt> definition inside an sdfObject, as illustrated in the definition called <tt>level1</tt> in <xref target="lst-container" format="default"/> and <xref target="lst-containertosdf" format="default"/>. Any other container becomes an entry to the <tt>properties</tt> quality of the compound-type definition corresponding to the parent node of the container. An example of this mapping can be found in <xref target="lst-container" format="default"/> and <xref target="lst-containertosdf" format="default"/> in the definition called <tt>level2</tt>.</t>
        <t>Since the first SDF Internet-Draft did not contain the compound-type as a possible argument to the <tt>type</tt> quality, containers used to be translated to <tt>sdfThing</tt> definitions. This, was not a very suitable conversion semantically, however. At that time, sdfThings were the only elements that could contain elements of the same class, that is sdfThings could contain other sdfThings. This ability is required to represent the tree structure of YANG where, for example, containers can contain other containers. In the second SDF Internet-Draft the compound-type was introduced. This feature effectively makes it possible for elements of the <tt>sdfData</tt> and <tt>sdfProperty</tt> classes to contain elements that share the same qualities.</t>
        <t>A sub-statement to the <tt>container</tt> statement that cannot be represented in SDF as of now is the optional <tt>presence</tt> statement. The argument of the <tt>presence</tt> statement assigns a meaning to the presence or absence of a <tt>container</tt> node in an instance of the module. This concept is expressed in the description of the SDF definition in question as shown in <xref target="design-roundtrips" format="default"/>. This is also illustrated in the definition <tt>level2</tt> in <xref target="lst-container" format="default"/> and <xref target="lst-containertosdf" format="default"/>.</t>
        <figure anchor="lst-container">
          <name>YANG module with multiple nested container statements</name>
          <sourcecode type="yang"><![CDATA[
    module container-example {
        // [...]
        container level0 {
            container level1 {
                container level2 {
                    presence "Enables SSH";
                    // [...]
                }
            }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="lst-containertosdf">
          <name>SDF conversion of the YANG module from the last figure</name>
          <sourcecode type="json"><![CDATA[
    {
        ; [...]
        "sdfObject": {
            "level0": {
                "sdfProperty": {
                    "level1": {
                        "properties": {
                            "level2": {
                                "properties": {
                                    "description": "!Conversion note: presence Enables SSH!\n",
                                    ; [...]
                                },
                                "type": "object"
                            }
                        },
                        "type": "object"
                    }
                }
            }
        }
    }
]]></sourcecode>
        </figure>
      </section>
      <section anchor="design-leaf" numbered="true" toc="default">
        <name>Leaf Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.6" sectionFormat="bare" format="default">leaf</xref> of <xref target="RFC7950" format="default"/></li>
          <li>
            <t>SDF:
            </t>
            <ul spacing="normal">
              <li>Sections <xref target="I-D.ietf-asdf-sdf" section="2.2.2" sectionFormat="bare" format="default"/> and <xref target="I-D.ietf-asdf-sdf" section="5.2" sectionFormat="bare" format="default">sdfProperty</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
              <li>Section <xref target="I-D.ietf-asdf-sdf" section="4.7" sectionFormat="bare" format="default">data qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
            </ul>
          </li>
        </ul>
        <t><tt>Leaf</tt> nodes in YANG represent scalar variables. If a <tt>leaf</tt> statement occurs at the top-level of the module or as a direct child node of a top-level container (which is converted to sdfObject) it becomes an sdfProperty. On any other level a leaf is mapped to an entry of the <tt>properties</tt> quality of the compound-type definition corresponding to the parent node of the leaf. In both cases the SDF <tt>type</tt> quality is set to one of the simple data types because <tt>leaf</tt> nodes can only have simple data types. <tt>Leaf</tt> nodes can be assigned default values which are used in case the node does not exist in an instance of the YANG module. The default value of a leaf is converted to SDF through the quality <tt>default</tt>. The <tt>units</tt> sub-statement of a <tt>leaf</tt> node in YANG becomes the SDF quality <tt>unit</tt>. An example of such a conversion can be found in the <tt>level0</tt> element in <xref target="fig-leaf" format="default"/> and <xref target="fig-leaftosdf" format="default"/>. The SDF quality <tt>unit</tt> is constrained to the SenML unit names. Although it could cause conformance issues, the content of the YANG <tt>units</tt> statement is not processed to fit the SenML unit names as of now. This is due to the low probability that a unit from a YANG module is not listed in the SenML unit names in comparison to the time required to implement a mechanism to check conformance and convert non-conforming units. This feature might be added in later versions of the converter. YANG <tt>leaf</tt> nodes can be marked as mandatory to occur in an instance of the module by the <tt>mandatory</tt> statement. The statement takes <tt>true</tt> and <tt>false</tt> as arguments. This can easily be mapped to SDF through the <tt>sdfRequired</tt> quality. A reference to the SDF equivalent of the mandatory YANG <tt>leaf</tt> node is added to the <tt>sdfRequired</tt> quality of the containing sdfObject. If a mandatory leaf is transformed to an entry in the <tt>properties</tt> quality of a compound-type definition in SDF, said entry is mentioned in the <tt>required</tt> quality. If the <tt>sdfRequired</tt> or <tt>required</tt> quality does not already exist it is added at this point. The latter is demonstrated in the <tt>level2</tt> element in <xref target="fig-leaf" format="default"/> and <xref target="fig-leaftosdf" format="default"/>.</t>
        <figure anchor="fig-leaf">
          <name>YANG module containing multiple leaf statements</name>
          <sourcecode type="yang"><![CDATA[
    module leaf-example {
        // [...]
        leaf level0 {
            type int32;
            units "kg";
            default 14;
        }
        container dummy0 {
            leaf level1 { type string; }
            container dummy1 {
                leaf level2 {
                    type string;
                    mandatory true;
                }
            }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-leaftosdf">
          <name>SDF conversion of the YANG module from the last figure</name>
          <sourcecode type="json"><![CDATA[
    {
        ; [...]
        "sdfObject": {
            "dummy0": {
                "sdfProperty": {
                    "dummy1": {
                        "properties": {
                            "level2": { "type": "string" }
                        },
                        "required": [ "level2" ],
                        "type": "object"
                    },
                    "level1": { "type": "string" }
                }
            }
        },
        "sdfProperty": {
            "level0": {
                "default": 14,
                ; [...]
                "type": "integer",
                "unit": "kg"
            }
        }
    }
]]></sourcecode>
        </figure>
      </section>
      <section anchor="sec-map-leaflist" numbered="true" toc="default">
        <name>Leaf-List Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.7" sectionFormat="bare" format="default">leaf-list</xref> of <xref target="RFC7950" format="default"/></li>
          <li>
            <t>SDF:
            </t>
            <ul spacing="normal">
              <li>Sections <xref target="I-D.ietf-asdf-sdf" section="2.2.2" sectionFormat="bare" format="default"/> and <xref target="I-D.ietf-asdf-sdf" section="5.2" sectionFormat="bare" format="default">sdfProperty</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
              <li>Section <xref target="I-D.ietf-asdf-sdf" section="4.7" sectionFormat="bare" format="default">data qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
            </ul>
          </li>
        </ul>
        <t>Similarly to <tt>leaf</tt> nodes, <tt>leaf-list</tt> nodes hold data of simple types in YANG but as items in an array. As such, leaf-lists are converted to sdfProperties if they occur on the top-level or one level below in a module. On any other level a leaf-list becomes an entry to the <tt>properties</tt> quality of the compound-type definition corresponding to the parent node of the leaf-list. In both cases the type is set to <tt>array</tt>. The items of the array are of simple data types since <tt>leaf-list</tt> nodes can only have simple data types as well. The minimal and maximal number of elements in a YANG leaf-list can be specified by the <tt>min-elements</tt> and <tt>max-elements</tt> sub-statements. This is analogue to the <tt>minItems</tt> and <tt>maxItems</tt> qualities of SDF which are set accordingly by the converter. A leaf-list can specify whether the system or the user is responsible for ordering the entries of the leaf-list. This information is stored in the <tt>ordered-by</tt> statement in YANG which is represented in SDF by a remark in the description (as shown in <xref target="design-roundtrips" format="default"/>) of the SDF equivalent to the <tt>leaf-list</tt> node in question.
Since <tt>leaf-list</tt> nodes are just <tt>leaf</tt> nodes that can occur multiple times, the <tt>units</tt> and <tt>default</tt> statements of <tt>leaf-list</tt> nodes are converted as described for <tt>leaf</tt> nodes in <xref target="design-leaf" format="default"/>.</t>
      </section>
      <section anchor="list-statement" numbered="true" toc="default">
        <name>List Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.8" sectionFormat="bare" format="default">list</xref> of <xref target="RFC7950" format="default"/></li>
          <li>
            <t>SDF:
            </t>
            <ul spacing="normal">
              <li>Sections <xref target="I-D.ietf-asdf-sdf" section="2.2.2" sectionFormat="bare" format="default"/> and <xref target="I-D.ietf-asdf-sdf" section="5.2" sectionFormat="bare" format="default">sdfProperty</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
              <li>Section <xref target="I-D.ietf-asdf-sdf" section="4.7" sectionFormat="bare" format="default">data qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
            </ul>
          </li>
        </ul>
        <t>The <tt>list</tt> statement of YANG is similar to the <tt>leaf-list</tt> statement. The only difference is that, opposed to leaf-lists, lists represent an assortment of <em>nodes</em> that can occur multiple times. Therefore, YANG lists are mapped to SDF similarly to leaf-lists. <tt>List</tt> nodes on the top-level or one level below become sdfProperties. On any other level a list is converted to an entry to the <tt>properties</tt> quality of the compound-type definition corresponding to the parent node of the list. The type is set to <tt>array</tt> for both alternatives. Since lists contain a set of nodes, the items of the corresponding array are of type <tt>object</tt>.  The minimal and maximal number of elements in a list can be specified by the <tt>min-elements</tt> and <tt>max-elements</tt> sub-statements. This is analogue to the <tt>minItems</tt> and <tt>maxItems</tt> qualities of SDF which are set accordingly by the converter. <tt>List</tt> nodes in YANG can define one or multiple keys leafs of the list via the <tt>key</tt> statement. There is no SDF quality that could represent this feature. To preserve the information the names of the list keys are stored in the description of the SDF definition in question as described in section <xref target="design-roundtrips" format="default"/>.
The <tt>unique</tt> sub-statement of the YANG list defines a number of descendant <tt>leaf</tt> nodes of the list that must have a unique combination of values in a module instance. This concept can be partly represented through the <tt>uniqueItems</tt> quality of SDF. However, the boolean-typed <tt>uniqueItems</tt> quality only specifies that the items of an SDF array have to be unique with <em>all</em> of their values combined. The YANG statement <tt>unique</tt> specifies a <em>selection</em> of <tt>leaf</tt> node values in the list that must be unique when combined. Thus, in addition to setting the <tt>uniqueItems</tt> quality of the SDF equivalent of the YANG list to true, a conversion note is added to the SDF equivalents of all leafs that are mentioned in the <tt>unique</tt> statement. This is done as shown in Section <xref target="design-roundtrips" format="default"/>. The <tt>ordered-by</tt> statement of a list is also preserved in a conversion note. An example conversion of a <tt>list</tt> node with the mentioned sub-statements to SDF can be found in <xref target="fig-list" format="default"/> and <xref target="fig-listtosdf" format="default"/>.</t>
        <figure anchor="fig-list">
          <name>YANG list node</name>
          <sourcecode type="yang"><![CDATA[
    list server {
        key "name";
        unique "ip";
        ordered-by user;
        min-elements 1;
        max-elements 100;
        leaf name { type string; }
        leaf ip { type string; }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-listtosdf">
          <name>SDF conversion of the YANG list node from the last figure</name>
          <sourcecode type="json"><![CDATA[
    "sdfProperty": {
        "server": {
            "description": "!Conversion note: key name!\n!Conversion note: ordered-by user!\n",
            "items": {
                "properties": {
                    "ip": {
                        "description": "!Conversion note: unique!\n",
                        "type": "string"
                    },
                    "name": { "type": "string" }
                },
                "type": "object"
            },
            "maxItems": 100.0,
            "minItems": 1.0,
            "type": "array",
            "uniqueItems": true
        }
    }
]]></sourcecode>
        </figure>
      </section>
      <section anchor="grouping-statement" numbered="true" toc="default">
        <name>Grouping Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.12" sectionFormat="bare" format="default">grouping</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="5.5" sectionFormat="bare" format="default">sdfData</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t><tt>Grouping</tt> nodes are very similar to <tt>container</tt> nodes with the difference that the set of nodes contained in a grouping does not occur in the data tree unless the grouping has been referenced at least once by a <tt>uses</tt> node. Thus, a <tt>grouping</tt> node is converted to a compound-type <tt>sdfData</tt> definition which defines a reusable definition that is not a declaration as well. The nodes inside the grouping are converted as entries to the <tt>properties</tt> quality in SDF. <xref target="fig-usesgrouping" format="default"/> and <xref target="fig-usesgroupingsdf" format="default"/> contain an example conversion of a grouping.</t>
      </section>
      <section anchor="uses-statement" numbered="true" toc="default">
        <name>Uses Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.13" sectionFormat="bare" format="default">uses</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.4" sectionFormat="bare" format="default">sdfRef</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>A <tt>uses</tt> node has the purpose of referencing a <tt>grouping</tt> node. The set of child nodes of the referenced grouping are copied to wherever the <tt>uses</tt> node is featured. Some of the sub-statements of the referenced grouping can be altered
via the <tt>refine</tt> statement of the <tt>uses</tt> node. In SDF a <tt>uses</tt> node is represented by the <tt>sdfRef</tt> quality which is added to the definition in question. As an argument the sdfRef contains a reference to the <tt>sdfData</tt> definition corresponding to the grouping referenced by the <tt>uses</tt> node. If the <tt>uses</tt> node contains a <tt>refine</tt> statement, the specified refinements are also applied in the target SDF definition. An example for such a conversion is illustrated in <xref target="fig-usesgrouping" format="default"/> and <xref target="fig-usesgroupingsdf" format="default"/>.</t>
        <figure anchor="fig-usesgrouping">
          <name>YANG module with uses and grouping statements</name>
          <sourcecode type="yang"><![CDATA[
    module restaurant {
        // [...]
        grouping dish {
            leaf name { type string; }
            leaf price { type int32; }
        }
        list menu {
            // [...]
            uses dish {
                refine name { mandatory true; }
            }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-usesgroupingsdf">
          <name>SDF conversion of the YANG module from the last figure</name>
          <sourcecode type="json"><![CDATA[
    {
        ; [...]
        "sdfData": {
            "dish": {
                "properties": {
                    "name": { "type": "string" },
                    "price": {
                        ; [...]
                        "type": "integer"
                    }
                },
                "type": "object"
            }
        },
        "sdfProperty": {
            "menu": {
                "items": {
                    "properties": {
                        "dish": {
                            "sdfRef": "#/sdfData/dish",
                            "required": [ "name" ],
                        }
                    }
                    "type": "object"
                },
                "type": "array"
            }
        }
    }
]]></sourcecode>
        </figure>
      </section>
      <section anchor="choice-statement" numbered="true" toc="default">
        <name>Choice Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.9" sectionFormat="bare" format="default">choice</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.7.2" sectionFormat="bare" format="default">sdfChoice</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>Conversion of the <tt>choice</tt> statement from YANG is simple since it is similar to the <tt>sdfChoice</tt> quality. The <tt>choice</tt> statement is used to define alternative sub-trees for the node the choice occurs in. Only one of the alternatives is present in the data tree. A YANG choice is converted to an sdfProperty if it occurs on top-level or one level below, like the <tt>snack</tt> definition in <xref target="fig-choice" format="default"/> and <xref target="fig-choicesdf" format="default"/>. On any other level a choice is mapped to an entry of the <tt>properties</tt> quality of the compound-type definition corresponding to the parent node of the choice. The <tt>food-level2</tt> definition in <xref target="fig-choice" format="default"/> and <xref target="fig-choicesdf" format="default"/> is an example of this kind of mapping. The SDF equivalent of the choice contains the <tt>sdfChoice</tt> quality.  <tt>Case</tt> or other child nodes of the choice are mapped to SDF as one of the named alternatives of the sdfChoice each. What cannot be represented is the <tt>default</tt> sub-statement of the YANG choice that defines which of the alternatives is considered the default one. This information is preserved in a conversion note as described in <xref target="design-roundtrips" format="default"/>.</t>
        <figure anchor="fig-choice">
          <name>YANG container using the choice statement</name>
          <sourcecode type="yang"><![CDATA[
    container food {
        container food-level2 {
            choice dinner {
                default home-cooked;
                case restaurant {
                    leaf steak { type boolean; }
                    leaf pizza { type boolean; }
                }
                case home-cooked {
                    leaf pasta { type boolean; }
                }
            }
        }
        choice snack {
            case sports-arena {
                leaf pretzel { type boolean; }
                leaf beer { type boolean; }
            }
            case late-night {
                leaf chocolate { type boolean; }
            }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-choicesdf">
          <name>SDF conversion of the YANG container from the last figure</name>
          <sourcecode type="json"><![CDATA[
    "sdfObject": {
        "food": {
            "sdfProperty": {
                "food-level2": {
                    "properties": {
                        "dinner": {
                            "description": "!Conversion note: default home-cooked!\n",
                            "sdfChoice": {
                                "home-cooked": {
                                    "properties": {
                                        "pasta": { "type": "boolean" }
                                    },
                                    "type": "object"
                                },
                                "restaurant": {
                                    "properties": {
                                        "pizza": { "type": "boolean" },
                                        "steak": { "type": "boolean" }
                                    },
                                    "type": "object"
                                }
                            }
                        }
                    },
                    "type": "object"
                },
                "snack": {
                    "description": "!Conversion note: default late-night!\n",
                    "sdfChoice": {
                        "late-night": {
                            "properties": {
                                "chocolate": { "type": "boolean" }
                            },
                            "type": "object"
                        },
                        "sports-arena": {
                            "properties": {
                                "beer": { "type": "boolean" },
                                "pretzel": { "type": "boolean" }
                            },
                            "type": "object"
                        }
                    }
                }
            }
        }
    }
]]></sourcecode>
        </figure>
      </section>
      <section anchor="rpc-statement" numbered="true" toc="default">
        <name>RPC Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.14" sectionFormat="bare" format="default">rpc</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Sections <xref target="I-D.ietf-asdf-sdf" section="2.2.3" sectionFormat="bare" format="default"/> and <xref target="I-D.ietf-asdf-sdf" section="5.3" sectionFormat="bare" format="default">sdfAction</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>Remote procedure calls (RPCs) can be modeled in YANG with <tt>rpc</tt> nodes which have up to one <tt>input</tt> child node holding the commands input data and up to one <tt>output</tt> node for the output data. In YANG RPCs can only occur on the top-level because in contrast to actions in YANG they do not belong to a container. This can easily be represented by sdfActions. The corresponding sdfAction is not placed inside an sdfObject or sdfThing but at the top-level of the SDF model to represent independence from a container. The input node of the RPC is converted to the <tt>sdfInputData</tt> quality of the sdfAction which is of type <tt>object</tt>. Equivalently, the <tt>output</tt> node of the RPC becomes the sdfOutputData of the sdfAction, which is also of type <tt>object</tt>. Groupings and typedefs in the RPC are converted to <tt>sdfData</tt> definitions inside the sdfAction.</t>
      </section>
      <section anchor="action-statement" numbered="true" toc="default">
        <name>Action Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.15" sectionFormat="bare" format="default">action</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Sections <xref target="I-D.ietf-asdf-sdf" section="2.2.3" sectionFormat="bare" format="default"/> and <xref target="I-D.ietf-asdf-sdf" section="5.3" sectionFormat="bare" format="default">sdfAction</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t><tt>Action</tt> nodes in YANG work similarly to <tt>rpc</tt> nodes in the way that they are used to model operations that can be invoked in the module and also have up to one <tt>input</tt> and <tt>output</tt> child node respectively. As mentioned before, YANG actions are affiliated to a container. The representation of this affiliation is not quite trivial because YANG containers are not translated to sdfObjects in all cases. Only sdfObjects can have sdfActions, however. If an action occurs in a container that is a below-top-level container (and thus not converted to sdfObject), as illustrated in <xref target="fig-action" format="default"/>, the affiliation cannot be represented directly in SDF as of now. <xref target="fig-actioninstance" format="default"/> shows how an XML instance of calling the action in <xref target="fig-action" format="default"/> and the reply would look like. As an input, the action specifies the container <tt>server</tt> it is affiliated to and its name. The actual action, <tt>reset</tt> and the value of its input, <tt>reset-at</tt> are specified inside the container instance. The result after converting the container from <xref target="fig-action" format="default"/> to SDF can be found in <xref target="fig-actionsdf" format="default"/>: To ensure equivalence of model instances a copy of the contents of the converted container is set as the sdfInputData of the sdfAction. The sdfInputData is of type <tt>object</tt>. The conversion of the actual action along with its input is added to the copy of the container conversion as another entry to its <tt>properties</tt> quality.
Furthermore, a conversion note is added as described in <xref target="design-roundtrips" format="default"/>. Equivalently, the <tt>output</tt> nodes of the action become the sdfOutputData of the sdfAction which is also of type <tt>object</tt>. Groupings and typedefs in the <tt>action</tt> node are converted to <tt>sdfData</tt> definitions inside the sdfAction.</t>
        <figure anchor="fig-action">
          <name>YANG container using the action statement</name>
          <sourcecode type="yang"><![CDATA[
    container example-container {}
        container server {
            leaf name { type string; }
            action reset {
                input {
                    leaf reset-at { type string; }
                }
                output {
                    leaf reset-finished-at { type string; }
                }
            }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-actioninstance">
          <name>XML instance of the action from the last figure</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <action xmlns="urn:ietf:params:xml:ns:yang:1">
            <server xmlns="urn:example:server-farm">
                <name>apache-1</name>
                <reset>
                    <reset-at>2014-07-29T13:42:00Z</reset-at>
                </reset>
            </server>
        </action>
    </rpc>

    <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <reset-finished-at xmlns="urn:example:server-farm">
            2014-07-29T13:42:12Z
        </reset-finished-at>
    </rpc-reply>
]]></artwork>
        </figure>
        <figure anchor="fig-actionsdf">
          <name>SDF conversion of the YANG container from Figure 13</name>
          <sourcecode type="json"><![CDATA[
    "sdfObject": {
        "example-container": {
          "sdfAction": {
            "reset": {
              "description": "Action connected to server\n\n",
              "sdfInputData": {
                "properties": {
                  "server": {
                    "properties": {
                      "name": { "type": "string"  },
                      "reset": {
                        "properties": {
                          "reset-at": { "type": "string" }
                        },
                        "type": "object"
                      }
                    },
                    "type": "object"
                  }
                },
                "required": [ "server" ],
                "type": "object"
              },
              "sdfOutputData": {
                "properties": {
                  "reset-finished-at": { "type": "string" }
                },
                "type": "object"
              }
            }
          },
          "sdfProperty": {
            "server": {
              "properties": {
                "name": { "type": "string" }
              },
              "type": "object"
            }
          }
        }
    }
]]></sourcecode>
        </figure>
      </section>
      <section anchor="notification-statement" numbered="true" toc="default">
        <name>Notification Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.16" sectionFormat="bare" format="default">notification</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Sections <xref target="I-D.ietf-asdf-sdf" section="2.2.4" sectionFormat="bare" format="default"/> and <xref target="I-D.ietf-asdf-sdf" section="5.4" sectionFormat="bare" format="default">sdfEvent</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>In YANG, <tt>notification</tt> nodes are used to model notification messages. <tt>Notification</tt> nodes are converted to <tt>sdfEvent</tt> definitions. Their child nodes are converted to the sdfOutputData of the sdfEvent which is of type <tt>object</tt>. Groupings and typedefs in the <tt>notification</tt> node are converted to <tt>sdfData</tt> definitions inside the sdfEvent.</t>
      </section>
      <section anchor="augment-statement" numbered="true" toc="default">
        <name>Augment Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.17" sectionFormat="bare" format="default">augment</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.6." sectionFormat="bare" format="default">common qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>The <tt>augment</tt> statement can either occur at the top-level of a module to add nodes to an existing target module or sub-module, or in a <tt>uses</tt> statement to augment the targeted and thus integrated grouping. The conversion of the <tt>augment</tt> statement to SDF is not trivial because SDF does not feature this mechanism.</t>
        <t>The tool used to deserialize YANG modules, Libyang, adds the nodes into the target of the <tt>augment</tt> statement automatically for targets that are modules or sub-modules. This is adopted in the mapping: The SDF model that corresponds to target of the the <tt>augment</tt> statement is converted with the augmentation already applied. A conversion note is added to the description as described in <xref target="design-roundtrips" format="default"/> to preserve where the augmentation was issued from. This mapping is illustrated in <xref target="fig-augmented" format="default"/>, <xref target="fig-augmenting" format="default"/> and <xref target="fig-augmentsdf" format="default"/>. If the resulting SDF model has to be converted back to YANG, definitions that are marked as augmentations are converted back accordingly. This way of mapping the <tt>augment</tt> statement to SDF causes problems if the augmentation target lies within a module whose converted version is already available and should not be replaced. Because, as of now, SDF does not offer means to extend already existing models retroactively these augmentations cannot be converted to SDF.</t>
        <t>When the target of the augment is a grouping the augmentation cannot be represented in SDF, either. The reason for this is that <tt>grouping</tt> nodes are converted to SDF definitions with the type <tt>object</tt>. The nodes inside the grouping are converted with the help of the <tt>properties</tt> quality. It is currently not possible to add properties to the <tt>properties</tt> quality, it can only be overridden as a whole.</t>
        <figure anchor="fig-augmented">
          <name>YANG module that serves as an augmentation target</name>
          <sourcecode type="yang"><![CDATA[
    module example-module {
        // [...]
        leaf leaf1 { type string; }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-augmenting">
          <name>YANG module using the augment statement on the module from the last figure</name>
          <sourcecode type="yang"><![CDATA[
    module augmenting-module {
        // [...]
        augment "/example" {
            leaf additional-leaf { type string; }
       }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-augmentsdf">
          <name>SDF conversion of the YANG module from Figure 16 after conversion of the YANG module from Figure 17</name>
          <sourcecode type="json"><![CDATA[
    {
        ; [...]
        "sdfProperty": {
            "leaf1": { "type": "string" },
            "additional-leaf": {
                "description": "!Conversion note: augmented-by augmenting-module!\n",
                "type": "string"
            }
        }
    }
]]></sourcecode>
        </figure>
      </section>
      <section anchor="anydata-and-anyxml-statements" numbered="true" toc="default">
        <name>Anydata and Anyxml Statements</name>
        <ul spacing="normal">
          <li>YANG: Sections <xref target="RFC7950" section="7.10" sectionFormat="bare" format="default"/> and <xref target="RFC7950" section="7.11" sectionFormat="bare" format="default">augment</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.6" sectionFormat="bare" format="default">common qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>The <tt>anydata</tt> and <tt>anyxml</tt> statements are designated for nodes in the schema tree whose structure is unknown at the design time of the module or in general. Since this is not a concept that can be represented in SDF as of now, <tt>anydata</tt> and <tt>anyxml</tt> nodes are not converted. Instead, to preserve the information a conversion note is added to the SDF element corresponding to the parent node of the <tt>anydata</tt> or <tt>anyxml</tt> node as described in <xref target="design-roundtrips" format="default"/>.</t>
      </section>
      <section anchor="type-statement" numbered="true" toc="default">
        <name>Type Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.4" sectionFormat="bare" format="default">type</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.7" sectionFormat="bare" format="default">data qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>The <tt>type</tt> statement of YANG is used to specify the built-in or derived type used by a <tt>leaf</tt> or <tt>typedef</tt> node. Mapping this statement to YANG is trivial if the argument is a simple data type because the SDF data qualities also contain a <tt>type</tt> quality. A derived type used as an argument to the YANG <tt>type</tt> statement is converted via the <tt>sdfRef</tt> quality. As an argument, the <tt>sdfRef</tt> quality contains a reference to the <tt>sdfData</tt> definition corresponding to the derived type. If the derived type is restricted, for example with the <tt>length</tt> statement, the restrictions are converted as they would be for the base type and added to the SDF definition containing the type in question.</t>
        <t>There are multiple sub-statements to the <tt>type</tt> statement that depend on its value. The conversion of those sub-statements is discussed in the section of the built-in type the sub-statement belongs to.</t>
      </section>
      <section anchor="design-string" numbered="true" toc="default">
        <name>String Built-In Type</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="9.4" sectionFormat="bare" format="default">string</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.7" sectionFormat="bare" format="default">data qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>The YANG built-in type <tt>string</tt> is converted to the SDF built-in type <tt>string</tt>. Strings in YANG can be restricted in length and by regular expressions.</t>
        <t>The <tt>length</tt> statement can specify either a constant length, a lower inclusive length, an upper inclusive length or both a lower and upper inclusive length. A <tt>length</tt> statement can also specify more than one disjoint constant length or length ranges. The values <tt>min</tt> and <tt>max</tt> in a <tt>length</tt> statement represent the minimum and maximum lengths accepted for strings. If the <tt>length</tt> statement in YANG does not contain a constant value but a length range it is converted to the <tt>minLength</tt> and <tt>maxLength</tt> SDF qualities. This is illustrated in <xref target="fig-string" format="default"/> and <xref target="fig-stringsdf" format="default"/>. If a constant value is defined through the YANG <tt>length</tt> statement the <tt>minLength</tt> and <tt>maxLength</tt> qualities are set to the same value. If the <tt>length</tt> statement specifies multiple length ranges or constant values the <tt>sdfChoice</tt> quality is used for conversion. The named alternatives of the sdfChoice contain the single converted length ranges or constant values each. If the <tt>min</tt> and <tt>max</tt> values are present in the YANG <tt>length</tt> statement they are converted to the respective minimum and maximum lengths accepted for strings.</t>
        <t>The YANG <tt>pattern</tt> statement can be used to hold regular expressions that the affiliated string has to match. To patterns from YANG in SDF the <tt>pattern</tt> quality can be used. One problem in the conversion of patterns is that YANG strings can be restricted by multiple patterns but SDF strings can have at most one pattern. To represent multiple patterns from YANG in SDF the patterns are combined into one regular expression with the help of positive look-ahead. <xref target="fig-string" format="default"/> contains an example leaf of type <tt>string</tt> with multiple defined patterns which is converted as shown in <xref target="fig-stringsdf" format="default"/>.
This does not always convey the meaning of the original regular expression. Another issue is the possibility to declare invert-match patterns in YANG. These types of patterns are converted to SDF by adding negative look-ahead to the regular expression, as illustrated in <xref target="fig-invertmatch" format="default"/> and <xref target="fig-invertmatchsdf" format="default"/>. To preserve the original patterns and to facilitate round trips, the original patterns are stored with a conversion note in the description of the containing definition as described in section <xref target="design-roundtrips" format="default"/>.</t>
        <figure anchor="fig-string">
          <name>YANG leaf node with type string, multiple pattern statements and a length statement</name>
          <sourcecode type="yang"><![CDATA[
    leaf example {
        type string {
            length "1..4";
            pattern "[0-9]*";
            pattern "[a-z]*";
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-stringsdf">
          <name>SDF conversion of the YANG leaf from the last figure</name>
          <sourcecode type="json"><![CDATA[
    "sdfProperty": {
        "example": {
            "description": "!Conversion note: pattern [0-9]*!\n!Conversion note: pattern [a-z]*!\n",
            "maxLength": 4.0,
            "minLength": 1.0,
            "pattern": "(?=[0-9]*)[a-z]*",
            "type": "string"
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-invertmatch">
          <name>YANG leaf definition with type string and an invert-match pattern</name>
          <sourcecode type="yang"><![CDATA[
    leaf example {
        type string {
            pattern "[0-9]*" { modifier invert-match; }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-invertmatchsdf">
          <name>SDF conversion of the YANG leaf from the last figure</name>
          <sourcecode type="json"><![CDATA[
    "sdfProperty": {
        "example": {
            "description": "!Conversion note: pattern [0-9]*!\n",
            "pattern": "((?!([0-9]*)).)*",
            "type": "string"
        }
    }
]]></sourcecode>
        </figure>
        <t>Another, more general problem regarding the conversion of regular expressions from YANG to SDF is the fact that YANG uses a regular expression language as defined by W3C Schema while SDF adopts ECMAscript regular expressions. Both regular expression languages share most of their features. Since this does not cause problems in most cases and regarding the time constraints of this thesis, this issue is not given any further attention beyond what was stated in this paragraph. There is, however, a project of the IETF Network Working Group to create an interoperable regular expression format. Once the work on the draft has progressed the format might be adopted by the SDF/YANG converter.</t>
      </section>
      <section anchor="design-dec64" numbered="true" toc="default">
        <name>Decimal64 Built-In Type</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="9.3" sectionFormat="bare" format="default">decimal64</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.7" sectionFormat="bare" format="default">data qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>The <tt>decimal64</tt> built-in type of YANG is converted to the <tt>number</tt> type in SDF. A <tt>decimal64</tt> type in YANG has a mandatory <tt>fraction-digits</tt> sub-statement that specifies the possible number of digits after the decimal separator. The value of the <tt>fraction-digits</tt> statement is converted to the <tt>multipleOf</tt> quality of SDF which states the resolution of a number, that is the size of the minimal distance between number values. <xref target="fig-dec64" format="default"/> and <xref target="fig-dec64sdf" format="default"/> contain examples for the conversion of the <tt>decimal64</tt> built-in type.</t>
        <t>A YANG <tt>decimal64</tt> type can be restricted by means of the <tt>range</tt> statement specifying either a constant value, a lower inclusive bound, an upper inclusive bound or both a lower and upper inclusive value. The <tt>range</tt> statement can also be used to specify multiple disjoint constant values or ranges. The <tt>min</tt> and <tt>max</tt> key words in a <tt>range</tt> statement represent the minimum and maximum values of the type in question. If the <tt>range</tt> statement in YANG contains a range and not a constant value it is converted to the <tt>minimum</tt> and <tt>maximum</tt> data qualities in SDF. This is illustrated in the definition called <tt>my-sensor-value</tt> in the example. If a constant value is defined through the YANG range the SDF <tt>const</tt> quality is set accordingly, as shown for the definition <tt>room-temperature</tt> in the example. If the range specifies multiple ranges or constant values the <tt>sdfChoice</tt> quality is used for conversion. The named alternatives of the sdfChoice contain the single converted ranges or constant values each. An example for this conversion can be found in the <tt>my-sensor-value3</tt> example definition. If the <tt>min</tt> and <tt>max</tt> values are present in the YANG range they are converted to the respective minimum and maximum values for the type in question, as shown for the <tt>max</tt> value in the example definition <tt>my-sensor-value2</tt>.</t>
        <figure anchor="fig-dec64">
          <name>YANG module using the decimal64 built-in type</name>
          <sourcecode type="yang"><![CDATA[
     module decimal64-example {
         // [...]
         leaf my-sensor-value {
            type decimal64 {
                fraction-digits 2;
                range "-50.0..150.0";
            }
        }
        leaf my-sensor-value2 {
            type decimal64 {
                fraction-digits 4;
                range "0..max";
            }
        }
        leaf my-sensor-value3 {
            type decimal64 {
                fraction-digits 6;
                range "0.0..1.0 | 5.0";
            }
        }
        leaf room-temperature {
            type decimal64 {
                fraction-digits 1;
                range "21.5";
            }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-dec64sdf">
          <name>SDF conversion of the YANG module from the last figure</name>
          <sourcecode type="json"><![CDATA[
    {
        ; [...]
        "sdfProperty": {
            "my-sensor-value": {
                "maximum": 150.0,
                "minimum": -50.0,
                "multipleOf": 0.01,
                "type": "number"
            },
            "my-sensor-value2": {
                "maximum": 3.3999999521443642e+38,
                "minimum": 0.0,
                "multipleOf": 0.0001,
                "type": "number"
            },
            "my-sensor-value3": {
                "sdfChoice": {
                    "range_option_1": {
                        "maximum": 0.0,
                        "minimum": 1.0,
                        "multipleOf": 0.000001,
                        "type": "number"
                    },
                    "range_option_2": {
                        "const": 5.0,
                        "multipleOf": 0.000001,
                        "type": "number"
                    }
                }
            },
            "room-temperature": {
                "const": 21.5,
                "multipleOf": 0.1,
                "type": "number"
            }
        }
    }
]]></sourcecode>
        </figure>
      </section>
      <section anchor="integer-built-in-types" numbered="true" toc="default">
        <name>Integer Built-In Types</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="9.2" sectionFormat="bare" format="default">integer</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.7" sectionFormat="bare" format="default">data qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>In YANG there are 8 different integer types: <tt>int8</tt>, <tt>uint8</tt>, <tt>int16</tt>, <tt>uint16</tt>, <tt>int32</tt>, <tt>uint32</tt>, <tt>int64</tt> and <tt>uint64</tt>. Each of them is converted to type <tt>integer</tt> in SDF. A conversion note specifying the exact type is added as described in <xref target="design-roundtrips" format="default"/>. Additionally, the <tt>minimum</tt> and <tt>maximum</tt> qualities of the SDF definition that the converted type belongs to are set to the respective minimum and maximum values of the <tt>integer</tt> type in question. If the YANG type also specifies a range, the minimum and maximum SDF qualities are altered accordingly. Like the <tt>decimal64</tt> YANG built-in type, the YANG integer types can also be restricted by a <tt>range</tt> statement. The integer <tt>range</tt> statement is converted as described in <xref target="design-dec64" format="default"/>.</t>
        <figure anchor="fig-int">
          <name>YANG leaf with the int32 built-in type</name>
          <sourcecode type="yang"><![CDATA[
    leaf example {
       type int32;
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-intsdf">
          <name>SDF conversion of the YANG leaf from the last figure</name>
          <sourcecode type="json"><![CDATA[
    "sdfProperty": {
        "example": {
            "description": "!Conversion note: type int32!\n",
            "maximum": 2147483647,
            "minimum": -2147483648,
            "type": "integer"
        }
    }
]]></sourcecode>
        </figure>
      </section>
      <section anchor="boolean-built-in-type" numbered="true" toc="default">
        <name>Boolean Built-In Type</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="9.5" sectionFormat="bare" format="default">boolean</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.7" sectionFormat="bare" format="default">data qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>The YANG boolean built-in type holds a boolean value, that is one of either <tt>true</tt> or <tt>false</tt>. It is converted to the SDF <tt>boolean</tt> type. There are no further sub-statements to this type in YANG.</t>
      </section>
      <section anchor="binary-built-in-type" numbered="true" toc="default">
        <name>Binary Built-In Type</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="9.8" sectionFormat="bare" format="default">binary</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.7" sectionFormat="bare" format="default">data qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>To represent binary data, the YANG built-in type <tt>binary</tt> can be used. If the argument of the YANG <tt>type</tt> statement is <tt>binary</tt> the SDF <tt>type</tt> quality is set to <tt>string</tt>. In addition, the <tt>sdfType</tt> quality is set to <tt>byte-string</tt>. A YANG binary can have a sub-statement restricting its length. This is converted to SDF via the <tt>minLength</tt> and <tt>maxLength</tt> qualities. Like the <tt>string</tt> YANG built-in type, the <tt>binary</tt> type can also be restricted by a <tt>length</tt> statement. This <tt>length</tt> statement is converted as described in <xref target="design-string" format="default"/>.</t>
      </section>
      <section anchor="enumeration-built-in-type" numbered="true" toc="default">
        <name>Enumeration Built-In Type</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="9.6" sectionFormat="bare" format="default">enumeration</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.7" sectionFormat="bare" format="default">data qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>The YANG built-in type <tt>enumeration</tt> is used to map string-valued alternatives to integer values. Additionally each string can have a description and other sub-statements. SDF also specifies an <tt>enum</tt> quality which is used to represent YANG enumerations. The SDF <tt>enum</tt> quality only holds an array of strings. All other information is stored in conversion notes in the description of the SDF definition the enum belongs to, as specified in <xref target="design-roundtrips" format="default"/>.</t>
      </section>
      <section anchor="bits-built-in-type" numbered="true" toc="default">
        <name>Bits Built-In Type</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="9.8" sectionFormat="bare" format="default">bits</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.7" sectionFormat="bare" format="default">data qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>SDF does not specify a built-in type to represent a set of named bits and their positions like YANG does with its built-in type <tt>bits</tt>. Therefore, this built-in type has to be converted to SDF type <tt>object</tt> with one entry to the <tt>properties</tt> quality of type <tt>boolean</tt> for each bit. The property is named after the name of the bit. The position of the bit is stored in a conversion note as described in <xref target="design-roundtrips" format="default"/>. An example conversion of a leaf with type <tt>bits</tt> to SDF can be found in <xref target="fig-bits" format="default"/> and <xref target="fig-bitssdf" format="default"/>.</t>
        <figure anchor="fig-bits">
          <name>YANG leaf that is of the built-in type bits</name>
          <sourcecode type="yang"><![CDATA[
    leaf example {
       type bits {
            bit auto-adapt {
                description "1 if automatic adaption is enabled, 0 otherwise";
                position 1;
            }
            bit battery-only { position 2; }
            bit disable-sensor { position 0; }
       }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-bitssdf">
          <name>SDF conversion of the YANG leaf from the last figure</name>
          <sourcecode type="json"><![CDATA[
    "sdfProperty": {
        "example": {
            "description": "!Conversion note: type bits!\n",
            "properties": {
                "auto-adapt": {
                    "description": "Bit at position 1: 1 if automatic adaption is enabled, 0 otherwise",
                    "type": "boolean"
                },
                "battery-only": {
                    "description": "Bit at position 2",
                    "type": "boolean"
                },
                "disable-sensor": {
                    "description": "Bit at position 0",
                    "type": "boolean"
                }
            },
            "type": "object"
        }
    }
]]></sourcecode>
        </figure>
      </section>
      <section anchor="union-built-in-type" numbered="true" toc="default">
        <name>Union Built-In Type</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="9.12" sectionFormat="bare" format="default">union</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.7.2" sectionFormat="bare" format="default">sdfChoice</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>YANG unions hold a set of alternatives for the <tt>type</tt> statement. Although the <tt>union</tt> built-in type of YANG does not exist as a built-in type in SDF, its meaning can be easily represented by the <tt>sdfChoice</tt> quality. The sdfChoice corresponding to the union contains a set of named alternatives each named after the respective type in the YANG union and each containing nothing but the SDF <tt>type</tt> quality set to the SDF equivalent of the respective type. <xref target="fig-union" format="default"/> and <xref target="fig-unionsdf" format="default"/> illustrate this mapping.</t>
        <figure anchor="fig-union">
          <name>YANG leaf that uses the union built-in type</name>
          <sourcecode type="yang"><![CDATA[
    leaf example {
        type union {
            type string;
            type boolean;
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-unionsdf">
          <name>SDF conversion of the YANG leaf from the last figure</name>
          <sourcecode type="json"><![CDATA[
    "sdfProperty": {
        "example": {
            "description": "!Conversion note: type union!\n",
            "sdfChoice": {
                "boolean": {
                    "type": "boolean"
                },
                "string": {
                    "type": "string"
                }
            }
        }
    }
]]></sourcecode>
        </figure>
      </section>
      <section anchor="leafref-and-identityref-built-in-types" numbered="true" toc="default">
        <name>Leafref and Identityref Built-In Types</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="9.9" sectionFormat="bare" format="default">leafref</xref> of <xref target="RFC7950" format="default"/> Section <xref target="RFC7950" section="9.10" sectionFormat="bare" format="default">identityref</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.4" sectionFormat="bare" format="default">sdfRef</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>The YANG built-in types <tt>leafref</tt> and <tt>identityref</tt> are used to reference a <tt>leaf</tt> node or <tt>identity</tt> definition respectively. They are represented in SDF by the <tt>sdfRef</tt> quality. As an argument said <tt>sdfRef</tt> quality contains a reference to the SDF element corresponding to the target of the leafref or <tt>identityref</tt> statement.</t>
      </section>
      <section anchor="empty-built-in-type" numbered="true" toc="default">
        <name>Empty Built-In Type</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="9.11" sectionFormat="bare" format="default">empty</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.7" sectionFormat="bare" format="default">data qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>Another concept that is not contained in SDF directly is that of the YANG built-in type <tt>empty</tt>. YANG elements with this type convey meaning by their mere existence or non-existence. This is represented in SDF using the compound-type with an empty set of properties.</t>
      </section>
      <section anchor="instance-identifier-built-in-type" numbered="true" toc="default">
        <name>Instance-Identifier Built-In Type</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="9.13" sectionFormat="bare" format="default">instance-identifier</xref> of <xref target="RFC7950" format="default"/></li>
        </ul>
        <t>The <tt>instance-identifier</tt> built-in type of YANG is used to refer to a particular instance of a node in the data tree. As of now, it cannot be represented functionally in SDF because there is currently no possibility to refer to specific instances of SDF definitions. This feature might be added to SDF in the future. For now, this type is represented by the string built-in type of SDF. Furthermore, a conversion note is added to the resulting SDF definition as specified in <xref target="design-roundtrips" format="default"/>.
.</t>
      </section>
      <section anchor="typedef-statement" numbered="true" toc="default">
        <name>Typedef Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="9.3" sectionFormat="bare" format="default">typedef</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.4" sectionFormat="bare" format="default">sdfRef</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>The <tt>typedef</tt> statement has the purpose to define derived types in YANG. The SDF class <tt>sdfData</tt> is used to represent typedefs after conversion. The usage of a derived type via the <tt>type</tt> statement is converted to an <tt>sdfRef</tt> to the corresponding <tt>sdfData</tt> definition. If a derived type is restricted according to its base type, for example with a <tt>range</tt> statement, the restrictions are converted as they would be for the base type and added to the <tt>sdfData</tt> definition.</t>
      </section>
      <section anchor="identity-statement" numbered="true" toc="default">
        <name>Identity Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.18" sectionFormat="bare" format="default">identity</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="5.5" sectionFormat="bare" format="default">sdfData</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>The YANG <tt>identity</tt> statement is used to denote the name and existence of an identity. Identities can be based on one or more other identities. They are referenced with the <tt>identityref</tt> statement. This concept is converted to SDF by <tt>sdfData</tt> definitions for each identity. If an identity is based on one other identity this is represented by an <tt>sdfRef</tt> reference to the <tt>sdfData</tt> definition corresponding to the base identity. If an identity has multiple base identities it is converted to a compound-type <tt>sdfData</tt> definition with one property for each base identity. Each property contains an <tt>sdfRef</tt> reference to the <tt>sdfData</tt> definition corresponding to one of the base identities.</t>
      </section>
      <section anchor="config-statement" numbered="true" toc="default">
        <name>Config Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.21.1" sectionFormat="bare" format="default">config</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.7" sectionFormat="bare" format="default">data qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>The <tt>config</tt> statement of YANG can have the boolean values <tt>true</tt> or <tt>false</tt> as arguments. If config is set to <tt>true</tt> the element containing the <tt>config</tt> statement represents readable and writable configuration data. If the <tt>config</tt> statement is set to <tt>false</tt> the element containing the statement represents read-only state data. This is transferred to SDF via the <tt>readable</tt> and <tt>writable</tt> qualities. If the <tt>config</tt> statement is set to <tt>true</tt> it is mapped to the <tt>readable</tt> and <tt>writable</tt> qualities both being set to true. If the <tt>config</tt> statement is set to <tt>false</tt> it is converted by setting the <tt>readable</tt> quality to <tt>true</tt> and the <tt>writable</tt> quality to false. There are, however, cases in which the SDF definition corresponding to the YANG element containing the <tt>config</tt> statement is not one that can use data qualities. This is the case, for example, if a top-level container, which is converted to sdfObject, holds a <tt>config</tt> statement. In this case, all definitions inside the sdfObject that can use data qualities have the <tt>readable</tt> and <tt>writable</tt> qualities set as described above.</t>
      </section>
      <section anchor="status-statement" numbered="true" toc="default">
        <name>Status Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.21.2" sectionFormat="bare" format="default">status</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.6" sectionFormat="bare" format="default">common qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>The <tt>status</tt> statement of YANG is used to express whether a definition is either current, deprecated or obsolete. In SDF there is no quality with a similar meaning. Thus, the YANG <tt>status</tt> statement is represented by a conversion note in the description of the SDF definition corresponding to the YANG element the <tt>status</tt> statement occurred in as described in <xref target="design-roundtrips" format="default"/>.</t>
      </section>
      <section anchor="reference-statement" numbered="true" toc="default">
        <name>Reference Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.21.4" sectionFormat="bare" format="default">reference</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.6" sectionFormat="bare" format="default">common qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>In YANG the <tt>reference</tt> statement holds a human-readable reference to an external document related to its containing YANG definition. This information is preserved through a conversion note in the description of the SDF definition equivalent to the node  containing the <tt>reference</tt> statement as described in <xref target="design-roundtrips" format="default"/>.</t>
      </section>
      <section anchor="when-and-must-statements" numbered="true" toc="default">
        <name>When and Must Statements</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.5.3" sectionFormat="bare" format="default">must</xref> of <xref target="RFC7950" format="default"/> Section <xref target="RFC7950" section="7.21.5" sectionFormat="bare" format="default">when</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.6" sectionFormat="bare" format="default">common qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>As mentioned before, YANG provides means to impose conditions on its definitions. If a node in the data tree has an unfulfilled <tt>must</tt> or <tt>when</tt> condition it is invalidated. <tt>Must</tt> and <tt>when</tt> conditions use XML Path Language expressions to indicate dependencies. This feature is not realizable in SDF as of now and is thus preserved through conversion notes as described in <xref target="design-roundtrips" format="default"/>.</t>
        <t>There is a query language similar to XML Path Language for JSON called JSONPath. If SDF adopts JSONPath or something similar in the future the converter can be extended to process the functionality of <tt>must</tt> and <tt>when</tt> statements.</t>
      </section>
      <section anchor="extension-statement" numbered="true" toc="default">
        <name>Extension Statement</name>
        <ul spacing="normal">
          <li>YANG: Section <xref target="RFC7950" section="7.19" sectionFormat="bare" format="default">extension</xref> of <xref target="RFC7950" format="default"/></li>
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.6" sectionFormat="bare" format="default">common qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
        </ul>
        <t>The <tt>extension</tt> statement in YANG has the purpose of defining new statements for the YANG language. This is not a concept that can be transferred to SDF yet. When an extension is used, this fact has to be stored in a conversion note in the description of the SDF definition that is analogue to the YANG definition containing the <tt>extension</tt> statement, as described in <xref target="design-roundtrips" format="default"/>. The definition of the extension is not converted.</t>
      </section>
    </section>
    <section anchor="mapping-from-sdf-to-yang" numbered="true" toc="default">
      <name>Mapping from SDF to YANG</name>
      <t>In this section the conversion of each element of SDF to YANG is explained in detail. For reference on the individual YANG statements see <xref target="RFC7950" format="default"/> and <xref target="I-D.ietf-asdf-sdf" format="default"/> for SDF. Examples have been inserted where they are necessary to understand the mapping.</t>
      <section anchor="information-block" numbered="true" toc="default">
        <name>Information Block</name>
        <ul spacing="normal">
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="3.1" sectionFormat="bare" format="default">information block</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
          <li>YANG: Section <xref target="RFC7950" section="7.1" sectionFormat="bare" format="default">module</xref> of <xref target="RFC7950" format="default"/></li>
        </ul>
        <t>At the top of an SDF model the information block holds meta data, that is the title, version, copyright and license information, about the model. When mapping an SDF model to YANG, the content of the <tt>title</tt> quality is used as the name for the YANG module. For this, the title string has to be modified to only contain lower case letters, digits and the characters "_", "-" and ".". If the <tt>version</tt> quality contains a date in the format <em>month-day-year</em> it is analogue to the <tt>revision</tt> statement of YANG and converted as such. The strings from the <tt>copyright</tt> and <tt>license</tt> qualities are stored in the description of the resulting YANG module since there are no dedicated YANG statements equivalent to these qualities.</t>
      </section>
      <section anchor="namespace-section" numbered="true" toc="default">
        <name>Namespace Section</name>
        <ul spacing="normal">
          <li>SDF: Sections <xref target="I-D.ietf-asdf-sdf" section="3.2" sectionFormat="bare" format="default"/> and <xref target="I-D.ietf-asdf-sdf" section="4" sectionFormat="bare" format="default">namespaces section</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
          <li>YANG: Section <xref target="RFC7950" section="7.1.3" sectionFormat="bare" format="default">namespace</xref> of <xref target="RFC7950" format="default"/> Section <xref target="RFC7950" section="7.1.5" sectionFormat="bare" format="default">import</xref> of <xref target="RFC7950" format="default"/></li>
        </ul>
        <t>The purpose of the namespace section in an SDF model is to specify its (optional) namespace and the namespaces of external models whose definitions are referenced. The namespace section has a <tt>namespace</tt> quality mapping namespace URIs to a shortened name for that URI. The shortened name is also used as a prefix when referring to external definitions. If an SDF model is supposed to contribute globally available definitions, a value is given to the <tt>defaultNamespace</tt> quality and mapped to a namespace URI in the <tt>namespace</tt> quality. To map this to YANG, three of its statements are necessary: the <tt>import</tt>, the <tt>prefix</tt> and the <tt>namespace</tt> statement. To be able to use definitions from external modules in YANG, their names have to be declared by one <tt>import</tt> statement each. As a first step, each external SDF model that is mentioned in the namespace map also has to be converted to a YANG module. The default namespaces of the external SDF models are represented in the <tt>prefix</tt> sub-statement of the respective <tt>import</tt> statement. To represent the namespace and short name of the model, if present, the YANG <tt>namespace</tt> and <tt>prefix</tt> statements that are set accordingly. Both are top-level statements.</t>
      </section>
      <section anchor="sdfthing-quality" numbered="true" toc="default">
        <name>SdfThing Quality</name>
        <ul spacing="normal">
          <li>SDF: Sections <xref target="I-D.ietf-asdf-sdf" section="2.2.6" sectionFormat="bare" format="default"/> and <xref target="I-D.ietf-asdf-sdf" section="6.3" sectionFormat="bare" format="default">sdfThing</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
          <li>YANG: Section <xref target="RFC7950" section="7.5" sectionFormat="bare" format="default">container</xref> of <xref target="RFC7950" format="default"/></li>
        </ul>
        <t>An <tt>sdfThing</tt> definition holds the definition of a complex device that can be made up of multiple sdfObjects and multiple other sdfThings. SdfThings are converted to YANG <tt>container</tt> nodes. The <tt>sdf-spec</tt> extension is inserted to inform about the origin of the container as an sdfThing. This is necessary to facilitate round-trips because the container could also originate from an sdfObject.</t>
      </section>
      <section anchor="sdfobject-quality" numbered="true" toc="default">
        <name>SdfObject Quality</name>
        <ul spacing="normal">
          <li>SDF: Sections <xref target="I-D.ietf-asdf-sdf" section="2.2.1" sectionFormat="bare" format="default"/> and <xref target="I-D.ietf-asdf-sdf" section="5.1" sectionFormat="bare" format="default">sdfObject</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
          <li>YANG: Section <xref target="RFC7950" section="7.5" sectionFormat="bare" format="default">container</xref> of <xref target="RFC7950" format="default"/></li>
        </ul>
        <t><tt>SdfObject</tt> definitions are the main building blocks of an SDF model, grouping together definitions of the classes <tt>sdfProperty</tt>, <tt>sdfData</tt>, <tt>sdfAction</tt> and <tt>sdfEvent</tt>. They can also be used as arrays via their <tt>minItems</tt> and <tt>maxItems</tt> qualities. An sdfObject is mapped to a YANG <tt>container</tt> node if it is not defined as an array. Otherwise the sdfObject can be converted to a <tt>list</tt> node with the <tt>min-elements</tt> and <tt>max-elements</tt> statements set analogous to the <tt>minItems</tt> and <tt>maxItems</tt> qualities. This feature was only recently added to SDF and is thus not yet implemented neither in the SDF serializer/deserializer nor in the SDF/YANG converter.</t>
      </section>
      <section anchor="sec-map-comquali" numbered="true" toc="default">
        <name>Common Qualities</name>
        <ul spacing="normal">
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.6" sectionFormat="bare" format="default">common qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
          <li>
            <t>YANG:
            </t>
            <ul spacing="normal">
              <li>Section <xref target="RFC7950" section="7.21.3" sectionFormat="bare" format="default">description</xref> of <xref target="RFC7950" format="default"/></li>
              <li>Section <xref target="RFC7950" section="7.3" sectionFormat="bare" format="default">typedef</xref> of <xref target="RFC7950" format="default"/></li>
              <li>Section <xref target="RFC7950" section="9.9" sectionFormat="bare" format="default">leafref</xref> of <xref target="RFC7950" format="default"/></li>
              <li>Section <xref target="RFC7950" section="7.13" sectionFormat="bare" format="default">uses</xref> of <xref target="RFC7950" format="default"/></li>
              <li>Section <xref target="RFC7950" section="3" sectionFormat="bare" format="default">terminology for mandatory</xref> of <xref target="RFC7950" format="default"/></li>
            </ul>
          </li>
        </ul>
        <t>The set of qualities that is grouped under the name of <em>common qualities</em> can be used to provide meta data for SDF definitions.</t>
        <t>The <tt>description</tt> quality is converted to the YANG <tt>description</tt> statement. The <tt>label</tt> quality is ignored because it is identical to the identifier of the definition in most cases.</t>
        <t>The <tt>sdfRef</tt> quality is supposed to hold references to other definitions whose qualities are then copied into the referencing definition. Qualities of the referenced definition can also be overridden by defining them again in the referencing definition. The conversion of an sdfRef depends on what is referenced by it and what that is converted to. <xref target="fig-sdfRef" format="default"/> and <xref target="fig-sdfRefyang" format="default"/>, as well as <xref target="fig-sdfRef2" format="default"/> and <xref target="fig-sdfRefyang2" format="default"/> illustrate different conversions of the <tt>sdfRef</tt> quality. If the referenced definition is converted to a typedef the sdfRef is analogous to the <tt>type</tt> statement in YANG which points to the typedef. Overridden qualities can be represented by the respective sub-statements of the type which in turn override the sub-statements of the type of the typedef. This is the case for <tt>simpleDataRef</tt> in <xref target="fig-sdfRef" format="default"/> and <xref target="fig-sdfRefyang" format="default"/>. If the referenced definition is mapped to a leaf or <tt>leaf-list</tt> node it can be referenced by the <tt>leafref</tt> built-in type in YANG. This is the case for <tt>simplePropertyRef</tt> and <tt>simpleArrayPropertyRef</tt> in <xref target="fig-sdfRef2" format="default"/> and <xref target="fig-sdfRefyang2" format="default"/>. In this case overridden qualities cannot be represented in SDF.
If the YANG equivalent of the referenced definition is a <tt>grouping</tt> node the sdfRef is converted to a <tt>uses</tt> node which points to said grouping. The <tt>uses</tt> node is placed inside an additional container to preserve the name of the referencing SDF definition and to avoid sibling nodes with identical names (which is invalid in YANG). This is what is done for <tt>compoundDataRef</tt>, <tt>simpleArrayDataRef</tt> and <tt>compoundArrayDataRef</tt> in <xref target="fig-sdfRef" format="default"/> and <xref target="fig-sdfRefyang" format="default"/>. In all other cases the YANG equivalent of the referenced SDF definition cannot be referenced directly but has first to be packaged in a <tt>grouping</tt> node. This is done by first creating a grouping on the top-level of the module in order for the grouping to be available globally (in case it is also referenced in another model). The YANG node that is equivalent to the referenced SDF definition is copied into the new grouping and afterwards replaced with a <tt>uses</tt> node referencing the grouping. This is done to avoid redundancy. Lastly, the actual sdfRef is represented by another <tt>uses</tt> node referencing the newly created grouping. The <tt>uses</tt> node is placed inside a <tt>container</tt> node that represents the SDF definition that contains the sdfRef to preserve the name of the SDF definition. Furthermore, there cannot be two sibling nodes with the same name in YANG. The definitions <tt>compoundPropertyRef</tt> and <tt>compoundArrayPropertyRef</tt> in <xref target="fig-sdfRef2" format="default"/> and <xref target="fig-sdfRefyang2" format="default"/> are examples of such conversions. If SDF qualities of the referenced definition are overridden in the referencing definition this is represented with the <tt>refine</tt> statement which can be a sub-statement to <tt>uses</tt> node (see <tt>compoundArrayPropertyRef</tt> in <xref target="fig-sdfRef2" format="default"/> and <xref target="fig-sdfRefyang2" format="default"/>).</t>
        <figure anchor="fig-sdfRef">
          <name>SDF model that uses the sdfRef with different sdfData definitions</name>
          <sourcecode type="json"><![CDATA[
    {
        ; [...]
        "sdfObject": {
            "ExampleObject": {
                "sdfData": {
                    "simpleData": { "type": "string" },
                    "compoundData": {
                        "type": "object",
                        "properties": {
                            "A": { "type": "string" },
                            "B": { "type": "string" }
                        }
                    },
                    "simpleArrayData": {
                        "type": "array",
                        "items": { "type": "string" }
                    },
                    "compoundArrayData": {
                        "type": "array",
                        "items": {
                            "type": "object",
                            "properties": {
                                "A": { "type": "string" },
                                "B": { "type": "string" }
                            }
                        }
                    }
                },
                "sdfProperty": {
                    "simpleDataRef": {
                        "sdfRef": "#/sdfObject/ExampleObject/sdfData/simpleData",
                        "pattern": "[a-z]*"
                    },
                    "compoundDataRef": { "sdfRef": "#/sdfObject/ExampleObject/sdfData/compoundData" },
                    "simpleArrayDataRef": { "sdfRef": "#/sdfObject/ExampleObject/sdfData/simpleArrayData" },
                    "compoundArrayDataRef": { "sdfRef": "#/sdfObject/ExampleObject/sdfData/compoundArrayData" }
                }
            }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-sdfRefyang">
          <name>YANG conversion of the SDF model from the last figure</name>
          <sourcecode type="yang"><![CDATA[
    module exampleModel {
        // [...]
        typedef simpleData { type string; }
        grouping compoundArrayData {
            helper:sdf-spec "sdfData";
            list compoundArrayData {
                config false;
                leaf A { type string; }
                leaf B { type string; }
            }
        }
        grouping compoundData {
            helper:sdf-spec "sdfData";
            leaf A { type string; }
            leaf B { type string; }
        }
        grouping simpleArrayData {
            helper:sdf-spec "sdfData";
            leaf-list simpleArrayData { type string; }
        }
        container ExampleObject {
            helper:sdf-spec "sdfObject";
            container compoundArrayDataRef {
                helper:sdf-spec "sdfProperty";
                uses compoundArrayData;
            }
            container compoundDataRef {
                helper:sdf-spec "sdfProperty";
                uses compoundData;
            }
            container simpleArrayDataRef {
                helper:sdf-spec "sdfProperty";
                uses simpleArrayData;
            }
            leaf simpleDataRef {
                type simpleData { pattern "[a-z]*"; }
            }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-sdfRef2">
          <name>SDF model that uses the sdfRef with sdfProperty definitions</name>
          <sourcecode type="json"><![CDATA[
    {
        ; [...]
        "sdfObject": {
            "ExampleObject2": {
                "sdfProperty": {
                    "simpleProperty": { "type": "string" },
                    "compoundProperty": {
                        "type": "object",
                        "properties": {
                            "A": { "type": "string" },
                            "B": { "type": "string" }
                        }
                    },
                    "simpleArrayProperty": {
                        "type": "array",
                        "items": { "type": "string" }
                    },
                    "compoundArrayProperty": {
                        "type": "array",
                        "items": {
                            "type": "object",
                            "properties": {
                                "A": { "type": "string" },
                                "B": { "type": "string" }
                            }
                        }
                    },
                    "simplePropertyRef": { "sdfRef": "#/sdfObject/ExampleObject2/sdfProperty/simpleProperty" },
                    "compoundPropertyRef": { "sdfRef": "#/sdfObject/ExampleObject2/sdfProperty/compoundProperty" },
                    "simpleArrayPropertyRef": { "sdfRef": "#/sdfObject/ExampleObject2/sdfProperty/simpleArrayProperty" },
                    "compoundArrayPropertyRef": {
                        "sdfRef": "#/sdfObject/ExampleObject2/sdfProperty/compoundArrayProperty",
                        "minItems": 4
                    }
                }
            }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-sdfRefyang2">
          <name>YANG conversion of the SDF model from the last figure</name>
          <sourcecode type="yang"><![CDATA[
    module exampleModel {
        // [...]
        grouping compoundArrayProperty {
            list compoundArrayProperty {
                helper:sdf-spec "sdfProperty";
                key "A";
                leaf A { type string; }
                leaf B { type string; }
            }
        }
        grouping compoundProperty {
            helper:sdf-spec "sdfProperty";
            leaf A { type string; }
            leaf B { type string; }
        }
        container ExampleObject2 {
            helper:sdf-spec "sdfObject";
            container compoundPropertyRef {
                helper:sdf-spec "sdfProperty";
                uses compoundProperty;
            }
            uses compoundProperty;
            leaf-list simpleArrayProperty { type string; }

            leaf-list simpleArrayPropertyRef {
                type leafref { path "/ExampleObject2/simpleArrayProperty"; }
            }
            leaf simpleProperty { type string; }
            leaf simplePropertyRef {
                type leafref { path "/ExampleObject2/simpleProperty"; }
            }
            container compoundArrayPropertyRef {
                uses compoundArrayProperty {
                    refine compoundArrayProperty { min-elements 4; }
                }
            }
            uses compoundArrayProperty;
        }
    }
]]></sourcecode>
        </figure>
        <t>The common quality <tt>sdfRequired</tt> contains a list of SDF declarations that are mandatory to be present in an instance of the SDF model. The issue with the conversion of this quality is that in YANG not all nodes can be marked with the <tt>mandatory</tt> statement while in SDF all declarations (that means sdfProperties, sdfActions and sdfEvents that occur in an sdfObject) can be mentioned in the sdfRequired list. In YANG only <tt>leaf</tt> and <tt>choice</tt> nodes (and <tt>anyxml</tt> and <tt>anydata</tt> nodes but these are not used for conversion) can be directly labeled as mandatory. <tt>List</tt> and <tt>leaf-list</tt> nodes can indirectly be made mandatory through the <tt>min-elements</tt> statement. Furthermore, <tt>container</tt> nodes without a <tt>presence</tt> statement that have at least one mandatory node as a child are also mandatory themselves. Not all SDF declarations are always converted to YANG <tt>leaf</tt>, <tt>choice</tt>, <tt>list</tt> or <tt>leaf-list</tt> nodes, however. Thus, if the YANG node equivalent to the mandatory SDF declaration is a non-presence container, its sub-tree is traversed until a <tt>leaf</tt> or <tt>choice</tt> node is found. This <tt>leaf</tt> or <tt>choice</tt> node is labeled as mandatory, now making its parent container mandatory as well because one of its child nodes is mandatory. An example for such a conversion is illustrated in the <tt>compoundProperty</tt> definition in <xref target="fig-sdfRequired" format="default"/> and <xref target="fig-sdfRequiredyang" format="default"/>. Consequently, if the parent node of the now mandatory container would be a container it would now be mandatory as well. Alternatively, if a <tt>list</tt> or <tt>leaf-list</tt> node is found first, the <tt>min-elements</tt> statement of the node is set to <tt>1</tt> if it is not already set to a value greater than zero, which also makes a node mandatory. This is illustrated in the <tt>simpleArrayProperty</tt> and <tt>compoundArrayProperty</tt> definitions in <xref target="fig-sdfRequired" format="default"/> and <xref target="fig-sdfRequiredyang" format="default"/>. To prevent loss of information and to facilitate round trips, the declaration originally listed in the <tt>sdfRequired</tt> quality is preserved in the <tt>sdf-spec</tt> extension as described in <xref target="design-roundtrips" format="default"/>.</t>
        <figure anchor="fig-sdfRequired">
          <name>SDF model that contains the sdfRequired quality</name>
          <sourcecode type="json"><![CDATA[
    "sdfObject": {
        "ExampleObject": {
            "sdfRequired": [
                "#/sdfObject/ExampleObject/sdfProperty/simpleProperty",
                "#/sdfObject/ExampleObject/sdfEvent/compoundProperty",
                "#/sdfObject/ExampleObject/sdfEvent/simpleArrayProperty",
                "#/sdfObject/ExampleObject/sdfEvent/compoundArrayProperty"
            ],
            "sdfProperty": {
                "simpleProperty": { "type": "string" },
                "compoundProperty": {
                    "type": "object",
                    "properties": {
                        "A": { "type": "string" },
                        "B": { "type": "string" }
                    }
                },
                "simpleArrayProperty": {
                    "type": "array",
                    "items": { "type": "string" }
                },
                "compoundArrayProperty": {
                    "type": "array",
                    "items": {
                        "type": "object",
                        "properties": {
                            "A": { "type": "string" },
                            "B": { "type": "string" }
                        }
                    }
                }
            }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-sdfRequiredyang">
          <name>YANG conversion of the last figure</name>
          <sourcecode type="yang"><![CDATA[
    container ExampleObject {
        helper:sdf-spec "sdfObject";

        list compoundArrayProperty {
            helper:sdf-spec "sdfProperty";
            helper:sdf-spec "sdfRequired";
            config false;
            min-elements 1;
            leaf A { type string; }
            leaf B { type string; }
        }

        container compoundProperty {
        helper:sdf-spec "sdfProperty";
            helper:sdf-spec "sdfRequired";
        leaf A {
            type string;
            mandatory true;
        }
        leaf B { type string; }
        }

        leaf-list simpleArrayProperty {
            helper:sdf-spec "sdfProperty";
            helper:sdf-spec "sdfRequired";
            type string;
            min-elements 1;
        }

        leaf simpleProperty {
            helper:sdf-spec "sdfRequired";
            type string;
            mandatory true;
        }
    }
]]></sourcecode>
        </figure>
      </section>
      <section anchor="sec-map-dataquali" numbered="true" toc="default">
        <name>Data Qualities</name>
        <ul spacing="normal">
          <li>SDF: Section <xref target="I-D.ietf-asdf-sdf" section="4.7" sectionFormat="bare" format="default">data qualities</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
          <li>
            <t>YANG:
            </t>
            <ul spacing="normal">
              <li>Section <xref target="RFC7950" section="7.4.1" sectionFormat="bare" format="default">type</xref> of <xref target="RFC7950" format="default"/></li>
            </ul>
          </li>
        </ul>
        <t>The set of qualities labeled as <em>data qualities</em> contains qualities inspired by the json-schema.org specifications that SDF adopted as well as qualities specifically defined for SDF. In the first group there is a total of 18 qualities out of which some are interdependent.</t>
        <t>The quality that a lot of the other qualities presence or absence depends on is the <tt>type</tt> quality. The type can be one of <tt>number</tt>, <tt>string</tt>, <tt>boolean</tt>, <tt>integer</tt>, <tt>array</tt> or <tt>object</tt>. This quality is directly converted to the YANG <tt>type</tt> statement for all simple type. The type <tt>number</tt> becomes <tt>decimal64</tt>, integer becomes <tt>int64</tt>. The types <tt>string</tt> and <tt>boolean</tt> have built-in type equivalents in YANG. The types <tt>array</tt> and <tt>object</tt> cannot be converted to a YANG built-in type directly. Instead SDF definitions with these types are converted as described in <xref target="sec-map-sdfProp" format="default"/> and <xref target="sec-map-sdfData" format="default"/>, that is type <tt>array</tt> is mapped to <tt>leaflist</tt> or <tt>list</tt> nodes and type <tt>object</tt> is mapped to <tt>container</tt> nodes.</t>
        <t>If a constant value is defined in an SDF definition, the data quality <tt>const</tt> is used to hold it. If the value of the <tt>type</tt> quality is <tt>number</tt> or <tt>integer</tt> the <tt>const</tt> quality is mapped to the <tt>range</tt> sub-statement of the <tt>type</tt> statement of YANG, which can also contain a single value. An example of such a conversion is illustrated in <tt>displayWidth</tt> in <xref target="fig-const" format="default"/> and <xref target="fig-constyang" format="default"/>. For constant string values the YANG <tt>pattern</tt> statement containing the constant string is used, as shown in the <tt>displayText</tt> definition in <xref target="fig-const" format="default"/> and <xref target="fig-constyang" format="default"/>. Unfortunately, constant values of types <tt>boolean</tt> and <tt>array</tt> can only be preserved in YANG through the <tt>sdf-spec</tt> extension.</t>
        <figure anchor="fig-const">
          <name>SdfObject that contains the const quality</name>
          <sourcecode type="json"><![CDATA[
    "sdfObject": {
        "Display": {
            "sdfProperty": {
                "displayText": {
                    "type": "string",
                    "const": "Hello World!"
                },
                "displayWidth": {
                    "type": "integer",
                    "const": 300
                }
            }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-constyang">
          <name>YANG conversion of the sdfObject from the last figure</name>
          <sourcecode type="yang"><![CDATA[
    container Display {
        helper:sdf-spec "sdfObject";
        leaf displayText {
            type string { pattern "Hello World!"; }
        }
        leaf displayWidth {
            type int64 { range "300"; }
        }
    }
]]></sourcecode>
        </figure>
        <t>The <tt>default</tt> data quality in SDF holds the default value for its definition. Since YANG <tt>leaf</tt> and <tt>leaf-list</tt> nodes have a <tt>default</tt> sub-statement, SDF default values of simple types or of type <tt>array</tt> with items of simple types can easily be represented.</t>
        <t>The data qualities <tt>minimum</tt>, <tt>maximum</tt>, <tt>exclusiveMinimum</tt> and <tt>exclusiveMaximum</tt> which are only valid for the types <tt>number</tt> and <tt>integer</tt> are converted using the YANG <tt>range</tt> statement again. For exclusive boundaries the range is reduced accordingly in YANG. This is only possible for <tt>integer</tt> types or if the <tt>multipleOf</tt> quality specifies the size by which the number limit has to be reduced. Alternatives in the YANG range have to be disjoint, however. This poses a problem when the <tt>range</tt> statement is already used to map a constant value. Thus, if both minimum or maximum and constant values are defined, this is represented through the YANG <tt>union</tt> built-in type, instead. As illustrated in <xref target="fig-constminmax" format="default"/> and <xref target="fig-constminmaxyang" format="default"/>, in the YANG conversion of the definition the union contains the same type twice, but with different ranges.</t>
        <figure anchor="fig-constminmax">
          <name>SdfProperty that uses the minimum and maximum qualities in conjunction with the const quality</name>
          <sourcecode type="json"><![CDATA[
    "sdfProperty": {
        "displayWidth": {
            "type": "integer",
            "const": 300,
            "minimum": 100,
            "maximum": 1000
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-constminmaxyang">
          <name>YANG conversion of the sdfProperty from the last figure</name>
          <sourcecode type="yang"><![CDATA[
    leaf displayWidth {
        type union {
            type int64 { range "300"; }
            type int64 { range "100..1000"; }
        }
    }
]]></sourcecode>
        </figure>
        <t>The <tt>multipleOf</tt> data quality is one that can only be used in conjunction with the <tt>number</tt> type in SDF and states the resolution of the decimal value, that is, of which decimal number the value is a multiple of. This quality is converted to the <tt>fraction-digits</tt> sub-statement to the <tt>type</tt> statement in YANG by counting the digits after the decimal separator of the value of the <tt>multipleOf</tt> quality. Since the <tt>fraction-digits</tt> statement is mandatory in YANG, it is set to <tt>6</tt> by default. This is done because six is also the default decimal resolution of the <tt>std::to_string()</tt> method of the C++ standard library. This method is used for transferring data from the C++ objects that represent SDF definitions into JSON.</t>
        <t>The <tt>minLength</tt> and <tt>maxLength</tt> data qualities of SDF are used to hold the minimal and maximal length of strings. This concept can be transferred to YANG by using the <tt>length</tt> sub-statement of the <tt>type</tt> statement that specifies a length range.</t>
        <t>The SDF <tt>pattern</tt> data quality holds regular expressions for <tt>string</tt> typed definitions. This can be converted directly to the <tt>pattern</tt> sub-statement of the <tt>type</tt> statement in YANG. As already mentioned in <xref target="design-string" format="default"/> regular expressions cannot be converted directly between SDF and YANG in theory, due to the differing languages used for regular expressions. Because of the time limitations of this thesis no further measures are taken to insure the conformance of converted regular expressions.</t>
        <t>The <tt>string</tt> type in SDF can be supplemented by the <tt>format</tt> quality. This quality can specify one of the formats found on json-schema.org.
This could be translated to YANG referencing typedefs from the widely used <tt>ietf-yang-types</tt> module. To not rely on external modules, the format is only preserved through an addition of the <tt>sdf-spec</tt> extension to the YANG equivalent of the SDF definition the <tt>format</tt> quality is contained in.</t>
        <t>The length of an array in SDF can be restricted by the <tt>minItems</tt> and <tt>maxItems</tt> qualities. In YANG, both <tt>list</tt> and <tt>leaf-list</tt> nodes use the sub-statements <tt>min-elements</tt> and <tt>max-elements</tt> to express the same concept. They are therefore used to convert the SDF array length qualities.</t>
        <t>Another restriction for SDF arrays is the <tt>uniqueItems</tt> quality that can be set to either <tt>true</tt> or <tt>false</tt>. If it is set to <tt>true</tt> all items of an array are required to be different. For this purpose, YANG specifies the <tt>key</tt> and the <tt>unique</tt> sub-statements for <tt>list</tt> nodes. The combined values of the mentioned nodes have to be unique. These statements can only be applied to <tt>leaf</tt> nodes in the sub-tree. This does not pose a problem, however, because the uniqueness of a definition can only be measured by the uniqueness of its scalar values anyway. Thus, if an SDF array is converted to a YANG <tt>list</tt> node and the <tt>uniqueItems</tt> SDF quality is set to true, the <tt>key</tt> statement of the list states the first descendant <tt>leaf</tt> node of the list as the key, as illustrated in the <tt>compoundArrayProperty</tt> definition in <xref target="fig-uniqueitems" format="default"/> and <xref target="fig-uniqueitemsyang" format="default"/>. The <tt>key</tt> statement is chosen over the <tt>unique</tt> statement because it must be present in all writable lists anyway. It is not possible to explicitly represent the <tt>uniqueItems</tt> quality in <tt>leaf-list</tt> nodes. However, the values of <tt>leaf-list</tt> nodes that represent configuration data, and are therefore writable, must be unique. The <tt>writable</tt> quality is set to <tt>true</tt> by default. Thus, to represent an SDF array with unique items, in YANG the <tt>config</tt> statement is set to <tt>true</tt> whenever the <tt>writable</tt> quality in SDF is not set to <tt>false</tt>. An example of such a conversion can be found in the <tt>simpleArrayProperty</tt> definition in <xref target="fig-uniqueitems" format="default"/> and <xref target="fig-uniqueitemsyang" format="default"/>. Non-writable arrays with unique items cannot be represented as YANG leaf-lists.</t>
        <figure anchor="fig-uniqueitems">
          <name>SdfObject containing the uniqueItems quality</name>
          <sourcecode type="json"><![CDATA[
    "sdfObject": {
        "ExampleObject": {
            "sdfProperty": {
                "simpleArrayProperty": {
                    "type": "array",
                    "uniqueItems": true,
                    "items": { "type": "string" }
                },
                "compoundArrayProperty": {
                    "type": "array",
                    "uniqueItems": true,
                    "items": {
                        "type": "object",
                        "properties": {
                            "A": { "type": "string" },
                            "B": { "type": "string" }
                        }
                    }
                }
            }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-uniqueitemsyang">
          <name>YANG conversion of the sdfObject from the last figure</name>
          <sourcecode type="yang"><![CDATA[
    container ExampleObject {
        helper:sdf-spec "sdfObject";

        list compoundArrayProperty {
            helper:sdf-spec "sdfProperty";
            key "A";
            leaf A { type string; }
            leaf B { type string; }
        }

        leaf-list simpleArrayProperty {
            type string;
            config true;
        }
    }
]]></sourcecode>
        </figure>
        <t>The <tt>items</tt> data quality of SDF is a quality that specifies item constraints for the items of an array-typed SDF definition using a subset of the common and data qualities. SDF definitions with the type <tt>array</tt> are converted to <tt>list</tt> or <tt>leaf-list</tt> nodes. These node types in themselves indicate that a node represents an array. Thus, the qualities defined in the item constraints of an array are converted to the sub-statements of the equivalent <tt>list</tt> or <tt>leaf-list</tt> node as described in this section. <xref target="fig-uniqueitems" format="default"/> and <xref target="fig-uniqueitemsyang" format="default"/> contain an illustration of this mapping.</t>
        <t>Another SDF data quality is the <tt>properties</tt> quality. Properties defined through this quality are different from sdfProperties. The <tt>properties</tt> quality is used in conjunction with the <tt>object</tt> type and contains a set of named definitions made up of data qualities themselves. SDF definitions of type <tt>object</tt> are converted to <tt>container</tt> or <tt>grouping</tt> nodes. Thus, the named entries in the <tt>properties</tt> quality are each transformed to the child nodes of the container or grouping in question. This is illustrated in <xref target="sec-map-sdfProp" format="default"/> in the <tt>compoundProperty</tt> definition of <xref target="fig-sdfproperty" format="default"/> and <xref target="fig-sdfpropertyyang" format="default"/>. To label the properties as mandatory the <tt>required</tt> quality is used. Since it is resembling the <tt>sdfRequired</tt> quality, it is translated in the same way. The SDF type <tt>object</tt> was first introduced in SDF version 1.1 and made conversion of SDF models to YANG significantly more complicated. On the other hand, it is crucial to represent the tree structure of YANG.</t>
        <t>The second group of qualities that is part of the data qualities includes 11 qualities that are defined specifically for SDF.</t>
        <t>The <tt>unit</tt> quality can be set to any of the SenML unit names to represent the unit of an SDF definition. There is also a similar statement that can be defined as a sub-statement to <tt>typedef</tt> definitions, <tt>leaf</tt> nodes and <tt>leaf-list</tt> nodes. The <tt>units</tt> statement in YANG can contain any string and thus is simply set to the SenML unit name from the SDF definition.</t>
        <t>An important data quality is the <tt>sdfChoice</tt> quality. It represents the choice between several sets of named definitions made up of data qualities themselves. YANG provides a very similar statement, the <tt>choice</tt> statement. An sdfChoice is turned into a YANG <tt>choice</tt> node. Each of the alternatives of the sdfChoice is converted like an sdfProperty (see <xref target="sec-map-sdfProp" format="default"/>) and added to the <tt>choice</tt> node inside its own <tt>case</tt> node. <tt>SdfChoice</tt> definitions that give the choice between the <tt>type</tt> quality could also be mapped to the YANG type <tt>union</tt>. This is omitted for reasons of simplicity. An example conversion of the <tt>sdfChoice</tt> quality can be found in <xref target="fig-sdfchoice" format="default"/> and <xref target="fig-sdfchoiceyang" format="default"/>.</t>
        <figure anchor="fig-sdfchoice">
          <name>SdfObject with an sdfChoice quality</name>
          <sourcecode type="json"><![CDATA[
    "sdfObject": {
        "ExampleObject": {
            "sdfProperty": {
                "choiceProperty": {
                    "sdfChoice": {
                      "foo": { "type": "string" },
                      "bar": { "type": "boolean" },
                      "baz": { "type": "integer" }
                    }
                }
            }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-sdfchoiceyang">
          <name>YANG conversion of the sdfObject from the last figure</name>
          <sourcecode type="yang"><![CDATA[
    container ExampleObject {
        helper:sdf-spec "sdfObject";
        choice choiceProperty {
            case bar {
                leaf bar { type boolean; }
            }
            case baz {
                leaf baz { type int64; }
            }
            case foo {
                leaf foo { type string; }
            }
        }
    }
]]></sourcecode>
        </figure>
        <t>SDF also offers the possibility to define the choice between string values by means of the <tt>enum</tt> data quality. It consists of an array of strings. This concept also exists in YANG with the <tt>enumeration</tt> type and the corresponding <tt>enum</tt> sub-statement to the <tt>type</tt> statement. For an SDF definition that contains the <tt>enum</tt> quality the YANG type of its equivalent is set to <tt>enumeration</tt>. Each of the strings in the array of the <tt>enum</tt> SDF quality is converted to an <tt>enum</tt> entry in the <tt>type</tt> statement in YANG. The <tt>enum</tt> entries are also assigned an associated value.</t>
        <t>The <tt>scaleMinimum</tt> and <tt>scaleMaximum</tt> qualities represent limits in units as specified by the <tt>unit</tt> quality. They are not mapped to YANG because they will not be included in future versions of SDF. They are to be replaced in the future, therefore a mapping will have to be developed for their replacement.</t>
        <t>The <tt>contentFormat</tt> quality of SDF can provide an additional IANA content type. This information is preserved with the help of <tt>sdf-spec</tt> extension in the YANG equivalent of the SDF definition.</t>
        <t>Another way to complement the <tt>type</tt> quality is the <tt>sdfType</tt> quality that can either be set to <tt>byte-string</tt> or <tt>unix-time</tt>. A byte string is converted to the YANG type <tt>binary</tt>. There is no built-in YANG type corresponding to unix time
it is thus converted through the YANG <tt>units</tt> statement. The unit of the YANG conversion mentions <tt>unix-time</tt> as an argument.</t>
        <t>SDF defines the <tt>readable</tt> and <tt>writable</tt> qualities to flag whether read or write operations are allowed on definitions. Read operations are always allowed in YANG modules
so a <tt>readable</tt> quality that is set to <tt>false</tt> cannot be represented in YANG. The <tt>config</tt> YANG statement can be used to represent the value of the <tt>writable</tt> quality, however. If an SDF definition is explicitly marked as writable <tt>config</tt> is set to <tt>true</tt>. Otherwise, it is set to <tt>false</tt>.</t>
        <t>The <tt>observable</tt> and <tt>nullable</tt> qualities in SDF cannot be represented in YANG but are preserved by adding an <tt>sdf-spec</tt> extension to the YANG equivalent of their containing SDF definition.</t>
      </section>
      <section anchor="sec-map-sdfData" numbered="true" toc="default">
        <name>SdfData Quality</name>
        <ul spacing="normal">
          <li>SDF: Sections <xref target="I-D.ietf-asdf-sdf" section="2.2.5" sectionFormat="bare" format="default"/> and <xref target="I-D.ietf-asdf-sdf" section="5.5" sectionFormat="bare" format="default">sdfData</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
          <li>
            <t>YANG:
            </t>
            <ul spacing="normal">
              <li>Section <xref target="RFC7950" section="7.13" sectionFormat="bare" format="default">uses</xref> of <xref target="RFC7950" format="default"/></li>
              <li>Section <xref target="RFC7950" section="7.12" sectionFormat="bare" format="default">grouping</xref> of <xref target="RFC7950" format="default"/></li>
            </ul>
          </li>
        </ul>
        <t>Elements of the <tt>sdfData</tt> class are meant to hold data type definitions to be shared by <tt>sdfProperty</tt>, <tt>sdfAction</tt> and <tt>sdfEvent</tt> definitions. <tt>SdfData</tt> definitions can make use of the data qualities and the common qualities described in <xref target="sec-map-dataquali" format="default"/> and <xref target="sec-map-comquali" format="default"/> respectively.
Because an <tt>sdfData</tt> definition embodies a data type definition the YANG statements <tt>typedef</tt> and <tt>grouping</tt> have to be used for conversion. Which of the two is used depends on the value of the <tt>type</tt> quality of the <tt>sdfData</tt> definition. If the type is one of the simple data types, that is integer, number, boolean or string, the <tt>sdfData</tt> definition is converted to a YANG typedef.
If the type is <tt>object</tt> the <tt>sdfData</tt> definition is mapped to a <tt>grouping</tt> node with each of the entries of the <tt>properties</tt> quality of the compound-type being mapped to a child node of the grouping. When mapping <tt>sdfData</tt> definitions with type <tt>array</tt> to YANG, the type mentioned in the <tt>type</tt> quality of the <tt>items</tt> quality is essential as well. If an array has items of any of the simple types the resulting YANG element is a <tt>grouping</tt> node containing a single <tt>leaf-list</tt> node. Otherwise, if the array items are compound-types the <tt>sdfData</tt> definition is converted into a <tt>grouping</tt> node containing a single <tt>list</tt> node. The child nodes of the <tt>list</tt> node are equivalent to the entries of the <tt>properties</tt> quality that is contained in the <tt>item</tt> quality.</t>
        <t>One issue with converting <tt>sdfData</tt> definitions of type <tt>array</tt> is the added <tt>grouping</tt> node that is necessary to hold the equivalent <tt>leaf-list</tt> or <tt>list</tt> node. If the grouping is used in the schema tree the added level will cause model instances of the original and converted model to be in-equivalent.
If the <tt>sdfData</tt> definition is referenced in the SDF model via the <tt>sdfRef</tt> common quality this is represented in YANG with the <tt>uses</tt> statement pointing to the grouping equivalent to the <tt>sdfData</tt> definition.
The <tt>sdfRef</tt> quality can occur at most once in each definition while there can be multiple <tt>uses</tt> statements in a single container, list or grouping. Thus, instead of representing definitions containing an sdfRef by a parent node containing a <tt>uses</tt> node, the aforementioned issue with array-typed <tt>sdfData</tt> definitions could be solved by replacing the parent node with the <tt>uses</tt> node itself, effectively removing the excess level. This, however, gives rise to other issues because the name of the superordinate definition of the sdfRef is lost this way. An example for this issue is illustrated in <xref target="lst-objectarray" format="default"/> and <xref target="lst-objectarrayyang" format="default"/>. If the <tt>sdfData</tt> definition is converted to a typedef no such issues arise. The typedef in question is inserted as an argument to the YANG <tt>type</tt> quality wherever the original <tt>sdfData</tt> definition was referenced by an sdfRef.</t>
        <t>Another issue is a different view on global accessibility of data type definitions in YANG and SDF. In SDF, all definitions are globally available as long as a default namespace is defined in the SDF model. In YANG on the other hand, only data type definitions, that is groupings and typedefs, that occur on the top-level of a YANG module are globally accessible. Thus, to represent the global accessibility of all data type definitions in SDF, all converted <tt>sdfData</tt> definition equivalents in YANG are added to the top-level of the created module.</t>
        <t>Since these issues are also discussed in <xref target="sec-map-comquali" format="default"/>, examples conversion can be found there in <xref target="fig-sdfRef" format="default"/> and <xref target="fig-sdfRefyang" format="default"/>.</t>
      </section>
      <section anchor="sec-map-sdfProp" numbered="true" toc="default">
        <name>SdfProperty Quality</name>
        <ul spacing="normal">
          <li>SDF: Sections <xref target="I-D.ietf-asdf-sdf" section="2.2.2" sectionFormat="bare" format="default"/> and <xref target="I-D.ietf-asdf-sdf" section="5.2" sectionFormat="bare" format="default">sdfProperty</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
          <li>
            <t>YANG:
            </t>
            <ul spacing="normal">
              <li>Section <xref target="RFC7950" section="7.6" sectionFormat="bare" format="default">leaf</xref> of <xref target="RFC7950" format="default"/></li>
              <li>Section <xref target="RFC7950" section="7.7" sectionFormat="bare" format="default">leaf-list</xref> of <xref target="RFC7950" format="default"/></li>
              <li>Section <xref target="RFC7950" section="7.8" sectionFormat="bare" format="default">list</xref> of <xref target="RFC7950" format="default"/></li>
            </ul>
          </li>
        </ul>
        <t><tt>SdfProperty</tt> definitions represent elements of state as suggested by their name. <tt>SdfProperty</tt> definitions can make use of the data qualities and the common qualities described in <xref target="sec-map-dataquali" format="default"/> and <xref target="sec-map-comquali" format="default"/>. The mapping of an <tt>sdfProperty</tt> definition to YANG depends on the value of the <tt>type</tt> quality. SdfProperties with simple types are mapped to <tt>leaf</tt> nodes in YANG, as illustrated in the <tt>simpleProperty</tt> definition in <xref target="fig-sdfproperty" format="default"/> and <xref target="fig-sdfpropertyyang" format="default"/>. If the type is complex, that is type <tt>object</tt>, conversion results in a <tt>container</tt> node with each of the entries in the <tt>properties</tt> quality being mapped to a child node of the container. An example of such a conversion is the <tt>compoundProperty</tt> definition in <xref target="fig-sdfproperty" format="default"/> and <xref target="fig-sdfpropertyyang" format="default"/>. If the sdfProperty is of type <tt>array</tt> the deciding factor is the <tt>type</tt> quality inside the <tt>items</tt> quality. If an array has items of a simple type, it is converted to a <tt>leaf-list</tt> node. This is demonstrated by the <tt>simpleArrayProperty</tt> definition in <xref target="fig-sdfproperty" format="default"/> and <xref target="fig-sdfpropertyyang" format="default"/>. Otherwise, if the items are of compound-type the sdfProperty becomes a <tt>list</tt> node in YANG. The child nodes of the <tt>list</tt> node are equivalent to the entries of the <tt>properties</tt> quality in the compound-type, as illustrated in <xref target="fig-sdfproperty" format="default"/> and <xref target="fig-sdfpropertyyang" format="default"/> through the <tt>compoundArrayProperty</tt> definition. <tt>List</tt> nodes that represent configuration data, that means data that is writable, must specify at least one of its descendant <tt>leaf</tt> nodes as a key identifier. In SDF definitions that use the data qualities, such as sdfProperties, the <tt>writable</tt> quality is set to <tt>true</tt> by default. Therefore, the <tt>key</tt> statement of the <tt>list</tt> node is set to the first descendant <tt>leaf</tt> node of the list by default by the converter to comply with this rule. For round trips, this work-around is noted through the <tt>sdf-spec</tt> extension.</t>
        <figure anchor="fig-sdfproperty">
          <name>SdfObject with an sdfProperty definition</name>
          <sourcecode type="json"><![CDATA[
    "sdfObject": {
        "ExampleObject": {
            "sdfProperty": {
                "simpleProperty": { "type": "string" },
                "compoundProperty": {
                    "type": "object",
                    "properties": {
                        "A": { "type": "string" },
                        "B": { "type": "string" }
                    }
                },
                "simpleArrayProperty": {
                    "type": "array",
                    "items": { "type": "string" }
                },
                "compoundArrayProperty": {
                    "type": "array",
                    "items": {
                        "type": "object",
                        "properties": {
                            "A": { "type": "string" },
                            "B": { "type": "string" }
                        }
                    }
                }
            }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-sdfpropertyyang">
          <name>YANG conversion of the sdfObject from the last figure</name>
          <sourcecode type="yang"><![CDATA[
    container ExampleObject {
        helper:sdf-spec "sdfObject";
        list compoundArrayProperty {
            key "A";
            leaf A { type string; }
            leaf B { type string; }
        }
        container compoundProperty {
            leaf A { type string; }
            leaf B { type string; }
        }
        leaf-list simpleArrayProperty { type string; }
        leaf simpleProperty { type string; }
    }
]]></sourcecode>
        </figure>
      </section>
      <section anchor="sdfaction-quality" numbered="true" toc="default">
        <name>SdfAction Quality</name>
        <ul spacing="normal">
          <li>SDF: Sections <xref target="I-D.ietf-asdf-sdf" section="2.2.3" sectionFormat="bare" format="default"/> and <xref target="I-D.ietf-asdf-sdf" section="5.3" sectionFormat="bare" format="default">sdfAction</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
          <li>
            <t>YANG:
            </t>
            <ul spacing="normal">
              <li>Section <xref target="RFC7950" section="7.14" sectionFormat="bare" format="default">rpc</xref> of <xref target="RFC7950" format="default"/></li>
              <li>Section <xref target="RFC7950" section="7.15" sectionFormat="bare" format="default">action</xref> of <xref target="RFC7950" format="default"/></li>
            </ul>
          </li>
        </ul>
        <t>To represent operations that can be invoked in a model the <tt>sdfAction</tt> class is used. Since operations can have input and output data the <tt>sdfAction</tt> class is equipped with the <tt>sdfInputData</tt> and <tt>sdfOutputData</tt> qualities that can both make use of the data qualities and the common qualities described in <xref target="sec-map-dataquali" format="default"/> and <xref target="sec-map-comquali" format="default"/>. An sdfAction can also define its own set of data types in the form of <tt>sdfData</tt> definitions. Whether an sdfAction is converted to an <tt>rpc</tt> node (which can only occur at the top-level of a module) or an <tt>action</tt> node (which is always tied to a <tt>container</tt> node) depends on its location inside the SDF model. SdfActions that are not part of an sdfObject but can be found independently at the top of an SDF model are converted to <tt>rpc</tt> nodes. All other sdfActions occurring inside an sdfObject become <tt>action</tt> nodes inside the YANG container equivalent to the sdfObject, as illustrated in <xref target="fig-sdfaction" format="default"/> and <xref target="fig-sdfactionyang" format="default"/>
. The sdfInputData and sdfOutputData of an sdfAction are converted like sdfProperties (see <xref target="sec-map-sdfProp" format="default"/>) and added as the <tt>input</tt> and <tt>output</tt> node of the YANG RPC/action respectively.</t>
        <figure anchor="fig-sdfaction">
          <name>SdfObject definition that contains an sdfAction definition</name>
          <sourcecode type="json"><![CDATA[
    "sdfObject": {
        "ExampleObject": {
            "sdfAction": {
                "printString": {
                    "sdfInputData": {
                        "type": "object",
                        "properties": {
                            "content": { "type": "string" },
                            "colour": { "type": "string" }
                        }
                    },
                    "sdfOutputData": {
                        "type": "object",
                        "properties": {
                            "success": { "type": "boolean" }
                        }
                    }
                }
            }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-sdfactionyang">
          <name>YANG conversion of the sdfObject from the last figure</name>
          <sourcecode type="yang"><![CDATA[
    container ExampleObject {
        helper:sdf-spec "sdfObject";
        action printString {
            input {
                leaf colour { type string; }
                leaf content { type string; }
            }
            output {
                leaf success { type boolean; }
            }
        }
    }
]]></sourcecode>
        </figure>
      </section>
      <section anchor="sdfevent-quality" numbered="true" toc="default">
        <name>SdfEvent Quality</name>
        <ul spacing="normal">
          <li>SDF: Sections <xref target="I-D.ietf-asdf-sdf" section="2.2.4" sectionFormat="bare" format="default"/> and <xref target="I-D.ietf-asdf-sdf" section="5.4" sectionFormat="bare" format="default">sdfEvent</xref> of <xref target="I-D.ietf-asdf-sdf" format="default"/></li>
          <li>YANG: Section <xref target="RFC7950" section="7.16" sectionFormat="bare" format="default">notification</xref> of <xref target="RFC7950" format="default"/></li>
        </ul>
        <t>The purpose of the sdfEvent class is to model signals that inform about occurrences or events in an sdfObject. To represent the emitted output data, sdfEvents can make use of the <tt>sdfOutputData</tt> quality which in turn uses the data qualities. An sdfEvent is converted to a <tt>notification</tt> node with one <tt>child</tt> node representing the <tt>sdfOutputData</tt> definition. The <tt>sdfOutputData</tt> definition is converted like an sdfProperty (see <xref target="sec-map-sdfProp" format="default"/>). <xref target="fig-sdfevent" format="default"/> and <xref target="fig-sdfeventyang" format="default"/> contain the SDF and YANG representations of a <tt>warning</tt> notification which communicates the device and reason of the warning.</t>
        <figure anchor="fig-sdfevent">
          <name>SdfEvent definition</name>
          <sourcecode type="json"><![CDATA[
    "sdfEvent": {
        "warning": {
            "sdfOutputData": {
                "type": "object",
                "properties": {
                    "warningDevice": { "type": "string" },
                    "warningReason": { "type": "string" }
                }
            }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-sdfeventyang">
          <name>YANG conversion of the sdfEvent from the last figure</name>
          <sourcecode type="yang"><![CDATA[
    notification warning {
        leaf warningDevice { type string; }
        leaf warningReason { type string; }
    }
]]></sourcecode>
        </figure>
      </section>
    </section>
    <section anchor="challenges" numbered="true" toc="default">
      <name>Challenges</name>
      <t>Since conversion between SDF and YANG is not always trivial this section takes a look at the various challenges that arose in the process of finding an adequate mapping for each of the language's features to one another.</t>
      <section anchor="differences-in-expressiveness-of-sdf-and-yang" numbered="true" toc="default">
        <name>Differences in Expressiveness of SDF and YANG</name>
        <t>SDF and YANG differ in their expressiveness in different areas. Compared to the other format, both are stronger in some areas and weaker in others.</t>
        <t>Areas in which YANG is more expressive are regular expressions, operations, some of the built-in types (<tt>bits</tt> and <tt>empty</tt>) and the retrospective augmentation of existing definitions. In YANG, multiple regular expressions to be matched can be defined and they can also be labeled as invert-match expressions. Both features are difficult to express in SDF as of now. Furthermore, YANG and SDF use slightly different regular expression languages. YANG uses a regular expression language as defined by W3C Schema while SDF adopts ECMAscript regular expressions. Operations in YANG can be defined on their own or with an affiliation to a YANG container. This affiliation is not always trivial to represent in SDF. The YANG built-in types <tt>bits</tt> and <tt>empty</tt> do not have equivalents in SDF. The semantics of those types can, however, easily be mapped to SDF. A YANG statement whose semantics cannot be fully mapped to SDF is the <tt>augment</tt> statement. The augmentation can be applied and then converted but cannot be represented as a retrospective addition to an SDF definition or model. Another Language feature of YANG that SDF does not offer is the option to place constraints on valid data via XPath expressions and the option to make sections of the model conditional with the <tt>feature</tt> statement. YANG, furthermore, puts no constraints on the value of its <tt>units</tt> statement, whereas SDF does only allow SenML unit names in the <tt>unit</tt> quality.</t>
        <t>SDF offers more possibilities to define default and constant values, the latter especially in conjunction with minimum and maximum values. YANG uses a single statement, the <tt>range</tt> statement, for constant, minimum and maximum values. Although there can be multiple values or ranges in one <tt>range</tt> statement that are interpreted as alternatives they all need to be disjoint. This imposes a strict limit on what can be expressed through the statement. An example for a conversion where this is a problem would be an <tt>sdfData</tt> definition with values for the <tt>minimum</tt> and <tt>maximum</tt> qualities but also a given constant value that fits inside the given minimum and maximum range, like the example in <xref target="fig-q-sdf-range" format="default"/>. Such a definition could be converted to a YANG typedef with a range that states the minimum and maximum value as one range and the constant as an alternative, like the example conversion in <xref target="fig-q-yang-range" format="default"/>. This example does not validate in YANG because the range alternatives are not disjoint. This problem is solved through use of the <tt>union</tt> built-in type. Furthermore, labeling definitions as readable, observable and nullable, as possible in SDF, is foreign to YANG. SDF is also more expressive in the way it labels definitions that must obligatorily occur in model instances. Basically all definitions can be labeled as such through the <tt>sdfRequired</tt> and <tt>required</tt> qualities. In YANG, only <tt>leaf</tt>, <tt>choice</tt>, <tt>anydata</tt> and <tt>anyxml</tt> nodes can be marked with the <tt>mandatory</tt> statement directly. <tt>Container</tt>, <tt>list</tt> and <tt>leaf-list</tt> nodes can only be made mandatory indirectly and there is no general mechanism in YANG for all kinds of nodes.</t>
        <figure anchor="fig-q-sdf-range">
          <name>SdfData definition with the qualities minimum, maximum and const</name>
          <sourcecode type="json"><![CDATA[
    "sdfData": {
        "someValue": {
            "type": "integer",
            "minimum": 1,
            "maximum": 5,
            "const": 3
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="fig-q-yang-range">
          <name>YANG conversion of the SDF definition in the last figure</name>
          <sourcecode type="yang"><![CDATA[
    typedef someValue {
        type int32;
        range "1 .. 5 | 3" // invalid in YANG
    }
]]></sourcecode>
        </figure>
      </section>
      <section anchor="design-roundtrips" numbered="true" toc="default">
        <name>Round Trips</name>
        <t>One of the bigger issues in building the converter is the facilitation of round trips, i.e. converting a model from one format to the other and in a next step back to the original. This issue is tightly linked to the differences in expressiveness between the two formats which makes mapping between them non-injective and thus non-traceable without additional measures.</t>
        <t>To be able to track the origins of an SDF element after conversion from YANG, currently, a so-called \textit{conversion note} is added to the description of the element. The note specifies a statement and optionally an argument to the statement. An example for a note stating that the original argument to the <tt>type</tt> statement was <tt>bits</tt> is: <tt>!Conversion note: type bits!</tt>. This approach is not able to preserve all information from the YANG module without exceptions since sub-statements cannot be specified. It is, however, sufficient in the majority of cases.</t>
        <t>This issue was also discussed in one of the meetings of the ASDF working group. The possibility to introduce a new mechanism for round trips was suggested. Instead of overloading the SDF file with information that adds no functionality, the possibility to preserve information from the original model in a separate mapping file for each model was proposed. Mapping files for SDF models could contain selectors that assign additional information to the selected SDF element or element group. No decision has been made yet on the definite structure of such mapping files. Therefore, some requirements from the perspective of the SDF/YANG converter are listed here. Generally speaking, the information attached to an SDF element should have at least the same information content in the mapping file as in the previously mentioned conversion note, that is a statement and optionally an argument. To also cater to statements with further sub-statements, nesting should be possible, that is defining further statements as arguments should be possible. It is also necessary to be able to specify multiple statements to attach to a selected SDF elements. Another solution to round trips with mapping files would be to reference the associated YANG element of the selected SDF element. This way, all information would be preserved. Round trips would be easy because the original YANG definition would stay attached to the converted SDF definition. Opposing to that, if the SDF conversion of the YANG model is used to be converted further into other languages, the supplementary information of the original YANG element would still have to be extracted. This defeats the purpose of SDF to reduce the number of necessary mappings between languages. Thus, to attach statements with arguments to SDF definitions in mapping files is the better solution, in our opinion.</t>
        <t>To preserve the original SDF language element after conversion to YANG a new <tt>sdf-spec</tt> extension is defined in YANG. The extension states the original SDF quality and optionally an argument, similarly to the conversion note used to preserve information from YANG.</t>
        <t>The eventuality that round trips occur in model conversion makes building the converter significantly more complex because all features of the target format have to be accounted for. Features of the target format that would otherwise not be used for conversion must now be considered in the case of a round trip.</t>
      </section>
      <section anchor="type-references" numbered="true" toc="default">
        <name>Type References</name>
        <t>Both SDF and YANG offer the possibility to reference predefined types. SDF uses only a single quality for this purpose (<tt>sdfRef</tt>) whereas YANG has several statements that are all used in different referencing contexts (<tt>leafref</tt>, <tt>identityref</tt>, <tt>type</tt>, <tt>uses</tt>). The way the <tt>uses</tt> statement and the <tt>sdfRef</tt> quality are converted regularly leads to additional containers in YANG or additional properties (when using the compound-type) in SDF that make instances of the same model in SDF and YANG in-equivalent and complicate round trips. If no additional elements are inserted, information, for example the name of an element, is lost.</t>
        <t>Both the <tt>uses</tt> statement and the <tt>sdfRef</tt> quality embed the content of the referenced expression where they are located. Issues arise because YANG provides only groupings to be embedded via the <tt>uses</tt> statement. Groupings are the non-declaration-equivalent to containers. There is no non-declaration-equivalent to YANG lists, however. This means that <tt>list</tt> definitions in YANG need to be packaged in a grouping. If such a grouping with a single list inside is transcribed from YANG to SDF there will be an extra layer that looks redundant but otherwise does no harm. For the reasons stated above, an <tt>sdfData</tt> definition of type <tt>array</tt> with items of compound-type is converted to a <tt>list</tt> node inside a grouping in YANG. Problems arise when said <tt>sdfData</tt> definition is embedded via <tt>sdfRef</tt> because this cannot be converted directly to YANG. Such a scenario is illustrated in <xref target="lst-objectarray" format="default"/> and <xref target="lst-objectarrayyang" format="default"/>. The <tt>sdfData</tt> definition <tt>menu</tt> is converted to the YANG list <tt>menu</tt> inside a grouping <tt>menu</tt>. Referencing the menu via <tt>sdfRef</tt> in the <tt>sdfProperty</tt> definitions <tt>menu_english</tt> and <tt>menu_german</tt> is equivalent to copying the qualities of the menu there. In the YANG conversion the containers <tt>menu_enlish</tt> and <tt>menu_german</tt> both use the grouping <tt>menu</tt>. This means the <tt>menu</tt> list from said grouping is copied into the containers. The containers are necessary to preserve the names <tt>menu_english</tt> and <tt>menu_german</tt> and also because there cannot be two sibling <tt>uses</tt> nodes with the same target grouping (because no two sibling nodes must have the same name).</t>
        <t>Another issue with the mapping of type references is the accessibility of elements. Only typedefs and groupings that appear on the top-level of the tree can be reused globally. If these nodes appear within a sub-tree they are only available in the scope of the sub-tree. Since there is no such restriction in SDF, mapping <tt>sdfData</tt> definitions directly would cause accessibility problems in the resulting YANG module. Thus, mapped <tt>sdfData</tt> definitions have to be moved to the top-level. In YANG it is furthermore assumed that every type of node in the tree is addressable, while SDF focuses on sdfProperties, sdfActions and sdfEvents as addressable affordances.</t>
        <figure anchor="lst-objectarray">
          <name>SDF model with type definitions of types object and array</name>
          <sourcecode type="json"><![CDATA[
        ; [...]
        "sdfData": {
            "dish": {
                "type": "object",
                "properties": {
                    "name": { "type": "string" },
                    "price": { "type": "number" }
                }
            },
            "menu": {
                "type": "array",
                "items": { "sdfRef": "#/sdfData/dish" }
            }
        },
        "sdfObject": {
            "restaurant" : {
                "sdfProperty": {
                    "menu_english": { "sdfRef": "#/sdfData/menu" },
                    "menu_german": { "sdfRef": "#/sdfData/menu" },
                    "dish_of_the_day": { "sdfRef": "#/sdfData/dish" }
                }
            }
        }
    }
]]></sourcecode>
        </figure>
        <figure anchor="lst-objectarrayyang">
          <name>YANG conversion of the SDF model in the last figure</name>
          <sourcecode type="yang"><![CDATA[
    module restaurant {
        // [...]
        grouping dish {
            leaf name { type string; }
            leaf price {
                type decimal64 { fraction-digits 6; }
            }
        }
        grouping menu {
            list menu {
                key "name";
                uses dish;
            }
        }
        container restaurant {
            container dish_of_the_day { uses dish; }
            container menu_english { uses menu; }
            container menu_german { uses menu; }
        }
    }
]]></sourcecode>
        </figure>
      </section>
    </section>
    <section anchor="implementation-considerations" numbered="true" toc="default">
      <name>Implementation Considerations</name>
      <t>An implementation of an initial converter between SDF and YANG can be
found at <xref target="SDF-YANG-CONVERTER" format="default"/>; the source code can be found at <xref target="SDF-YANG-CONVERTER-IMPL" format="default"/>.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document makes no requests of IANA.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security considerations</name>
      <t>The security considerations of <xref target="RFC7950" format="default"/> and <xref target="I-D.ietf-asdf-sdf" format="default"/> apply.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="I-D.ietf-asdf-sdf" target="https://www.ietf.org/archive/id/draft-ietf-asdf-sdf-08.txt">
          <front>
            <title>Semantic Definition Format (SDF) for Data and Interactions of Things</title>
            <author fullname="Michael Koster">
              <organization>PassiveLogic</organization>
            </author>
            <author fullname="Carsten Bormann">
              <organization>Universität Bremen TZI</organization>
            </author>
            <date day="25" month="October" year="2021"/>
            <abstract>
              <t>   The Semantic Definition Format (SDF) is a format for domain experts
   to use in the creation and maintenance of data and interaction models
   in the Internet of Things.  It was created as a common language for
   use in the development of the One Data Model liaison organization
   (OneDM) definitions.  Tools convert this format to database formats
   and other serializations as needed.

   An SDF specification describes definitions of SDF Objects and their
   associated interactions (Events, Actions, Properties), as well as the
   Data types for the information exchanged in those interactions.


   // A JSON format representation of SDF 1.0 was defined in version
   // (-00) of this document; version (-05) was designated as an
   // _implementation draft_, labeled SDF 1.1, at the IETF110 meeting of
   // the ASDF WG (2021-03-11).  The present version (-08) adds URIs as
   // alternative measurement unit names, is editorially more self-
   // contained, and uses updated xml2rfc conventions for its plain-text
   // rendering.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-asdf-sdf-08"/>
        </reference>
        <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund">
              <organization/>
            </author>
            <date month="August" year="2016"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols.  This document describes the syntax and semantics of version 1.1 of the YANG language.  YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification.  There are a small number of backward incompatibilities from YANG version 1.  This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="SDF-YANG-CONVERTER" target="sdf-yang-converter.org">
          <front>
            <title>SDF YANG converter playground</title>
            <author initials="J." surname="Kiesewalter" fullname="Jana Kiesewalter">
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="SDF-YANG-CONVERTER-IMPL" target="https://github.com/jkiesewalter/sdf-yang-converter">
          <front>
            <title>SDF YANG converter</title>
            <author initials="J." surname="Kiesewalter" fullname="Jana Kiesewalter">
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="LIBYANG" target="https://github.com/CESNET/libyang">
          <front>
            <title>libyang</title>
            <author initials="M." surname="Vasko" fullname="Michal Vasko">
              <organization>CESNET</organization>
            </author>
            <author initials="D." surname="Sedlák" fullname="David Sedlák">
              <organization/>
            </author>
            <author>
              <organization>more contributors</organization>
            </author>
            <date/>
          </front>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgements" toc="default">
      <name>Acknowledgements</name>
      <t>TBD.</t>
      <!--  LocalWords:  sdfRequired sdfObject SDF sdfProperty sdfObject's
 -->
<!--  LocalWords:  sdfChoice sdfAction sdfRef sdfData sdfEvent anyxml
 -->
<!--  LocalWords:  sdfObjects sdfThings sdfActions sdfAction's YANG's
 -->
<!--  LocalWords:  sdfInputData sdfOutputData sdfEvent's typedefs
 -->
<!--  LocalWords:  sdfThing sdfProperties sdfEvents anydata SDF's
 -->
<!--  LocalWords:  deserialize sdfType typedef leafref identityref
 -->
<!--  LocalWords:  nullable ASDF boolean
 -->

</section>
  </back>
  <!-- ##markdown-source:
H4sIAGYVh2EAA+2965LbRpYu+p9PgS5HHJc8JKWSZNmubvceWbZntI9v21KP
Z09PhwmSYBUsEmADoEplWQ9zIs6b7Bc7uW6ZKxMJEKyLJPdpRnS7RAJ5Xbly
Xb81mUxGTd6ss9Pkz6Mk+TbdbvPiLJlnzUWWFcn/fvzdvyVpsUyeffn1KJ3P
q+zlaf9Dy3JRpBvT3LJKV83kRZ7V2UW6brJqktbL1eQyLc4m8Mc6bbK6GS3N
f06T+/fun0xOTib3PhmN6sa09XO6LgvzQ1PtstEo31b4Z93cv3fvs3v3Ry+y
y4uyWp4mTwvTcpE1ky+hu9EibU6TvFiVo9E2P03+2pSLcVKXVVNlq9r8dbmh
PxblZpsuGvxjkxVN/bfRKN0152V1alZhktAU/mdapMn/7WZgfkqSsjo7Tf5S
5C+zqs6b//P/NskXVWbawB+zTZqvT5Nf0sJM/F93RT6Z44/TZabafZJWdWMW
7ouy2qRF0dts8vy/nuIDtZlDZmb3Q1k3q3Rxnjx4cO/hw3v42yJvLk/1OBbl
0vTz5eT+pw8+/oy/2RVNZZ76tww6vcQvt+e4yP/y8LPJQ7MB908+nTx68Nn9
Ez2XRTov/7X5NZ+aEeL3VQnUki3zpqxGowLm0Jhhw8I9nXw5zbNmRVtt/nea
mP8zP/z49ZNPPvv43mkC2z+CDVJvGbKZAA1Nnnz/3X989ePzr348xY4mZis3
2zX+3aTVGczektCiLMxSmU2x42IyNq0RRdonku06vTyrzAIs8UG30fDp3Or2
sCZPv/3hG29sdbXwhnfeNNv69O7ds7w5382nhrru/qKOwN328PuHfsh4v3n6
Bbx8um9AT7569t1Xz++u8zluhupff0XncpWu66w9CCHkb/PFebpO/iOtX5Q8
PCJk6sN/+Mv0ZW54RLZc/5//54X8hE9vyiqDOTdVPt8ZqqpHo8lkkqRzQ/Pm
lI5Gf/qD+efxvMqz1foyyV6ZDc2L5OI8bZKLLEnN24a0gSU1ZbIsx0k2PZue
3kkmkz+PRpo70aMXZbI209ylZ1mdGEo0/S+z9RrfP88M+zDrabrNS9OFWTZ4
eQQ/mCVJ6Vcz6+IsW9LPy+xlvjAtmRHBU4YZGdb0Yjp6XMO/8wo6TeukXCWG
b65zw6Kg5WN+LjGH0QwEmNA4eVo+HydVVm+nd0aloYB1uh0neZPkdbKrs9Vu
DROcmxnP1xn8aZanqIGRWl4MIzDtTkej5+avrWnLNJzU22yRr6TrbVWancAR
8zk0X5pTvmuS8/KCVgOnY5jDyAyb21SLtkgLGIbtfgnLUuKDpfm/amp6N2P2
uzVfFGWDC1gszSs0Fcs/xonZe/jyPFtvcWVHC7NwDW4Ld2RIw8wMiWOTL5dr
czWYC6AqlzvaLv68/iCHb9+MPlcfpoTXr/EAvnljacJ8Y44lfPFP4vgHII7R
D2lewfd43s0e47avzMM7M2GPJDRxvH6NfLkpmRjOTK+1eT+BpX6ZZxf4B66B
TNU2CtsHvYx46huzlzQHGIM8NTXCCmzopVmhOgNpJDMtGvYpEzDrUI+ACLdl
XedmF8c4fli4Kj87b5LFeWmIydDU1iyS6ZV2FBhn9qqZJrCpG5LN6hESnFlV
FMPMAEHeSBcg7pTA2vFNQzYJbyEu0tbIJWaO3/A18Po1Xylv3piF/dqcBXzK
yGcNkiSQsOHAMGLYO/jKTAH3m8gCKbEo+TqrYZ9pTUYXKRyuHc7ONIGkWMGC
w3u2gw8NlRgpxDS7qHkEsjQj16ZdfvP4fJevmwn0f7k1rW3X5nCZ1ctWZlqm
a9rkpsQtno5+oJ/N4DOeSvIhvJiU81+yRfOhUCUOytxhSQoUMTJvf48PIFFi
4zVPLBxC8iE3ZbZyXZuVSNfrbDkC8RNmP4FnYOPy8L1N+iKr9QZ9aA7m1sgE
5sr/cPT3Xbo2Ip+5Ac0FbEeJR8asy8q8xuwHR75c/UDvGspbp3U9xeOPDIuW
qdht5kY4WZoDuUnXjx6O8RyeZZU5dqWR9tJiDOInHCrYbJwJTrtCKh+ZZalB
GsqSY2j1DjWL9G4o37yM1IBdpVWVXiJZ08Jgg3W5yZp8Y06nahUWG9Zpnb0K
mn1SFgsj9MNwYNupeSMUGCICehh9WC/ODdkkIDB/qPYHHkP+ZXYJfjPLlyH3
/ZDWAh83rG9hxBAzFhw0PAbM2XCoAhSThd0QbMlQ5W/BqUiS30yfm9Rw77Jo
/eZ/frOSnuUW79Xnt9Fvk/DT/qbrM/zJd/Mxs4Nd3Bm6dTMevja4XUgFyXE+
zaZjvDKT+bpcvBijzFsbHdNQd0biwv9laGuVFzny+Tu3sFvB+Mzs6t3cm+Bv
ZoiL9W5JPLreGaYQLoB60rCAyt3fbrbmAPS9+lY+MLvWd3DgcnMtlRdF5BXv
STeb9/EDs4Nr3Wg55uLi7wyH2E7WRmbYN+bfEndDvY+frr3LEprdPFsbKatr
tr95FxowY3djJ8fezXr7hyzy6aRMkPxQAE56NvG3ZCtTO1YTu+PEAHNhGslI
8ZK3ugYwOyMQrFqzc9uFl3uwmfZJvXc0QRY17rIQwgLHXZI33vIO3vDe7Zna
295S2bt1XlvGcNW9kwGSPPc+fG5473Bi782xo71T+2Znd+29Qz0hN/Jp/e6Y
6W3s3fCJHbDLH11lUfA2J9VdjXnw2sDePQlef48+ODtQo/V3SH7FGZtkw8l7
T2ZrUo14D96zycLswHWADi/5bvjbMJ0vQbk0s/MIJ7jdUzIymMPMhE6aPdiT
zPdoVEI9NjMK6PJmZ7erjVrujVl6Qn2/Nftgdj9mK9GtQaZWJ2dRVmCtLIsl
kwEastwsuhu+wdlV20Uw5sFvw+wek+rmtod5LRPru9QiYHapZ/a+6uzcyWOl
obVzqdJG4FHuN6/NL2AwyYplao5wYZYCHr+h2RVl4wzEh8/uq5cRi8v78cG9
Ky7R7GS/G/42mvuc5eh9+/DsXm3UsfgHm93uzDPnHTI7fhdskOijhVPkZmut
tvwY+1/WVZYuL8lHlC3HbVs7mS23Pju44uzwZvLGTGZZywx8U7X3JH6DkyCx
DUmczNW5uWeOwTM7hlsi3a3NvZevkiJbZHWdVm9Dixg0O3jADDDydnDf+WxS
bnqRZ97+B2Y3b0lig98OZifz2Xejhz3e1gdnl/vresjsYsJ9XrcFM1CjzLGs
UZfKIGZGzpjzwCTigBHtgFV7dBhnEJwTjnTI7LJit7nq7LBTbEB7zwyD2SEx
wk29BLMverAsjSrBDd/laYHfTdw9N6Lew+xW7DafLPMzMNIeMruNYRb5dp19
v7Ir/x59yK5SnBmm575LarN+60x+qCAmIP52ssmLb/Cpu5v0Ff2lWOa7/sR1
c57dy3S96z39anZ4smIzrDNLiehl3dvoDX7is2Np15wViK0qMAQhthNaN6do
EP08Ro+8072F2W1TTZfXuRF89h9oe+/gw7ODFddjJsoMf2i/bR95D1lK0kWZ
wgll8F001JrdmNXvs906rZS3vEYPvLkC5zmIkztYPoiyyIGGk3VZvkjPjez5
dmaXoxg82aTN4jzy0uGzg4vPKOhGjbRzK7Kz9HbnxpaHgONbyuy+CuyThmvk
m90GeAb89z26DeAz4EY4NhwUwiWatoEUuWvdvKen7sZvhCxHPSjcUXM1+MuQ
7m36xmYXKjhXsWc6zj+WWwKjaVxA4rvQ3GF2+RJ0Y0dY/1izg/CuXJlMf8Po
JM88lzbJPFtguFqhjHq/oZx1UeUUlgfCSbpeiypgI1TdC9iSjWisXpD2YBvg
mBd8CuLUbBCsZVaHeYw6fEAr5QPCYKq4fh3M7r37IGUaNbNSAz+EMjniDOJt
cMUxFpnasyb12jclHduthU0syovAizC/ZNq+g5I56GTm2lzlr/CfLn4JQ/5Q
eSQbeCS0Ce+77GVOAsXhs1vlVd3YFjD3AGi4NP0kEjmaF15IMoZZDe7iWh+0
Rds5y5gHvy2LF1u49+CDUjTtu/tu+Nvv/exenyYfqNBuynX5/EiS2JCnUHjb
0ZsRxIFDjo55lrMEbDw8Rf8DNdooawg3p1CymDCjw0C7njlwMn64KA799/uJ
BZfa0MybD/a88Rbf5QeDO5er5+cR/+nwwzt4p5R8gT6+3/WH1y4aIPnPtev/
8NrZUCLvt2R/0NuBvVGo4e9/2fATE3Dtb3sisg5fVFq7CcaM/f4X8Dprd3g0
G4fa/f6XDT8D1u4GA/7+Ifnd45g8+1srLGic/PxzUTY//wyZdA3nDR0Qi0/h
Sr//VaNPP93lRW3E6sPXqLtFDkrC5YPcsfN8vbQhSZIoSYQZdWS/T0kTTHfR
EKbbkFG8UCtcM2Skbg051/Miq7zM3nX+IusUCN7Rh9fuSx1cZX+7BRmlM17k
d/h52zKKjQF1NOfEFnWCfw+fty2jxNbud7hs+HnbMoq/dr/vD/O7H+Mha8rg
q7z1F2nt25IGMzHhoF7Yhrzdda+GgWTvzaef7gauHSqpZbVf4SKdrPr/xV0x
cO0GH8TfkqMZpCrMjlimA3FEuT580rPNHoMvA6zbReYFm76T1FD/Y8/t33d5
FTgUB69faqmPk2y61pEcZOhGMksCaCmXCpeAUwD8RYSW7+pmEVTmrYVm9X36
ae/Ge0vMBpD7izxVrZwHIEbDEtnZn7aXDsiQNyCvolsgi1tWtrnUsZS7jq8E
TeXFxDr6vNZOkmOg+LKx4eN//jy5d0foLppldSv2T7UMFBluzuKCgFeWmQuZ
VeEPrWSwcfsRz9f5tvSQWAC5m+mN93bjLb7LD4cv1DH9+reA9Xie/nPD9LLN
1uzq3tAp3SI97I4EBWgOjlx9rz577lqcKZx0WqZr9wZOXX+h9MkzvCVc2+PN
roawk2SZ17/sikUk7uudfWDtOOGk/ZuVZoEpGa7Tr8RCzExMhTvPagE4cn15
tyteCL6A+H4E8/V/ECInCF2zv72FM/t7/ryLM0ut/o4PK3+Q7lzSh//bzffW
Sk75PVMgn9lW2gH+dvO9SYbL73nJ7CeWUmB/u/nebF//CIvHdPcUbkUgO/xD
frv53jzNB/qLqEG/hysWPwjEUOR/32W0amJbA4XwNzBcePAkQepN3rYJ9Luv
pS9FdpxQjDl/a4tvEJVaOFDYfgPZgrv5BKES38UHQ2sVrXm/3XxvOFlFYSDc
oYLuW/+iplAYpkqyjKWkvt0PBX/atNZgpjfem+dQxMxb9sje9e2A0cVrp9++
2yXkMxtl2bexdtDX71sycZ9YurP97eZ7Iy0POsyq1GF3+/nStTNFsbrHnC5M
j77x8R04G479jJmhfkPFi1T2D+eXTTahqXx49d5CQON5XqTV5dUbfKcfWLuu
JJFbiv2EdJ1/iENLofQqOj4MpYdzwmHpGEov36+qcqPj7KXB1x84NO4OXPbP
P2eweM4oYND4jOw1AgYu8fjuAGtUc41XTv0bWl5m5uJZTxPAFLeuFkFUz829
8zJfmtPeaqE2Qo5fQsCWD4DOTevT5KtXKcBW1+YsvoQ8lqxwsLuURmY6uUwQ
8ZyArmsQGyiDNV1mlbnXdoX5L1bCQbuTuGcE83xqVjeOvvv6A3O35mfFhLKF
3owoYHw0+gjncmrG+4wX85PpSXJMjyEEHs/KPGmmAZU+PlIPP4CHWwk49B7O
33++Ni/cx/V5mBzbzBC7kfo9RCOf0Thm6qjkgp69m9c7yARCwRQdLGpDNKBx
yilS0+TxqsEwL4c776F1QbKl2YpyrUUNixGOvUpLMDgLo8H7MLMTmrV9aOpt
B7uhgDb0y3KhNOVZhhNz8D9hl5Sis6c/Qo1DfHZJn0JsdEQxkZbYPvldexh5
sE5mHZdLlKnM0nOOtdpL2F0aFklz+uTRgOo2UNGMstZmeg9VhlnZWmANteIP
jusUJOsyXdYqI860I92nu6YEegXcfYKdz6Vogtn2RSPZZbjPtRt2Soe0YNR+
q12h760pwV1bl+yBU6jeki6pnLcv85SmRCEaM6w4VTrQgQvoxbqlp+YEreuG
Dy8XKmA24743X+Xr9Q6q41AlB5eSVHNxDywKweoJdl9WZ2mR/4pndzZOZih6
L8w+QOMzTJDitWhtDU8YKnKdYdBmCDgVo3w4jcitDROdcQjITEvpxKZS1lnN
WVx6+X18ZnXO47LMqNLBKm9cTRFi6AFf4poKUP8CLopcirVolkBlH8pklS5y
sxWwlBWVpDDzsmruagfFO4BjSGUApKHXr5nN4iv4xps3ptfS3xmrmteYSxzb
XJdZruiM2BQXmImvH5WSMOcJ6m2tynICizAjhlVW+ZkR09beljBtUtkNnIKm
KHoxsquOldWmBTjJcNHpFa+ys7TCe2pRbi+pVAlQ1TpfZAViLjBfkkOFAaSu
0APSp32VKZJetuc/zywpt7NA23wLrxRLzwELiTTgRTPFslGhHEwhHeGqzuQB
dV4Mw7R3lPc+HSRDL3SScC5FeTHlokTCdmCLlhSsYmvLWAbC38x8Lz8UCsFw
8zrYsAVoz8S7+Rab524hUxI/KkL/OM8WmN59BoRIkojtH3uzfFOuxe9QhXeS
k32cAKbs9SXbmxsabY1/mjxVI7HHu95tMbHZHAhzGqDSF7861qHIrm/8Jz/i
rfP8kqIIsP1p8iynp81ur8DtgWsDdAF0XTbEuLkqEs0YKOoya8Z+DSHNFCPw
e8Jxr8v0aNdaDEtiQ/R9qbqvEdekHsiwRqOnViowhNb45AwCH1XXIihY+wyJ
9E0Hp7kD45PqUvrI0M9je3ETnGHNU5C2lznczHxdO7HXCXRN3boaLtJLWi7q
1lVpcc3yQKKs0VafWkIMvNtW0xg4oVi3sbIjHV7mahsqzZQCBoIhMLMDORR3
XMDEUhRD1a3i7iUiODP9l7balWn2DIpasRiDxWYAyQFatvNg6oMjUtObZWHW
qlwsdsCVjeKw3c3XeX3upCCzy6IdyHz5zkhej7Tu4DK4j3ZVcQpPnRrWkm7q
01eb9WlRn8K2ncrbR3/03uYk8qP2L1r2SI6+Nv0+LRbT4CEWSPD9f4XSk1Cs
MHhG0bn3PXyOZGUB3440MJ7uqPVs8sReVDKayEPf0BWU/Of/DoZhWfv9eyeP
JvceTO7f8x8QZjRPq64ffv2j3+Pdu8l0OqVSiE7+so+8QeXbXdjJVKqQeao4
q56auI/e2Eb83T4KFYGjU9q8sf8YMCjz0+v2its7G95sL2nQEL7C1zq8oJY3
8iBOCB6z1BZ5iDkjPOa24sh77k0wm0LN9jXN93QgubfaYg4fXxxPLos+wptg
SRoG0knE/138d9FeYvjWreN/F3944l8XpzFa/QO81X7SO6XSQcezclj1Wf1D
7EF1EjqaUkfCPHHUWqU3o/i/whOB8rQ6Fr/UcJvSsQDurS5Srhcn3NBeZuu0
BuXizAwHDFjPpHrSyObdx80o95NjW2nJs6SMnhI4D1UxC24cTGQAHg71lLgU
IH5XwMknbZtjsNzXTsN0gopTMWUQnoz1dVl5Sghq8eKBSVWNKBEtlEnFXC/o
dIByT8J5rI1ixg9qiQHFr6ByFE5EtwAXu/JYqgucdbadzdkz31txwc5ZDdGO
3lytdr+kNKJRzqEUlBPvXKc1yoLSshU9sQKiIYG1SJl1uc7M9cpKml4uc2M8
sQmFz2QBRhGwhjjRfIwgafT+XvNbndyf3p+e4Mp9DJY4m6zYY4GDVx7hK4+m
D/AVxIvwbG9Ik1gCYGZHMxMxm8PznXmKNBv8Fcvw0fO2EqWHjy/GOMYXVP7p
mR28lo2VbORUaCVgtxRf7OnezKmydgKeycR+K2Ufk8chXBbh2KPYGaSNpmpO
7qW2w92HEJ6pSGRP/OekV53xOgaB8oAJn1xlwhZBy81B7INw0aB5UDQ152Zt
Kc7+LPcBQ5NnlpbSGbCpexiTveDwRwBqZCt+3FAxbLL7lu/+zJxbUQRF1Yfr
wS8kb6hhKTj0ePDb00cbsvVAtBReeGbm4CkX7rDsaivxq0xaPhd4QiPHYoyp
HxjMDzbLS8OH2Iul7jUplkrW2vPyIkO99zFjuUGJzbGFjak5mRd0ItAgbPQM
4b6Vu/XSzt7+JnH5gC6HtUTH9gS5dv132WIvv/IpJ2PEJbxYSQIMhCoKiyd+
AiEl5lzsFighyLWNPpQxOXuIhLz1BfLxO3c/Uk1StAmAfSS28+2dhpUXRThb
8gREbMlWK+C3L+GWoKKteePIAscYLJ4zDKChy+MVuKbEeltrT/fROVvRaA+s
ccxQ9WM/MkVZ1ixfVz8yuF+33cPpuTnp2+WWLCboi0Al2xMzoo6SyJPo7jpD
e+cmSwsvwEN09wpqv4san7auJrQuRyuystmEGPQi21JWDsHB9lprwpAqMNBn
NRVfMLR9DnJEj9lXpHbwFvQzc2FDB3PxlhJvn5gII30dapR/NSrl39paNl4A
dH1G1JLgkZMOzSV47H7HY/CxG3v0VQE8q06ePfv3QKfeO/K2BhD/JqYhuLHG
1WbPhwbirYVZLgwRZEs1Waebg4ogXflz/2Nk+Ef2xo+ri7Qd3XqiYhOdD7mG
TnqfwefcPb/3Wdfu/UHPXqV9+16gELcVRktNiphAc2zbB7o+sf3p+rwZ1uwR
3BQwXkpTb6uxrXZ7n9jT6+De4r1c6wgdpmeHfsEuXfsbyGJ91gqTsdEMEF35
ZjREr3qUHMPDA1Wq+6xS3Uf9SE5Yp1KVPJx+QtXINcyt0qdmMJGZi5TFuTup
pjayWVolL9MqR9plD8hsjW8p3z6Yc+vOumO8mHBPxlUXvDZjqsuxLRnvaTBK
ncwbrRuoRZkm37cLMnL+MUvvrA4VQcTBbaoU0D1KdfMSAGvSmv0JGGrhCeHK
y8fJXmRhwauTKsBjBpeY3HlTaCtBqEQxGWN6Wi9NE2/jWYMhSYcyuDElDAPz
auUO3bFUgumwYphx5ojsFQQGxaWdVpSK1wlRgOxNq8p8c24EmDMy48jySGAI
+5BnGG86C4TKUpGriGI4Eh1votFOsZlZqO/Vu0XgjQ+VPiQcUfElqwxlJsM0
iB2IuCRfWH33eXQMvBAgmmGpA4kfyIpvv6FAXrQNgw+3OcfVya0ehAQBwXzg
qoNNyOva7OTYarVhQI5dPRfOxBamqlyQMAqhB3kTHYPyEMeMYlDZ1bQzFyUK
hfmU3kcGm8a8WxCb7kTSVpdAheYwGs6EDJ2BPYzK6CloSPgkxhvxfXFuBPh6
QzU+s8ULb4mUlc/0X0z4NzjOuDiBIkV+tLlEApnhgGJcSYROrWwI5A2c8kqH
x9SDK3eZ9nDsxUnWqTyIy3hm32vpOEqHQnVvBkkarMutjAIAf7vKSzJLGFiW
1rnhIPNM8crwMM4UIoTlXGCyUu5uVbTJPGiOuyI+N99wcVpO42hXgaWGC5vR
3cCXletC2AvFc5i9Dfi/HOMO/h+azXz9y8xvbJTcfCmNxYLJqvZSPV1FZmdu
yvazjs8KQALzW10vqyHb1LbMhQDWmLOFRzLbED9R58rqd4fxrJZ2h+kkByh2
uBedOp0AdD2439a6KK/g6MVZRCOTO+Xk4R87JET4OPFiudtsLmMDcMMz+iQN
hyLT/xiRRoP2ujRQ12af8qn76nxIsQlzmuPPHSo1yxYP0DnVabOaJ756W9om
7dMNaJu0QbepbTplhzbx6Jqqk7AB0+JfbT/J325K4epuR2nmQ+e0l+TaDune
bdtrZeDzbh44eRifSZ/ubGfFKAodKvkRcBx4zLCcK56p21NCJ9/AFeBpoq8/
qLPFxNzZ2DWIUaEm2qOOfkLqKGYGviOd9Fm+yY3WuUYZSItLY/oXjk0kKIxJ
W3LJctZzSC+ykv6uQZ8VplySMIWgGEZKqVGwHzvYorrt/XNTgggpSm2V+KW2
H7FCXY3+ATXlL/w4/06NlDIx34mTy3YfU0sD8LwZrhxrXBpPhHFGUnJ7tJVU
8l+3t2+PnooVfLI1R4Qiske6lsKM+DcBn2A4v6oMxAqFwuYkQVvycZZOcFZZ
2SwV69zsQJ9UTt+0SNflmVNyZpJL7lrhf3oRwXDanT4Ny5ouzE7BHoGsfRnq
DI+DSdAMMA4fiQhtApc1JOqW9C+j+lXkp4LNd34d00lGVYPPKcVCxSgrGqD5
qSBP2H0veHSGLWXLyfwylv9iLTYRJ42ZXyplRiLOjeO9vos72gGi1AnZhIDA
tGNkyn7UNhHCTvwCGCOebmbrSdFZt4IO6JisSYvWjBsu5gidjmAGG+9OpWjo
wFfYJ28Qeh1IIDeit8/yB1kZPzVs/d1xdLTP0BJ4phmkF6Av4vixXQy0WeQV
y3wlymVO+zROShdg6rj5OCGm7gyawPzruqwaGcJHuM4f9e829m002hL8uMRZ
7GXh68a1vrvcQMDepihgyL1Bd4F//XRdIKgFhkEeb/UOYdbRdWEgYePVoosG
Sog7LaaKWcoaMict5aB5V40/KO/ioXAWEnrNLXXwrfH7vis8GhN2rHI00Iys
aPtFdlkjkdZ6H118nvk9PIAVm+c8e6WKwNABEc5YholG+AOmkJ77OS1oR0ab
nh4FDm5Q5kK/L9zLKpC83I7sArEj/x0sZC1DshXLcXy0puDOcMSkcDY9Lq7n
hYuFiFYo8qSCbUIlbVOZGJvelfRoTYBBxACTK+TUGKrQl65nqFNwLd75xxTg
f6fYGzpsDCKHzGDZ9SLwYZfd7Gr8yUFNOSoDTyfOlEKIeLbotf4oXa8/4sXJ
K5my1PYlfuInNKvdsX2nyUe1OYK4sR/ZG5fvf7eMkQ1Qw4E0L93xzjAeWHvO
J0VFIGsaEZ86V7Pb0ukoh4FyxpH0vlgCrmuKFna95jNLZnS4glp2RrtK+vCq
BEMtZz3rPRPkW4lLfOSz4csHY0nkjHN6czA9z6viq7ypyAcOdhXNw3ZmAYoN
X7ft0DvUuEHl9SyX5ou25RJHzslcvn3B8B6KvA9MjEwtR/m2lTEi64Pit/+j
B3l7EvymcaBO7gV5GVROCgKnem2QZNfedj+kjBEw5x4DnwUE0va7XjvNEa1g
h91uX3AErDRMMBqMH6xqPGjiCFlOt4looCUP9nSvVXDvdIhA9kd3hPa0K9nn
kEAPsc51mLf22Qoj7x2JxAKWt3v3pvdij7CMA49EH5B+8Y6I7axisuY54Jn7
jW1y0g83tjksrC57278J6FNf+HwHcoVRpQQzKqKEqWc/hkh7Drn0QzWke61H
UmytU5/aUfGWlyqtyV7XWtK2bgxm3hbiyrqdrD8Sm0MjDUS87op1VpO5yL4D
sD6IJKKgBUyfhlOZFS0xUxBMAQSRj/3LrWu+PPMmOih8vZW5SnKzE9KqbFdj
/LF6RkKBKUx5mS3MIqYiNzqzk8jTFkvAzrKlyYtZpU/nIlPIlK8mWABpz7uz
9A9e5r3OtQovUXnB3HJ/ARPeYUaCkwfJMXTbT6APpw+RQLESs6LPx3o3kQBQ
WdxVoJjDg0IKlJwb7DI7q4keA9g1aEfRUbD825zIAsOsX7JJTA/F6SFGtHsG
SrXE0rSQ8bp6kgAZUF6z5chqSFSpIYJy4hH2U5aFw1FpWV10TIHdcHgbbE0L
Eqhj6g5atL1s9vNMSq0o2IaWaz6O1xBT/e2C+HW52zNurYIeQHvZOHvMatz0
gEJbAeGS0q+tkNuYaWZNoP15IiYYHdqRO+2EnUNPYtv7bVaqSXcVKH4DfN+O
s+b1eZfzeb/YZx/dVlCw4LX2mnf6pfAluOnM4u4ifXfGMmPSVceA4cNFS3jY
gYP6Ss5ove5DA6FxlLB19sXruKS7s2VhIa4vc/ZIcD1yH273XmF1SNBwywF6
aGDuVSXK63mFgXS7F79fH8BHDvDu9+90OG7DaWHeH9xl4rmLb+8PyQ68/EgX
+3z83WEF3b8MigvYt6skr1/zQN+GP5xLxHRL53Gx57PkmGq+7JN7PmGHyBP1
NAs/T1oDnlGbWjZwwILk84A7ihyjFMIVukFsVypc7Hm86dzl6bGxV4PqC94x
QYbauF00H9OacQB3XoCLAfA5XMSxtthHkFKsHgC+SrI4U5MRh4SueJOvYNbc
L1rYup0hYyqYQ4tSpIsXQZYqX9TUsXd301ccZxt1nrjRvqOIcBoA7+yqLJcT
Cck7fI4BFINkqr6AclDmH5yx6iKO22ZKXg4rrXUSYjJ7kkLwaClp1hGhnRtr
u8nSWlMYsLulT2ciodu6TwDWN01+6kkD5LE6N2yn/Z6HRSBtrCGSnN1B8oiS
g7Yokb4xytBMIe4v7zeDDsY6Eg7q4guBPIKryP9x0hlfyJM2xFi07J3ykYmd
GyVpsijLF9kyHluI8f+dQq/+cFhglr4QAZXdCzGZ0Htpm//6azrwpfi3OEo1
l33D3Jrr5Oo99kncvPjIu2J7AwOtAUSpngCDSPsiSA1xNb8a1jVsnPjKPIMt
3/t8JLIVBgZx7ZMCw917hmWmuCjh0YM7iokKvGA9Ur+j+10tbhlZZjn1oRG7
I8QUUHWWcVFzSGDpkTp4Nyl3wkEdJnnutUtHDvawFMQjy4GHZ1KqTg5Lpbxi
Cia9C2fX16WYAPcF4OrPwOxJ7PHQDMoD2j9yrPUtriDw264VHL4u2BYy/Pd/
N/Y+tSd0+0pum+uoYHiB7IlwH8oLHFvvZwUHsIAj1+YwxnUFej2yF82V6WsA
XR1ET/tC+PXNfnvrApf89Y7vEYsW78/CHmqPurKkcSVzhBK9OywSP/7wpMsc
0eGCeZgcV9tFryWCYjQfcIwmIWU9bsPU/5htQNnABM4lZCwCzk6dHJsx1Xds
5iFghJIWQsG7YESdmRFY9yHqRRjAg8haqLfN8mK7MyqWyuCGOHwrhpUbsP+C
WmQeIwsBDFY1UO4abMGW1IX36Et8Hp0mOCIYrgsT74i7lxzonKB0qpTCbFJe
L5kdhu4vSwEzLUkvTzXOUyT7MXDT2NWuBfFW6/n2V5tAu04XuMAtKC1QnQVn
iLIUOtLnHZirBzlklPpsm5n/Q0BjyqP1ZpLxBmhrA1BkaJkRHf8pPE2OoMDI
4WZl/VHtaMuvrDFBwPf9bVYj0NnXsB742JecxeF1OFYeMHACtbsVtzjZ/TFo
LVvZkC/oLYroFjq8PA+v7R5wimjih1oVTz5OjlN1Kq93mGf0XRjceVFWL/yY
Y312eQkAk1A8/pcujR/AuJGo4KphrF4bBT0H2nmJSrOHpI3jxI3oYAkYzyrb
rvgDHBEBnkI/pQvtmuvAajmy6PVbrfJ1niq3v0fc9iTYoEk0dslb6gwawgQo
6ip/CfD+wix8Hk5dwtM+ypk9rhSMuV5TdgzbSdWvsGyUxWIZhAI1e4ohkTQ7
Z23Vk0octh8aPSdRPAwCmd7VgvYWw8SIYfSRqZD6f/OGjqdeqbhRzWJbhyBb
U69BiUx98wbDCiEr6wKm+5/ffuMlrsMNJJcEL0VraBZG24zDdHyBYcWAEY42
YHFxI7WNdUM6GFWBTZmzjvFpM0mT9mkKwgbN3oEFkiHBFg3U0UmZ+cxgKZis
oV0LVpE3tQyCnpmk8FilvdiKoSgwRhXFK4jdDLzN2+muUU+8CJapNwKSTxHw
jlOIvc6KGsHfhEPTdtDxlwFRRYetl1Kv4yIcsXnIkhiWbjm5vUJajJwDPPQj
0Vvk+XkY1tKE20KlPaSotYgZYYxEOBcasWoaof/Jdm0zJaC5mLV/Ovp6V8Gj
G2RVPZG7Aytv7LksazVx6IOzQfbfl9e8LmepumeueXGKrO0Wn/0SCt/sdVdm
fjQuFz4HBEfw2uHx7NCiiHT22IXlfO/vsa1yyIdl20E9wcoCIP41utyv9/Di
HGhhFWYbs7D+yYge5lqva2gtX35+dHLv5Ch5tVkX9eddiOVF1gDOyunc3Kmn
J9N7R3/2Bv4n7q+/EYQ9PwlexdeZitTrTIKn9MtklVabyIv4MhDZn9NtujjP
Jid/uov/jD+J2xb/zf1udvPP9++dPJzc+2Ry/7PnJw9OH94/vXfvv/501/4c
b/1uR/N/ukuTCJbsLq2Z+9Y0sF382d+nCd2uN7xbbfI9eOVbK3Ry/7+C+bV6
CaZKc/tzQOlWDmESD2UTRd1d2rz00udKaLG4iAHnyHLJuNMBJ9hh+Ante8z1
TXeFGQ9LgrjCAF8fNesd6Uv4mkFMfdH/h7WET3YHRPXblnqX7CojcY0a+roN
WI/hZrDbszIfGtblBynxzneFKQ0YQbSfI0++uS55tnjF20iY2H8hR9reH/bW
e9SGrMeBGSPx7Tkstm+4JHITFtivkVUnJw+AW39XNkYNW6R7rDf9RpxHyXGh
2hlgynnIphwKkv/qpenTs+SwXdOojbphndPhW2f0U3JfQz75dx1vt+R1HEIL
oh0SLnXETuvVPlUDm+wzBe5RMtozv5qqgeMAE93uDIN8ena5Y38/SY5Tenlf
8N+jKRTAULUwoyAH3JgOzUNjco5qJlmvY2Zem+QLRomlbAqHogHKGwrgFPHu
0FQhxEmKlJWEFCgx9x6uOo9Khc1ny8RaklT9E5s/0qGGx+YnRYprNp75RjYM
z7eFMBk7kconCBwjlwBtynKtghgNtzPt5L96oZ+1LcY2hmWqbSxj7Uq38Cr1
jNivsoreB3xHp9RKYRa9yDqjf1ludZlBCqw7tYF1bK6nxHi/Yq83vK4heiZ6
V2WXHuQcJQYB5LQIrhPSm06sk+cH2SngRZu3b2tB++PAcgMAL7pEJsxrJMUx
urItuIlsCcZI76sw/YK/5hjOp5Kk0650hylHpV83Zw4BV1zke+xxErfVFnxT
TyvkiNiQgl/gaYJt3QVW7jsjeCRqxEJdIxrVqr2cTB9YaBA2XiMAXJyXtR6U
Smmx1PAyzdeY6Ia1f8/RfOosu+iMmiZf0OkcO4Pu2D+pJeQKYsEDXNPsVZOh
4V/hTiL6Hyw8JDI1VZlKWYkGC/z6ixmraUSLYk7/T1hktXV0hWuhSdzmc7QW
rK8qxJg5rxhbUxAryN1I5xipIEhFi1yGfpKRSqqMGC+HpgvaNs6z9bYv0tgQ
PTGEXVWhvZD8ilKzg28M92Jf9uEYQYLFmwpFHM1oqtwwiUJVGW8nOIlay/8c
DvCZrnoANJUMKOxgQKIPFRYBlmTLt7YPkNbXxXVl+csB0xAiPLrLS3DUZZNM
be1xgtHss9z1LMGwZCdlkeMBqlBnz2HXYcyQ/oclQu1DaTS7PDiP6ShYqD50
xz2hTJZqACKgtb3dYU170+8HKC32VrpeGouoLI88H9CgVz4BGn9cXNr4CvP3
q83aScF1l7LTKRLXIBPfw8bMHyfDheNBsjENlX3EKQ62VbxdVRwGPu05suvF
ebbhpHO6Cl2xJUiAKV4UgGnC8jW1RJDgPmg2icpnWQE1DL06yzYZXMB1tEO8
r+jQuGt67kLxHLYQ3wJBksuxJ2I15z400kCEGIZuHppx4oYKcHN6pINTE54D
azssu9woxHDs9iZZ7UeSozIJUSQ50R8EJhGmO9/l62YC1bWqBCAQsYIxjB8f
JhwCggyC5WBlVTKZv7WSXV77Ap10KRqPCHOSfI1iS4hoafUi2Tt/ruS0c0ho
fkUIEPHbE4hXMCc49XClPLXC1eH0c87DNPJx9KkbyijX87HSvTdJgrI0qwzm
ba+Mmirtuc6Ks+a8lVEuL0YEevJZS4DB3EWhzbG2BZbMA5E3PGzehCwMtpUF
PcBJIFeu8W5B19pARk2Mpjk5CeK74EIHvzTGHsQ1c+SFfsM5ZmsvdrqQmMCf
MR+wBwNHjg94OVMUIgdjhCKEeFUmX+A7T4sEOYCtd0MXaRRnOMoOPkP7GL50
fYbAML96MjNqexaNdUMk0ujj5jLAP3z4vHmmKBArPSC1IX3MAXLtbAdpm1y3
DS1sgnkZkqWH4cpWoZTKfEAeFT0P8QXr8gKDRRZGd4YUTvtLkey228hPiUVY
5Hcp4jL2KPCRjqEh/5HxYXFvQ4gFRngZavoFqgqEo4WO+a/KbCKjZQryGkAd
OpTDGduo2p37lRQRs3G3cZiN5m96pwYlPNuKfED7VjvEiXbLspNWt3Xs1c6E
wnowBtObCwcNtaMlzQC/4Z5kbvJvh4yYZ91FYsm2wcdGmzt4Rtba0RolFnJY
UUkYBfAn9TPC6e8brrp7GGRSjL8QY8E8p3t1XdiVqgSgiCGhas5qAp05pfb+
XnkVoFmrHpAjKhuL30olatm5vaOiDFOZaUC2/AwsUZD/3LPul3GruguFPJzO
FcObbbGwRxEe4bnzICA4eoQ92XBQHQ5HXYgVzQigsByA20nd1Dp9veBCMJka
hZUL3BggSDITc5csmH932dbFGMOAj8SF29zX8FtLaPZdOLiIvqteI3RNsJYj
4pR9GufkuE27seg07a+0owQUSTZnaLu9xm3zzrasc9x0CGacpOdG+J+GbMDJ
VC6JG40J1sUi95pf9lEYgh1mpGyaj60dspoR8ilVYeYiveS3SYqW4qd86soq
P8uhump76oDBQ2F1aBaWzGwyWHEFqJLhtjDM2IxvgvSmqIGYNp79WhD9NblE
TXQgyy9RuiyyszRYbHf8wgF3x8vS4HBsHpNW30sNr0CLs+vjRlxQDa10AWsA
ibKoUyWoVI27XnIAuLjjEYWwExdXiadKaD0QEteaPpAM4wV+lJ0rahxDxnt0
Mp0+jJTs4akmR3+9N/nsbx/1PpFOfm09ETPO8Fj6cC4xitBhjboZjFsswTNR
gEogU+rMM+4GyxQj4tXQMmVAtFRRzEz7CK5VB2Smvf5NNw+7wBvtE3H0Ru4I
Bnr8Pz6nEd3hHeoBe4xZ3Lq38GpAjrC3+2K4rkzOIb0C2FW5BBGo8nhZNwSX
m6RiI3uJVWMbBiRLVFlEWek7I80YEWiaOf4ffzhmqrkzvXMjNONz5RsmHL7T
xqQVsfHQyjbmUkkrlQCn248JYE7IcO5zeNPcDo2SgwjOLCZeyNyIn9Ptb66/
nx48SZ6RmdSIAGvSddFZXSdfPfn2Me1iVGVNvgDtsaermqu5k0QlqN3s0689
O6rTtdDY5RyeBb1NBWaAbP2FQ2PtQopeSu4BrU2d4y2Z106sgB7OzC1PuD4r
itBPgMgKjpq/LE0fF7Ce4KZGhs3WEIBpSav0rEq35w7a3mbsgA5uhk15ekQj
T796/nXyXdZg0tVP5v9g1BjpggUlqwzudDyGhsgxqWq+joqGZN8F4XhBwgK2
yG6bZZWuGpTCTfdnXAgeSQPf0nUnKQSB8RfNRt+VmCguCDAafWmUs026fvSw
y25jpLBHD+Nmm07LzYPkeCnt3oA117Y1C4wyyqzbVsAJdH9mjW4IqfrYa01+
wkbO0bvpYAlnq4riziZLI3O1C8eSk9HLKbIeVwX4j++y64bEMOzeSFVAXKYn
ZQyx5vd213EDrTU2sEDy/SpE7mc5H9+vRbks1zsRA6U4wTiR5DLSjX91LhGu
jrHMORR6bggcgHt5kqT4iqJC5KIlYfzGx6fli8SBjUXiiLo2HYK5WL0NdzKu
C2KEgrSKyn3bOnEJB7VtbMOpxWxtc5CAo6Y2/GWQpU0Za9vDspY2patbo5vV
6Vr2NjZCmO61oS00VbxAo3a15PzCdu/7TW3S0Spu17ZGklbT1mqqfANoR4PW
rWfNs2Z1G9hgKG5i9K/AXSIHv8PIRifS2evTNeS6zzaXEzP9uqwmOIaZPMqE
e7jZjeYopuUZvtmq462Ch8ZOGZczooY5q8pyMzErinm55m6NDhAPO/YbMcG9
Z7a3fUa3ALO3Obck0V1rO9jEBzPbhEYDvpo5z+7n1Sx43LpsbXh+IruvRhXs
tUcYwZzvz5R+Ls5tyzY7qvF2IPyi7Bu031WY13bREbgR3G9JpIgvfGiVjyYf
35vem05P4D8R7b8XyDgy6Bj23ZVG/bB31GbEZs9uYLwPbmq8j/aMF9Z4ei/5
Lfn4ausccqWbGvdJ77jvn0w/PmC0ThlEweSgSCo3cE8kORw2eg96sb//3eFP
zE7AAvNxtMQGPUUMyDw16XvKipDmQfPYyZ7AKJL+BtYCCQ7gkBk9mD74DD8f
3z95+PDBo4f3s3958OneKQ6f4L3bnOKD7ikOA8s6Qur+uUSDys8D6lG7letc
AvesXa6o5c5/trVsnQtn39m3gPLpS0/z5t+PmojPo9xgHvv43c4o+ksk2StC
QiH77CYhmSuwvmHUfmVSH8ZFbwOr+ykhzvt2ia6Axbgd4n5yzLj117NCSEoW
DJOjdT611XKahPsgH9QpAN00n87GyWwnf5j/njySb+gvLMIgX9Ff5g9QZVEG
3dE/pslXqQUd3rT1IHT4cfczZeQIXUBKy2XJEYyIHDt1ECrFYxuaa1EpOhQx
r1BlJDbKepjVlCj+TWKKwniDYUK1qPp2WTq1U9pSjONyQS1UMBC5z7hT/fUi
OLj+CBZ+8RNAvrGY5MpU0Y5FGrvReKTkWQF8q0ZEaxc8L2ogonkHrt74brP9
ZpBbT1UTidra++vIQbPWBY6tdEtVt+mXcLPo9oXxbWkkkU8efmpkkU/iDjER
s+xzEXmlv6JG3GlxtSDyXmfFF4TZ6HPXOHON89aPk2PGfbyp8DwekW/ihQAV
BLziX9kkJ8ZKxohn090MSslQkO7KnJtsZhNjYgF+M25zxqGlLhSzKK2rIBaM
CUZSZTk2Z+WLvEirywGLGV/LT81aYgvXXEodtkINojlM8ZcgqJEemvkROU+D
MGVNU7F4YduKXVgvJlnXerZBlE9d5VQXPPy867X5ZZNN7Lts/uUJukiewD5v
I3shx7CpbWSjWAJbsSE22nlILJxm7hJx08XZ3QKJlbqTqbeixHi8sajFQfxc
AocMkX5lhDzG8Rty7LvJ9VFynLm2bic6V3Uw02H7m3TLPm1StAKrIwB08Q0o
fgktsaA1UXziinK8tFew30fO/pQ8pYGkUNBQI+XYZMTuSOI81cRqV2YjaARz
75j1FVwiuVy5WNbH6zWPMagr4UphByJg7azd+8pjo4RohqMkMTJIKti6zmCg
L+Co7aOuHi7Y7K0t2E9PXo6qeEzSMJBd74qrJo9G7HnOQTzkvKaYPHDIY4EZ
FydsseVaLLWpZ3yZEGolXhjBrRZJRGYu5OWLUi9wyVn8OQqp7Kg2QyOQaw0T
IYDgzZiI1La2tk4tNnvrmETENIn7ty/w9NUPPpldtXZJX6FnJRq6Je2HM4RH
PK8jfNEq59wvyeLOtyVImDLgAUzSZbrtwmfTp+roBDJ9LIRAgu/x+cwKcPkv
x8k9Or8XeR2WkJaPXfqI+bNtUIBRzjF45nKC3OO1a6BV7E9eWOZY8ZQtV/qV
ewPSUXG99kn4VlCLJZRAC29VzIcOuyKPBqDjODI4CGH/ixyRm92GniaHksgA
HCdBYY9boDrsP5pkrjWn+7c2RJ9IrzXIe9cf5CBLXh8CUtdJunkV7y/FIEkv
fhlDOepdMUS86y55RwFqBd6emGhgr1pPZrMuzkC3ADGnObd+9Bm21BUCZO98
RJ4gpAL/ScF7AK4loep8mTCSe0e13WiFPe3XjiQt4lh1kIMnY3jTxxs6vIyV
qUsGbzed2oarDl9VQdwQgChQ8R3KmDKnxcu7BT3bKtTQqV/0FjeWasrZoAoS
dqSK3PBgWppTh7+QARLiP0oRqb2HjLoYdF9hUKXbxndnlsL+Oy6s/X4ky8p6
eea1mDMH3g7qoAtKAdu/gudBCPCG2eY35kcjuiOlP11CnGhzCf8e5IcYxlw/
S47X1Ivmrj7/vZcc5673qxVcjyvXNSWzV5CqjfYN1c/Mw5dzWds2AZ5QAir3
kpfA7WP4P5fwmAguQkc181aB8jrNl4dllu/FO/AxhHgpvDnhQrh7aDT6arNt
Bpj3Oq7Sk+Q4gwaup9lKypQHPJF7CatueR0sPyfNafIPTS0wNqOyknlizZZO
Ns2LrZPzvOTipO3LAQAKUOPhziXMeADkKCb2C2dui9CAKsvnlUilPCajH+Kq
883p5PMp+OMoFnVCBxRTKwaatPbs1QNwGXLjuW3c2zkKSo481ROe7J0oqlWx
Tc1sFhj5rVGGUzpikdq5Dkkk7ypxutoVC2vrkpPm8CQIBUWjRIU5d3Z8bOxZ
KPB/DigOYCJNgwLapwLPl86gwTNZ7eCZafI1ksjFWNvR65joxVa61pKii3Mo
1r7zHCowOD/XbYhZi/FMzIv7cUL3UNgDAjlZXoenOwgSZw4+5xIL2121BbAH
V+dZY2X4eZNkUDH3X63wOKKmSwvQGWIQUTs7wBwl6vWQOaxJvRdmhEAsLZO3
1Rk0747hhXAYbjcWiPPGSuUGC90RgQmJ+FRvBSMkOhXD0/jy6aWwDpDST52w
0E9VH4PfjvuPiwrqYu8oHo4nzFoMUQ9x/B+L2EgTUxGg8sxmasPCIGAJuu4q
SpZiW7Z92JMd+H5XeHhdFzXX5uILMubjMbwlDhtrbaVq7N5coDl/7HrMl5J3
FHIyTdjXAMFBcuocGpx9G9mtH8UI+MhpCy7c6Dis6dkajZ092R8NxqjYp3SG
+nWnrkqAB9MyB8aoTEZqP7js1v2T6QmAkcHLN5CcRA3FwKasfwmHr/3XddtT
jRYLFnoJrIQa1m5QegfdM1a+9fCFIoOx5AiUmS4t7udFlTf4D3plx35Brqy3
6mpOjYbH3TOczlGQhRp/5h5FSsTKWoZUqohbVsbPWovMwHPKDho5rSOdC1d1
fmAflNgzz7CUHxtTKo2AMmTRwjM5RzHX1nVSwxCNx41bCk21BndJ4AGmAxXL
oNIVKaUylwJAEc9flPVotWAAwbFGAifXQuOB+OmfI7XjcNWntX8hj9E8nkTq
m41jwBW6ttnYhoy0B4dxB5Q7gj1CrbZu7HCuwdgzC3e8hxAO18FyzrF0Xr7M
EDjLyM/1VRgZmF7x5RuBX6Sm9uDmcZYqYD03lC6nCAjcFxSKw0oGICqb5xeY
b2X2t5zXhg82Ge4EQ6dUnKnrXOgkjXHVQtE5gWR2tYpliYw3cv8eAIdx8Glo
OlZtgbMn/+hAuMQf7QXZq2B0UgJUhZUmrksMKtoVCJtb9ZQNPmLnu01qpiIX
i3fLI0AN2rnNISsXO74IbNlEEMcVOyErvpLtiUH44Q0CoOIy7K6xv8r2zZuL
mneLx0VXYOi+InI1sIRvd3UzBHg1vsNY+HNjmugwGCINGNHenMq9Hpt9299d
etPIeC9zQCu1sN/5ZsuA40vmoQxF6FkJnnaaNSjr2vDWYrVbr3LOvtxBciTI
RjCdmWud7828MNuWL1NESZ19i08T1/UfR6aFJSZ/SA1H+UYAETycKwgYWkKl
iSyxxXLdBSWmDb7VDKWv81+R1kN8V6oUCffZLkanrXCcwTiqwiDh3smqS4fr
IPzRTKE9R7hM/+ez77+TlFb4G57AzVCQD/I91jEoNxk5kKRpz3bjBWtX1neG
wO90pLGSdM04FdYUxcEpvK1qo1Rs1Wj0FbSD63MFBnjyWXKcSQM3chfa1mLJ
y6GtpRTwFcSVutBwQGIPIL8D746TfrqxhCOS8GVmJBhmKIkdoFzObFFDfBAX
X9QXqXNARBjXnTW7WZ7tMu8y7IY7jS7ieGiA0PNzL7WVR+ZN2wdMHo0Eihdd
OyhdEAjv6POOz0jkQcG4ciQuTiNUeOXCZxOowvY1vGRtLe/LzEx/TTZOdxdy
s8BmDPeEIqWMYGeJpDaM8PVr4erkYiVqRPpBi+dXgpmAMuccABiMuMqFAqTu
BplMigxOYUrxYmZJzWQa0Rqca/apulq/WJeLF/GSOMHxeQDKs76V5/CqPj/R
82kuL8z28Q3pj22dGzYc6cIoPs41dsNyh+FSqQ1sdqAV6PcbS8kLo++U28sK
TdIw+XW+MITjNToGCZxd5dgrny6p1eEPSEqEMIk0ymc+w67bqfLMJtBO5jEC
WgwiFKC/sZtAgLI4zwQ8akkGkbW1sDC2BKgyiZGpDU827QjeCG/34jyFZFoo
Xn303z8fjZOjyRH+eDQ9ciorL1nUvwbXrL0HCGDmI8M7m/PJMr2cXGZp9ZEU
Tg64gxGcXuYhCxWNAsbgIw/uFuccWsEYjdZBO7M7ydcH72ULmtTyug625twA
OgGtZlQiFf1v7rOcdJbwqLaERrP4Tqsdjb4ze11vU5DjifqHnKraHKv7ODUj
xhfSguVKe08XCIf2tU4JEQVEENiqpu3PUleZkCxNQzhjXvjnIa81JgnQ3DEl
a6brO+p1IUQ1K2CqohhweRjC6tequG/6dSgT/qAIs2dmf3AULGfYvfOXH59S
UhkgKxiqA56tTqaha/MEU6D/QM6o6xZMHeS7Vf4K+G5Bo6xYRXQaTyj/BmtX
77aw3nio4bSZ23BnDtrZupyj885V6VEtgavLYo0QrJWcNfNUamj7u/ZKUN6a
WLlSf0VcwbXWi4hYCeH25Khz7A/E9pLqmwelGezFc8pmeiS2GWdB0KIpA5bq
U9vwkemlXLhmF9AFMgVNPliEKy8cc84rmiIbZ7A1hhJFiwBYpmRkijExzgjs
7io3F6b5KduO+fqX/vT9RBeP05R4Jd3ywtoh3XREe6f+XcDyDuxicFpE7vGH
UMdCK7yF9vNh2vFd7VUIoG/9+XC5qKrxQsVxLGiv47e0hUbtMDJuOzKVUSVV
tgIEHEabg1+cGdDTGJ4tV89RW/lfRLBRs1nIaKEA4yMczCPgmjW3sY/Ffowe
AzJBBjIMeTmwFc+ZQbJK05Jiyfmyzl6Z71/mC2Umhbs+NUryDsUhVw9ATJF0
rdvvOUmF+4b8FPmzjUlD22GnwFVHGB7KNDEBopj50rUVL1FHhrtfyUsERBsA
yYI5ENV5GZRSdLRMGiLcTlDo9ypfuBYX6FqlWvWEfttw0jh1RGtD9MAm2y6C
6KSIEy7JeYIUQa1cnSRmdiSz1p1GMnhOQYVoWETJtg4F4LGqZ1aekalVtyUL
D877jNz3EokIueTiXaM/qQQ0n0Fb8JOdrC2oMfREVQDuzK4Xw1EhJ+6pOXq1
S4njfyqT/mO1H75vJY0TIHCN3LoMBDxLypWYIUyT7xsOgQ+s8nxeAoZqJEOw
MSjY3nPK55tIXJMbv/rKU8UaFmTLnau9MWT2nr0IsCRRVq8M3WOsjRcTo21F
MHWj2SdYB4ZLnBVsRWeOjsjlUu2yuqtKX0IsjX6sDfD4hEwd/8tKyq8/MNLT
xOzNxPAhHH8b3TGi+O21m/AZgUDNj0LLJAJCWnHcOy2txzsCZILnuoIo2+1B
SBcE9PY9BX1mldnl0mw8ObotEGRbVuaINKd8iDCAR9ZsH+rcTvUzz34UrtxH
IRI/21adciuqvydKWkRMu5ie1tnKcxagRPV4ABgwM1JmtvZayc8KVKSEH7PV
FX3vi3QtbbvAN+FG2hOkcVxl2GEYZyAHczECFvrx9JUtxkeqgq/4NSCHGyWR
grhszBc15KObT9VJsBKRjTDxoAAdW1QlEI0AaU19DWBypGfAzfkEdvX5vGVW
orvLrAZbndFwfsF0pEY0B92KPPaEl5G2wjlsjQBszy8Vgl8R7aLh7SJbr+G/
+uf7Ha/c9yP7Hd6Jm4lD22jF8T7tW9x2QAofeeHysDDWpKA5cSuQjE2y5BXe
lrkqmcRtmkvE7Z8jnEjNNo48VCJykP6v8S7ZD202flcVQiKRIkn+W+pvHFro
BsdTP6OiYHCD46K6egz9W7x/1fWVTGUjKorsnqibM1cF7TQh4gbY0PFWdo2E
FXZPSCSUH23oOX3/GO5678dgxj0k6vv09VH1trqzAOx0pNFgYvkwHUuZhlVh
A9oNRROquk2iSUCsGOTuV9bWj4PjE8vySoBCWqhaokpUboISE1pP06wpDIKl
uhPpy9IMAwCMKZdoabOcLecnxfrYhmCwJ052/47bfmFlS1C3kQQk5Eyoeuzt
vqV1JAt51v/pgGNQYGwHB8ynks6zf4vDEABFOI4MJLYe0qxAtyd7AWn4Rtl9
kZ6JxyWgELc8uCzmSNGriAyOFmcn9bPXwKsBz/r2jtyPRlM2sxO7slIX0H5i
7UfWpHQMqACpvc/xclPTQgMfrRhqIHeIEHHNmLxpS9t+8+4FxHPg38vgIHMF
jwvOertIAY9Y6k/bgFx1CjQB6wkHi2oJ2UgwhoLSYgFATGndCF5VumjAB+MO
aitikxahr28zB7DDI6D7YSe3rQPhsqoAuS7/m7XJKzbTd+D9NoKQebJ2O/Ju
LsrYyceuoE2yg+rQcS2T2fPaZvDeSb4ii0cZz2KGAw7GbqE96rV1arcwx+Lc
G9pTF0Wv8JbEAnudblmh0qolEmKOfIGGoDQQxqfo4xg8fzeyRnemh2KQkiId
z05kZ2PPI9IKMOf+9D8nywwuAG3f1XfGfgjIIO16D6TjgIR/7/nHBw/fvvpF
x6u9b3b/2rdiwZU6fNHQ3rJvzXKwehw6mSEbfOsD3r9JB1EPvnEgBeE7V6ci
fP1KlASfK9PaYenAe6CN3YNawdm/58TqYMYf3LWs667Hpe4yM7qr+M0+DuCK
DXFZqmvRsJrNYSP2uNwhp/tKvYUc4rDzea0J6k5vLA2cRaHuJHDlsLOJ/fwS
3uPOsMHj1bKNTvdn0ZslkW+xWZ9wo8j5YtpwhGnWTwMbBJO0wnFr2SLHBGpH
ZtWpuHDcndyGSwANf1Cb8OHsE0wniOMTofngcf9UvGe/2P9sH8R8a1luYEUG
TmHI8DsGG5y2648XDTXtZocPzZkLvMM6cGQsErbHph12bZ7RQWWxHuwFEic7
PMKtLoZAZLVHeLuDO3xcbfZ+w0MLOhgyOqR977ruGBMRoOZxrbKc1+DviNbS
A97SRvpwrH9fpccb1pd6yhscKB/pZ6+mOA3qDd/4p/LkiVeHL9x7oEDd9qD/
qURd7df9NKesPoPF6/t3FTu5G3CMg7jD1Xtt8ZlDz9d1J+zT/eFH5abUz/iy
+KPbX5XlKZ+0h4fq41e+V+9fQ3FSM75hlSmuAtnOIiXEW7pNz8PwuYIEBWUT
Det5T7WhnvkeONfb04o6VI9YQbZr6h7qeN+SdC/PDpGhB74YVe/cvobrfNj7
ewR3gUFDqf08OWpxtwi33U+zMqrEv50G0lbrarz+BA4ce4dSu39IbS11Dz+C
D/mSul5LdBhj8rCLuQyZVvfo9sNoKq/TTetjIwqTUoFylxxY9PddXmXLmc5L
Qjq3kGQQ3k+Y+i6g3JVyZte8q+OJNbgd5po3PK6jgxXErZ8vnE5e6yA28owX
4itvMPiA3Kg2rrt64fkN7eAC16HKLEZwCjWxY+yGUq8dszKC8zixMb4UIi4h
voL9B3gEPG0V3ixDCzMY1IrjKmM4BU4NI1oZCJK8uwyNS3M9xu/S4vLVZs0P
mH8sEeWHnmBg2loSrZpYSVk7MhtogSGKFBls122azL7JbUJxEMJE6w4ZlxKq
waH1iiZUid4gQlhFSHpO81b8PO4nRMSnmNpQhyABuPpUYqIBBlUTLoobBDqB
MaNoYbZ+yZWk6tIbpxEJs/VLCDH+jkmrRfP03gXEbEfC/nHDxna3xhImHYn9
cuXtBW4jV9FRONx2+IcbbDAwCpMCQEhZHQ3kgglEu/kEcQAI+wcoAONnm3zt
MEcxekhRGjyM+P+uOErXYzHKGWO6/iZ9IZVhtqmENTKzdxOSkEkJhWVAKsSu
wB0jOsg9wgyKFWO0gpd9nUfrULeiKGZBQK1y+9PxbIcD0PcSBvXE0Ib5CgPQ
7U7ybAnIlbP9cD1kzm4dLKpdqr7MG/4e3ppn7cVC3G7Bt+aO0x6as9tJ0VDj
3iPphkwvCrDSycxPJkjXgEpi8a4lb+4MQ3Yw369Ifs2qUvCE+NS9yGqBqlAb
2lM8PBbB2Bf64meEXGVTn2PMD7D3ZF3WGOmiE6U5mC9MsUkwxWbMYdruhHJK
DcSHwY7oiemLV112DttCPdnKHxoKbyECRo+FdUA0ypEarHngr3Hra6+jssuQ
0uHp7m0LL9+2beTqTcWk7+sPzG+v1dzf4qDje42M1zFeH2a4Hm5uPMTMeEXz
4uFmxQNjKw40Tg+28R5ulN63ebc6yH+6Mbp/ubIdkMX9QbbAdiAqv82XhLb/
DXM29xp7vCcPsvMdaOKJPW4vlajRqSdCwlPWIxWcbtbI1mFl22MbvL31kdm1
2uit56GUnmqXdZkirrgqe4xrb5l4+tehh3Yis2oZ1253cIM2KcpeDvfhBwYi
jCuIZbKCjSGayhpNZO1F9e1MY30I2eGwNAMSQpXa+ZHf1UeOfbrHzb+2eeWS
rID5TuqF0fzTaVmdWTB+beF6Jhhu1I0k9im4UXkJZHvJrbZwUk8Z0QfzT9CZ
wDkBqLI3ZZNixsnJpzqmfofTJIUJwOLQ7gD1NiuBzms41dMi0qIxzigqVnGj
5ArXqLUMmJGlc/pTpURyJplfxYhMdLaa6tzq5TOqY4+5RVSUdezqIY5dTXDz
JwocpI9ysUXW85SqY81HHXm1YTIirC7YZ+hAurLCXGiDBwfGhBLyqFRV8LEt
W2p/lArw8n7tCs2iemnLPBIgmJeN52w0AeA/N8STx3ak1KRLBomhlPjty8IA
HRmlMQ3zflz6SC19tnDzA/VQjjKzWasFq+/h+EMeqwX9wlXluXjJjWhiUAYH
ZRhE/dirsem/2cLIGI2eEmgHGowbB8AjZ8ohI7kFYEXbHf1LbLluvPoKmPAM
pTY5BZGatqBiYTlkS0BYq8aWtyfTEbatHg6BrbmyQQwSpkXHDNI1VrksaB8R
4DHA5i3O1jxgz+Al2Tl77F2zZV5v1+nlT/kSqhpbOwjOw7OA4Ddi+/iaDMW0
EQyUxojq7lRy2JmeUABMGDZhERQBh+y8vLApQTLM59mrJm6N2zPgv4BlptkB
ZglYwnwiqqVma61OM5nNiaZh4dHmLt4LMbswPK+yYEdsMAOtK1/SFDvtKvv1
fbVIB1UC643VMAsFj/67udfK5KeyWi//cHDdSEthw4bFR2rIuB7cu3djChi2
2aV6BTDkWvWi93qVLt7bQ9Qt/SBKl2p3+wV6HfHpbVt/UIDuBDerqxe8EE0n
yMqSI7MFPS0Hy3u46GnXpN9dKcBrM5/Zsw/Pw4BCZC9i8SAo+CjJ0+QZwhAq
j02HZ4tLlruOPZ4+lovI9UYpk04kqRGIfeVfn1zOOtu0nwYuxBUy/Qx6lvUC
THyw3Oeb3QaErE36Sv7MXi3MDZC/zL7ln2l67mt+VOzxkKIJrI8SzCXLmbml
XIRUvk5uQl/EcNXFaE3D2j6E3EF3ih1FMgd9Oa1yvlGI1jD7c7mDLFKFUNbG
PMABU0Ut9v2oa1pWnt0wM8Hx+l4BorjC8kiC+a+YJO7qNdC8k3W+yTXILw/O
c7zYgu84e5qHRsTL618Af8Dz94F1v6wzQjgszRw2BHHoSRAabF+8LCLQIORd
cMspRyKWzmDywNo/tOcCBupdjbCZLGGNozm4+vqjHY4ViB2jo98MErH9AilE
XdhmVGY07YucvhcEFb2kbZbhJQ23asDaXGo8d81FvjCDA4d4kISE61xPh1YZ
3XvNDbje9LUW+ZV3zPx+Ev+dtpF+vzeMIdO6dt961prhhx8K8RCoJVGP1qNh
uX9h5HEveiN+U+67e/bXph1wKXU9axZrOoUVG36NOWo8+DKzC9p/nWmu5N9o
tV/TReRSPPpdC28ZtarATBEqwEVqQdsp17vGO0eoFhMnsOre2Nke5AFmh051
QuOFA0hctVX6liY/WwFAsul9QtDJoY60D3hoDtYBCFjgy0YAmG0pZxlsnW3B
6VpatCxf24tcByITdAxTM2JnlbNQqLlXeOjRjKGrQC4IcUg4uKHOX1lgEC2z
yAzaOzWrm+XpaVP+TBLg8Z0Z4Jedl0t54Mm//EuC4ONpBcFE8yq1/nR+UNRh
vOEF8x4hGBADTYgVGioZBdNHzGiZHhBpBOoaCOyYOTXfZMUZKJoC3yf/DmQX
jifTNXBRR7esx6yCZT3m7zU2gxITgVYHJejiWP5CN05Cma15PMP0c1wAJyuk
Mg5kLDxrmIdThb2jTFJplZ1h8VFdDYOwmtjKhHmrkXKfLehFayaTs+I08EHT
sXLUYydReFFpNniAhmZu6djgYwYsFQDWXABmvjAgwu/HixpDgpYOt5yuYtga
YbGKRCMdT5MvJDqIwb1yc8ujjJYqsE6yZNZU6mhFcWUQzVcb/sswdukLQnQ2
4oKqt4GxHRyp6GYWG4it4+Q2UJgubxrA7VmUSYH0ouARz7qqmCa8KTDfqh4f
vSSRO4YlBEbr6YhPAocQ4RmwxX9IKNWoOlJg1J74i3yZrVm0nOVZs8KLDgsW
Gu5nUZNLLsyyhtG1kKHHaqxOQm9XEXKAWhrRrhXV4hWBauFItVB72mvLV5At
1sxb5viIIJ8G+6ZqmsquDcEkfSqXAUrebAeNq5UCvBtg1+0HT1U1wayIy/xP
lfFE5wKUErKMlUnZrhxNm1dCQ+pL4WtVhtViYzJQrXgJjKj2913mrcNlovGV
+TpkeNVWFUa0xPoXJxfdW6+ddmz3iAC42fstehXL8a64g2DrcxElX8ebvcgu
FSQ6TWAW7sIqsGILouRmjnSkrInnOqBXGQxodNQ8vl2r+oy1J9GlhkXkyo4u
FCLhwRyyyWxiWWYUcYflA6ziqOoOalhnGkCRUdyaVztOD4HZoiV2/zUMHF2k
wP1EWSwuL9JLpWmyQZ6PUguMj60sLgQx2ACmIAcpdalIAihirDavdcGRl9lJ
uORkA39HBoBkjV5W7x2uF2JaRVN0X4xoZ1Ch02tpKki1nl6rvrcxhZHJwKoB
1iphWwbkaZ9SGLFQ3ymMszfHxlYahSm6rXpqQzWtwYQ4yTpf5A0iJ2sY+vjR
Bk9CyMmmyb8L5VkpG8mmzfMCQbJdCnVMAHUe/5L5jO2E1amKVeVsMRNfEMea
hhp136NdVKWoA2JAY2X/H1boFEw4md3CyPioP94Nv1Lpft8OM1YSA3qDYq9J
o98Z8cLSEvP91up0QH2aw0QFuIQC4F65wdjToTGRtxEYpw6GeR6Z0+881O9q
M/pnXGD3L1dxS6kjuNc5FfhX1Qb+3oMCO5N+bzGA79BQtd54LQ5THBasFbDd
2/GY5XSHeyYJNrxwmUsltztpGV4jS26V5rq0Yksun5DlIlDHyNqCgJwcr0X6
NaYbws0TVqjuCmnxHWetUis9yVUieBPuKzqE6MbkDC9XipTjphh81mLDuroY
rhays16pgBRZF2/BQtWlZQuN45YrRbcniSeM6NFlFaeH3vYu0qRwUrBOvnRl
DEU7xN0KDNZkjLK8XFk4XPKkXTXnT1LGD/RCWdcM0rWXeslCX6QPa9jstI1L
/BGSE7vAJLuVKRRgdz0TnC4QFNguG5UoGJKu9fZKn22qVXFPsL0+cHWtCY4G
lUHNMqcVRpcAcXuhgBYZQMtq42hNp8+1qgiZEViAgxySgY3qn7ui0BFHXjt8
bFBWnenZJlrxDC7DBCz5XiVgYXwnNu+m7eUYsss0lj8FRCGW/ZzLPdTZhrCX
xfLUyrwSe74yo4k+DgYX1n7JkuJv9YVFKDdMoCrJjc0yv3DwE66AhNTlc3Yb
/G9rwCVgisXIUixsA7mxePuuqWTiNPmeBkbn8ty0K4NfVLtFTgVEfO0OU0DN
fu4WWD2H48+mEl0LFZ05SDVad2WbVpahB6fCLPN6BzR2chK+qDzMfrCsBMny
fWW4kzLg+YYko81a619WfPsNiD5cvq09S/zN1XkKCoRUrtBgagswBzZ/SYxW
lZIiANNsS/VSDce+LSdqAxT88iL0L7HCCb07xnwpYT9kO9nhuUSBxWZdRpbF
yQbBEmAlNSpIByaSKCs3B+MJJ/i6OiMt8HTKAbYW/xp0X/S/0ZV2VZ7qV0BP
4exctveJDUOSh6xSyak6Fo0fZ7SrCsHFt/WxVPryNPkKWCdTV6ojO5zA5Zpz
3Hydv8g41d8KjcdUYrjFJe+QgUNqU3lj54LtiFsPJjeIi5xBAQEZH9Q5k/3Q
64mkCuUpY9uhPECu2qyt8DbPgsBVsnQgQ6PwDhVts8mbxrpl0povOiRBsCH5
mdhteTVCTi1rhr0EaBbh1UDf8sXwdg0K1PVANEGZ6B5t9mhVllfQZI/maeW/
xtGs+9/71X9PQlTeVuIb0+Y+9ZaqUejzeztarX6Qh+Zvc2T3sKKH2YCOjUX1
E3+mU8Q7MxD+htr+tb/tX6VtjG85oGVDbX0t489XxciKbPOtaLSE1AK1KUFJ
oAuIDNo5KbEl39bRq8mLYJ9fMriL8KesgHhIfRPidQcqHZrStT7XGYKAg8te
4Qu2WJbVQaCLjHQrpYiQMF5BHSwjecEQeSyDQmPI89UScpJ2BDO36hR+ze/Z
0aO0T2XZ1uP2L0qpHs7SsV0d1V/g1vF9Q4U8BQrOpdUiOmMWnrt2RSWyKC5p
DaIyCGoAiFCXRvhtxF1nnfVG5gxiYukriYd10oiTJjG4AOeIwhrmLbChxDmI
PblVuWLBPu4uWQpGcS46cDkgehEa0Vl8xrtwtUPhXJd+w1Qy5+PlYFRb8oa8
X/jaWHlQUludG7vy6jS/zNblNrMBv3kl7W1cchnqquafXwe+ddZW4A6Xaop+
paynj797nPDLNjsLy1g5/AwP4cIeFGDb6EOKRQXoqNB9UQHKYmF0NvKDS+HP
mGykRN/n3g9WH2BfttNJZvPLJptIEAgo84YSXk0gKgX8OQn8rDJf4rltJHLN
8yKtLmdKPylKF1/rHvSZBZTtNj1iHMyI1VbQD1RPsdjdAHrpudKY7HOKR7Ob
u9bTs7Vjz3ZML3b1xd8O4UXk/8KzFrrDclLcVuv0DBxnHHiQLmEd4VnDl7aZ
D7u0Li8yjIDxQqV+xJfCZxGiSV6RJeRYlRFqfmqA3lYr5keuue6qdooxiXuQ
9HaXD+XXHvXVVD8useUvVBHjTyO6LFYIc15cBj6DDFXx3dlBhZ5KVe03DF9k
bySf/3IO51PtYrFbr8NddAE03auE8dewM+7Iz7FUL+m1VwgCyivtDGmd/Wdc
YYIrVKsUZslv3JvATBWrP+aK1R9jxWp4c1AS85BiuOap+8mx2N/8bOev1r5t
2BaapkrUhLuXpSQcYOgkii+UNKpVRGT39XnKQR6R+tXxotX+IZs9k+5140Dd
AOWUqJi8QLF3Uo5flrcrK9UlmId5qbaI8htVN3R9OR1JUCCTUTjMJNvMyyWF
b8bWyNGYjsayph1cFWek1TE+bUS9afITxk1LfOJFaa3TKtW6ffb9q6i15dqA
9VTVOOVQcRHIKJfIzrF2Cbys7o05kHss2gkwW7qgxp1ddkX18ArZsp4yImdu
72lQl0cNq3uiLJApSVPEPVmXmAXceZm2VOgedbAMeIPuyxnD5Q1XU/AnyMAR
gSk2cPFMaa8UC3ZjtwQtmMeO3c2DCBvDzWtgmmC3tQBvT5XmAWlIygV3Gew7
ubngC3M8IMbdzIJY59qlEbUWW/FQm2wc2iv962KlxH0aTloFC18PJCY2yQ0b
kxrO87hbw4szq2IAikMoSVV+ttGjbsecnD8afV948KU8r27qCVMBWeQko2C7
xi0No8gWhi5SAle1MfKeq9Dtlh+9aJmFc/E4VxlSDgYRk1PAjYSqoKLGQIyV
IIkEx9WuniDaiUuNN5UBjErSaiZupJZTdBGGXyNVRHpq72WeKp/NahbC18YS
19paOFWEdOIZVgZmSdpbqDbpRLlxvNo6BlgiFCzAyJYIRrrAAHHkamrShEPb
SI1QtMpKUk042DrRgAAK3pMAeiuvOipGZzJihNkuuyp+yc3aO2q2UDpIZh56
pXcgVVlNrvMKuqbieu5E6CCB+JGwUet1uWahkNRQ8dHpYYT7yDW062y9GifZ
aiUigWliY7RSbiF7BQeIqJrUUBUye4Zm/iqv8VIndREnUHvRtLrca70zLANT
U7FYu+fiZFsW17tdw9YjYaLXMEArZYqtKZuq5Wdd182EblJcRSsOBd8H9cgH
XuB8d4OSiYGGPOUUFsLhl8ATyilMgkRtcUWU/hdDa5HTcAHULVGRlmdEBwoe
1MqrhG6JUqnzds1SFTHwMs8uQLaiIsyQPZw526D4m1rSsXAIWFpB6zH/HTMm
tHsQrhNb39mVfE5hk+FU1BRijVlc6JTcposQu8RjaBrrueXExejs6IidSCen
3QGtQFYH/07cJ1bZOtWacDAtXrN1Fo2WRf7Ysbq4XF0rbBfUEWFcTm9j6ZAy
r51mrTLdUhua81SM5iepfHXm6JrthMu8XuzqOlQ6nGoxduWPu0JviVsPLpGO
qqh1K0TVUfQQBupor056n3XS+6iTSuOD9NJHyTHIC/1q6Sf0EAoV/U9+ap4M
HxrN1Ix9du+oKVP6LV5xaFrdnZ1ltcu9MTo+HCZSP+MtviMVlJikKAvkH/BU
a0/BZOPvcBVwmjzTwU9cBUbL+YS778EwqfQRUkk6Mht8FLtO7OuhUTqB+kdW
1lcheBQrhWN9rEhPYbkmxIPqVgP7AqGGaHy2o0F4SuSpHwoYfuCi6ciBvK0g
IDFnixytZKt0ATnNUZw2iR6IKJZ9OqQmKRs65EsKbV3QZjQbIasQ2hJXyOB8
hAPWqq18OrUTMzW1yh+uqqC8pZ526Nlub02TZEL1Bhg7lQeuiGfU35+nZOs3
DE7FUeUv6FLnkxwk5EiuqldygZ2J8RysmgQlCPXOAcMQ3GiVCF3tyBaRvn1+
PuZz2qrNEbei78sKYl9Zb56ZRzq1DroanHHmOpWzIgetsr6pS9FwQI/FpFvw
7wao8rAPZfViktL3lEwUeHquAVJ2s2k4/4Qm/yc0+T+hye2r720KkrpjDonR
ihQlvMVArYOyj95SOpH+12A48NsdxoHF7VqdDa0gF6We2wj9eiYuStGe26py
l6L8gBXlB6goUyvD3LcPk+Nqu9jjvf04OU5VmxapWptNVGSCjizPi5flC8a0
tZj/meePJUdvkMigmoOW0B2ZF1vwrgM6yK6BP1lq62gOhFnUj5w91Tz2FBoh
m4w4gr/H1ui7IKQfZ4Egc+9C96YIbyYKC5rL4X8SQc2ZPc4dauOkymojIUYt
izS6AdEUl+pOYtFrhj5Y0Dt28L1ourPG/4j5jexUdxKK3JulvDu6HcxOwACW
Jrd6WKAe3/GwuxuwQy44rsqpgsra+MwVrrM5GYgJwBkdumIdBmsEAdoWd3x9
qSamkiyIhtvpTnaVakBNXLOds3bDwcWiGCkauT8U1N/8dar1HIWtMOtta2q2
rV7Vi9oPFS/6ls81aYv6qEgNQHdQ3FIy4fgLghkDntoyKGGA4SpmeNAFTRz7
9DUNXIsff3hyl8YdxEncpAJAs+sW/7dmQ5tnJN/si5i3y/muJTsOWLy6fLco
1+WuumEhr6/Mtya9d716RisHr0BXfsL7IOPysdgn4XaGUnsn+63IvDxidZwi
W0H3f0+AP9HlATWzJXT3wKwA+LAI0jMaJpSDEyV6N/WWBE+MheuUO7vEzocs
dj5EsRPbiEidviz5KDk297EtPtKufcLgVmr4NDgr1wEsMF7CEAufrm21XJR3
0jkWFcG7NqMoDnNZvrRxBerOxcRb3++XcQaYki/HqvhtzAkTFyAFYxlEsV1V
OLzZEBOARDyaYcQqrZdK+wvABDlDg+4syOnXSb96XEFyaM/v10j+mzqRAtc8
lDPwyyAjXwQ4C6Jop+LADs1KXKRVwVFDbkmknoSRuncFZgsLOPpLSIuBJimR
T3aLWwmMhLj8bRGBH+4UDgbcScPuoqF3kIzoS5zewfe3vP4jLslBRrCrsSwq
Ktp5DRHVx+8Xf5dp3MHKIJP1VmSA1u8twUCl31LtwYyXZtiZ6/XkPF0DPmFW
jz63H3bsq/biUKNSlpYUqCp/iYnwCiQD4T8RzLUsX4gy8zKt8hJSJ2zXoicB
z+XjaMhxwdB4q7yQ2PV0aZQO8GCLOxiie7TjUhbnwzpZZWmDMKQQbVTASUR9
CITzLzmWZUGa6lcMN/rSovHpacaiBbo/I2+FKGiG55Q7YFPuyXzvwmpSYBNQ
33izTSsXhUFKHOXyMOYlKDqGXsrijNqWslUpGQEuMrPo+AO+i3CT+GMuzEp2
D2EO3JgY+7GFwTpWppAx9cbL7cHSGwVrNs8toma22TaXszvWLlFlZsiiJCXp
7mwj/BVaw2y+IGROYX3aUL0YSG7DOdbN4tysW4gnQN1fOuPFPNO1zHK8ZSb4
doCAC2ttqUhQU/IFOJYUQKgggFMifnkRFFjXQU94adfr/OwcdHsFj9+alIPp
5ST9HZUw6HmS0Gpo0vPL5KcHT5JnFHRKoY+2uFqdfPXk28dgE9rGujY9fu8s
XxonQa1qKRQN5h9II2JLdWoWaJ2nEouRBjYDdmnrpzqYiBaLaIVJZmgX7oJC
QyHVJUuC0EWbXRDsZJuqzdoYYWXBnuXSlvUyc1Vxi65MiIt1wDYehxlIF9iG
a9al6ax2a8wbUu/b6AI+Ca08Me+E8PILjCkTdaGEJDYkxYEC0/D0CTAw2deC
bCeoYkGmLIkD/EZojI+DoJkktmyfhUwtiePR5Ay1cS+Y7+gjNxVcBwXlUQg6
/s8f0sY7g5Z3uHZQ9q1FAxB0WJTFAVFFsiKdvZVH7C0v8ZSVPqZGisJEwGCE
XvAQ2P5aSX1jiro0i2yXAQ2TmBDXBlCRiBo/kZVy+jjdGrmyy7fm7D02uYpn
O1JeZMw3IOCUJ2iOyjHYMAbWFKs5Qa34/IZDoEMokLBuyliSc3A8497mH6/N
WWP3eSQWW7BNKy4agvdYEavVYo2rWK3REI0Qu4YVQdYPEZFFpvCMqU6MBNhs
pEAMYTFzKRoU7Z0XgckycP/7WCg65tgLbkISsYHzqhKNxGR3JVThZvGSCDac
LUZkkavDpGrMACTQHYi6LgJKoZVbUba1te7Sk7Gdw5UfkxpGYd40TWvU/TuI
qBN8DHwGzyi4S+Mgyzx7spv4DuFKIgSU5/CGOykKL95Cqho5JwhPmIOnHUlE
5qGj0NyUEJndzgkpRV6wzA4ZGMijNvdSRbLziDQ1iisgoEAhBxCcKThfaExr
+bFSQIGwgXJNmHiAkd6Uf2skOZtmimslSaZosLegxRJJnCPRZfmZDaycWkhD
IK9QfmTmdoHpSjSYuh1rhBFNZsL5GcCK5daJY94O0l+MDGYuXwKwCsPE+Vgq
SQ5jlcLYHAc6hoclRC/zEeWRcVNY0dhiBkFd1eJy6dx15l+vNmvxjwj/opxg
d+9Y2DTNslyN0dkT62Qa94PYexjigOqk66LYWhCpC5fGe+zMaBiAELXJjJpV
5PXGkqgUdH2Ro0trZUuCWh2dGVHbGgGi/3/AobtyUSZVdqm36NLHfQWd9ur9
ih91q/7oQwpZLWyd46M82nG7qJe2Ewj/sqsTK7hk1uTBfd/gLCWTkuk0+Tj5
LXlwlNy9C/oISkW8XdHZOdZ0mDkgzGovoiaBH9EP+Ryi4Kjr1x9wqRKMg8Pw
OC+GHrPzRCPMz85cYo/pAdjVUhUp5UA8FhBX6QJkHKsGehF4+dTwN5XqJ957
NGYAz+caGJ6mnBbs6S+guGPdZNtkni5e2Ic4K8YG13KCS8NKmeGeL5zyvfQN
BYH6ruG/IP9YyoeQkr1B04cYKtSzG3PiCsPAfxFhXLDm4Gsjey4yZM9Aj2BI
VlgfUlllioEPIDYwxDy89ULNr1beYslJpepNiihwGYnxkam6gXKuRgoqJ8By
zSr8d2PWMG9eq5cgAvINXgA6VYRCDLY6N4u7JV0G3vKK+6iKhRBLsaUJIh9r
ZTr1yVjUMNAPUhhbmFy6ZNBUC/IG0qBYfczr02T2hyf+VE/ZcWKe+IPAtJkd
rcqUggdQdeVNELwFKqyh4Fes8U3nA8n2Qs7clq60Gq1uAWCt0+ksGg4XGlA6
ar0Dw0TOyjLKS+kvZhUoZQiAqaiQjqX4i7SOpOmoDPdNljWY8sT/fgykBNGw
sNCYEEU7G+BCWThOPIAX6vpZ+fG1OAKbhOJqbpvuoDTDukwt04CeVzkvmbew
pAEsl1x+iBQcBvRo2oOzGxTdHEs0IoQgZC3WN1P2xpxJD42O9CTMBKznJcYO
fauerG1NF0YbJTlY3A61OSOQaCD2T0RW0ufdmysfBnyHkaDlaMN4+E/emu9K
zGZAOoZEhHmGCfdGerjMGlFs+SoIUEpRjNLzrb3YbTT/sRjFhVxkBbfm4IiF
wd04d9VlBBwIZGCQb8wcoNVp8m8kqqyxVGj6wiIk6NkbpTZF654zWMiM63Nc
VCohK/HxuFSQSaobEVerPSJqT1OrmhsqeQn26bUu2BVwQJdyM4yVoZ+Pyo2n
HIaujjjStVTP8o//2JwisovyNOeZFdPdIGgjYSrSiGscDjqPoo40IkVLcHBe
Ary6XiT9wCrpqn3YENwc0uhi9Fk7Q5IttgcGPs0N0CjhHR2rG6MtkK9h3CEF
O+ahLojTIzIEZt1GMxm32LPtyALmTJMf9djkd0NZl56GZ1kG55w5WRJfMat0
6VGuFoFCLHewuppNsRnyYO3PndjWFubkMgFeVVvYI0/HFnJA8AfaAGtXpjPm
aqelqE+4VQmRB7yVlvkFUGdGWoCKjrCAVEcpA+sbAwg6nzriOZdc4Rd/5KKX
oIxYEmRqcGKWMonbnFkmvfAwOYpnY2uQJ+tTGsuipp9GkSgWpYFYjtI8Slkd
z9Ud4i0OdGHt8J0ClyQn0tUYh13z0phd4pR7QtlEvO4tPnknExoLsq+rahiw
NUtF3TelwrBGn6RG8tAHOlDpNcYZysUdakEXDHf2yh48OL7WKyPoP2aO5l5j
fUBRJJS23hWMqDtNvu59DydBpI2HBRLhBDQwgkBEhoyivOBDB5a0yiV/Ihwo
Bg64dQHnI0DeJT8KQ6tD9+II3U6eF5FM6hGBxrFFs2EW8x98GFNxN4k1Wiy5
QiYWFkHO5bFga9yxBm3sHKQHCzet2L4YX2E7BOhEe7RcGUS8dl814B4E44b5
CUwelJXWXPI/UTAfM9zEHSJ6BBM8j2CJ2MpmIRyIHwLKvi3Q6oxoSVeVE66s
U8o5uUClcA8oGPxjLBnuapt6eYZ3xAVI1i1wULQAXFAWsYJlULBTAbewhUGA
5/WRwuzSwpuCzewmKzjhRYz1oSXDvOhMyGoZXwNQFtdsvGcADUOdSHyHrXm2
mWfW6Nqoe1jBSyh3pZjCGV8TY6lRAVC4GPas+/jkSMkOjIHvHOgeVFELWxOM
3AiYDr+BK5CCpm3k43VKbs6JH8rsKMMHiex/i4pxASZtWH+e8juROtjSFwPG
UA6KrdHmzU3ChgwHNvPUJk5b9Bw2mvPpxlwUgTfnwgoc+2+5t1yJZC1E7CFy
QODtba6xS2Q2IEqX5Ysar2lKuAS3gmOMbAQ3DKLaSGHIzIKW4/IvIRYOTO5d
7o0wC5s0PEma9tONYwnTOs2YAtq9Ght0f/5A1nWhLTzKdZp3QGOAmV+TlKV3
J/jle+ryOls5bRZkrELMy02Azzw/70CemRla3826wU+RNOSh1mLRD1N7Lwmj
g6/9ZbDQBl0wEdjUz5mhx7w+Fx8VfHWWQc3fmeTF6PO2vZQOvbrVdgQNaYpP
FYKglqvOM83NZQBd/WMMjYjwrRXwTmwmK4arR6VygHI0ypcZfS4Aa/5IpKKp
HRm6f7SO5UmT5CDeu3yYq0BxLFYTIT8qUySYIkG3w1k5+CZV7AlvI5Z97FSO
pT1zpnUT9C7KOiRYSQMw3jstsCDbiULswPNrrwMrcLewbZy++D2wels/OS2W
mu+j6LHdZmkcdwe/AJw1W2cY5RMB3xFECK5ZVUtTMHAy+nAxWHdJkQhloYgs
pFu5VVBVUkHWguLYewN5tq70K/61fgREy09IJGXp11uzrbA2HlIAR2gLSqO6
xOEn8c6UzLwpX0ZAgByKEoFXqOgJUMh3WAYJdibDIiICdy4YEHZTyHQM0gD5
HV1w0qpcsMAawg2oFCZOA+Jo6NRrDOKKympJrkO//Nwfk79Op9O/Be6sDj8X
/rg0x+9txdTCSTo8lHZbtSJwSY8+IIQ25oQzzGb/xPsSyHWGO10b8MYHd3m9
7+LS7g/oHbd2qy9TCs5XujMCT3OUdEMlDMBTsIsgTLh7IrhUvXukOPd1moEV
+7lc/WxO0c/L9PLwpcUFPTCCOpBAujypNiHRIbZGkDjNH5QBQsWHgXiUC5V9
Im4Pg725ezdyfu3NBZPuyvtGdWdY6jeepw6i4Gkt8k26fvTQNLiqKBlmsszP
IJDm0SFJNd7oUcCJjB4kjo7f4INZ98g42on38EFWCivT/nlYZn3nZviPBaRp
lsb1HCuSYl/UR0zegu8GvEUHqu+lPbR8eCS9I/MOr/lTqXhAxrInbA+iMFoV
Wx/5SJkw/T5p6HiK0rUykEUD8UnQGVECsbmCX7+eQHNv3vyRZJNyV2Hw5TLz
c43do3W1QAA9rCaxd+zsSlyaCxttA2TSK0r0C2VcxgWaAnvXs2yxq6gk1pAl
sfXxYi9Bu2bEnL5DihJlemFoLARSTiYTdPibRV28KMqLdbY8I6my1SNQBt2Y
2fLzo6KEfXz+xZcw6NGf/mDaSb4pF+n6JyNT1KdJoqKJVEYbbIROTLK/fFiP
ksnkzx0tcc0ll+PIWKbMyF3mBkUb9TVF3SFGk9kWkJCVvGT//JDsef2jcunW
fqq1jObD2grlfc3gMILkayW0UTQVrFzPaJagGRnaz3/FVUKrqUTasBkxUTbE
znYkwo082JwBSU//fzdWnVBXKwIA

-->

</rfc>
