draft-ietf-anima-brski-discovery.xml

<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.8 (Ruby 2.6.10) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>

<?rfc compact="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>

<rfc ipr="trust200902" docName="draft-ietf-anima-brski-discovery-09" category="std" consensus="true" submissionType="IETF" updates="draft-ietf-anima-brski-prm, rfc6690, rfc9733" tocDepth="5" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="BRSKI-discovery">BRSKI discovery and variations</title>

    <author initials="T." surname="Eckert" fullname="Toerless Eckert" role="editor">
      <organization abbrev="Futurewei">Futurewei USA</organization>
      <address>
        <postal>
          <country>USA</country>
        </postal>
        <email>tte@cs.fau.de</email>
      </address>
    </author>
    <author initials="E." surname="Dijk" fullname="Esko Dijk">
      <organization>IoTconsultancy.nl</organization>
      <address>
        <email>esko.dijk@iotconsultancy.nl</email>
      </address>
    </author>

    <date year="2025" month="October" day="20"/>

    <area>Operations and Management</area>
    <workgroup>ANIMA</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<?line 108?>

<t>This document specifies how to make BRSKI communications autoconfiguring, extensible and resilient
in the face of simultaneous use of different variations of the BRSKI protocol (BRSKI, BRSKI-AE,
BRSKI-PRM, constrained BRSKI, stateless constrained BRSKI proxies). This document
specifies a data model, IANA registry and BRSKI component procedures to achieve this.</t>

<t>This document does not define any new discovery methods. Instead, its data model allows
to signal all current (and future) variations of the BRSKI family of protocols consistently
via different existing network discovery mechanisms: DNS-SD, CoAP discovery (CORE-LF) and GRASP.
Additional/future discovery mechanisms can also be supported through the IANA registry.</t>

<t>Automatic resiliency and load-sharing are enabled through the use of discovery mechanisms and the
provisioning of multiple instances of BRSKI components such as registrars and Join Proxies. This document
specifies the procedures to support load-sharing and (fast) failover under failure and recovery of
redundant components.</t>

<t>Future proof deployments of BRSKI requires Join Proxies that automatically support any current and future
BRSKI variation. This document specifies the procedures how Join Proxies can support this through
specific Join Proxy protocol behavior and the use of discovery mechanisms.</t>

<t>The specification for discovery of pledges by their IDevID as introduced by BRSKI-PRM is refined in this document.</t>



    </abstract>



  </front>

  <middle>


<?line 131?>

<section anchor="terminology"><name>Terminology</name>

<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>

<?line -18?>

<t>This document relies on the terminology defined in <xref target="BRSKI"/>.  The following terms are described partly in addition.</t>

<dl>
  <dt>Context:</dt>
  <dd>
    <t>A set of Services for whom the same set of variations applies</t>
  </dd>
  <dt>IP, IPv4, IPv6:</dt>
  <dd>
    <t>In this document, IP refers to (inclusively) IPv4 or IPv6. If a statement applies to only one of the two versions, then the terms IPv4 or IPv6 are used.</t>
  </dd>
  <dt>Initiator:</dt>
  <dd>
    <t>A host that is using an IP transport protocol to initiate a connection or transaction to another host called the responder.</t>
  </dd>
  <dt>Initiator socket:</dt>
  <dd>
    <t>A socket consisting of an initiators IP address, protocol and protocol port number from which it
initiates connections or transactions to a responder (typically UDP or TCP).</t>
  </dd>
  <dt>Objective Name:</dt>
  <dd>
    <t>See Service Name.</t>
  </dd>
  <dt>Resource Type:</dt>
  <dd>
    <t>See Service Name.</t>
  </dd>
  <dt>Responder:</dt>
  <dd>
    <t>A host that is using an IP transport protocol to respond to transaction or connection requests from an Initiator.</t>
  </dd>
  <dt>Responder socket:</dt>
  <dd>
    <t>A socket consisting of a responders IP address, protocol and protocol port
number on which it responds to requests of the protocol (typically UDP or TCP).</t>
  </dd>
  <dt>Role:</dt>
  <dd>
    <t>In this document, functionality of an entity in a variation of BRSKI that can act as a responder and whose supported variations can be discovered. BRSKI roles relevant in this document include Join Registrar, Join Proxy and pledge. The IANA registry defined by this document allows to specify variations for any roles. See also Context.</t>
  </dd>
  <dt>Socket:</dt>
  <dd>
    <t>The combination of am  IP address, an IP protocol that utilizes a port number (such as TCP or UDP) and a port number of that protocol.</t>
  </dd>
  <dt>Service Name:</dt>
  <dd>
    <t>The name for (a subset of) the functionality/API provided by a discoverable responder socket. This term is inherited from <xref target="DNS-SD"/> but unless otherwise specified also used in this document to apply to any other discovery functionality/API. The terminology used by other mechanisms typically differs. For example, when <xref target="GRASP"/> is used to discover a responder socket for BRSKI, the Objective Name carries the equivalent to the service name. In <xref target="CORE-LF"/>, the Resource Type (rt=) carries the equivalent of the service name.</t>
  </dd>
  <dt>Type:</dt>
  <dd>
    <t>See Variation Type.</t>
  </dd>
  <dt>Variation:</dt>
  <dd>
    <t>A combination one one variation choice each for every variation type applicable to the context of one discoverable BRSKI communications.
For example, in the context of BRSKI, a variation is one choice for "mode", one choice for "enroll" and once choice for "vformat".</t>
  </dd>
  <dt>Variation Type:</dt>
  <dd>
    <t>The name for one aspect of a protocol for which two or more choices exist (or may exist in the future), and where the choice
can technically be combined orthogonal to other variation types. This document defined the BRSKI variation types "mode", "enroll" and "vformat".</t>
  </dd>
  <dt>Variation Type Choice:</dt>
  <dd>
    <t>The name for different values that a particular variation type may have.
For example, this document does defines the choices "rrm" and "prm" for the BRSKI variation "mode".</t>
  </dd>
  <dt>ACP:</dt>
  <dd>
    <t>"An Autonomic Control Plane", <xref target="ACP"/>.</t>
  </dd>
  <dt>BRSKI:</dt>
  <dd>
    <t>"Bootstrapping Remote Secure Key Infrastructure", <xref target="BRSKI"/>.</t>
  </dd>
  <dt>BRSKI-AE:</dt>
  <dd>
    <t>"Alternative Enrollment Protocols in <xref target="BRSKI"/>", <xref target="BRSKI-AE"/>.</t>
  </dd>
  <dt>BRSKI-PRM:</dt>
  <dd>
    <t>"<xref target="BRSKI"/> with Pledge in Responder Mode", <xref target="BRSKI-PRM"/>.</t>
  </dd>
  <dt>cBRSKI:</dt>
  <dd>
    <t>"Constrained Bootstrapping Remote Secure Key Infrastructure (<xref target="BRSKI"/>)", <xref target="cBRSKI"/>.</t>
  </dd>
  <dt>COAP:</dt>
  <dd>
    <t>"The Constrained Application Protocol (CoAP)", <xref target="COAP"/>.</t>
  </dd>
  <dt>CORE-LF:</dt>
  <dd>
    <t>"Constrained RESTful Environments (CoRE) Link Format", <xref target="CORE-LF"/>.</t>
  </dd>
  <dt>cPROXY:</dt>
  <dd>
    <t>"Constrained Join Proxy for Bootstrapping Protocols", <xref target="cPROXY"/>.</t>
  </dd>
  <dt>DNS-SD:</dt>
  <dd>
    <t>"DNS-Based Service Discovery", <xref target="DNS-SD"/>.</t>
  </dd>
  <dt>EST:</dt>
  <dd>
    <t>"Enrollment over Secure Transport", <xref target="EST"/>.</t>
  </dd>
  <dt>GRASP:</dt>
  <dd>
    <t>"GeneRic Autonomic Signaling Protocol", <xref target="GRASP"/>.</t>
  </dd>
  <dt>GRASP-DNSSD:</dt>
  <dd>
    <t>"DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling Protocol (GRASP)", <xref target="I-D.eckert-anima-grasp-dnssd"/>.</t>
  </dd>
  <dt>JWS-VOUCHER:</dt>
  <dd>
    <t>"JWS signed Voucher Artifacts for Bootstrapping Protocols", <xref target="JWS-VOUCHER"/>.</t>
  </dd>
  <dt>lwCMP:</dt>
  <dd>
    <t>"Lightweight Certificate Management Protocol (CMP) Profile", <xref target="RFC9483"/>.</t>
  </dd>
  <dt>mDNS:</dt>
  <dd>
    <t>"multicast DNS", <xref target="mDNS"/>.</t>
  </dd>
  <dt>SCEP:</dt>
  <dd>
    <t>"Simple Certificate Enrolment Protocol", <xref target="RFC8894"/>.</t>
  </dd>
</dl>

</section>
<section anchor="overview"><name>Overview</name>

<section anchor="challenges"><name>Challenges</name>

<t>BRKI was designed to support multi-vendor deployments ideally with zero additional
provisioning in the network just to support BRSKI. In recent years, multiple
variations of the BRSKI protocol where specified, sich as <xref target="BRSKI-PRM"/>, 
<xref target="BRSKI-AE"/>, <xref target="cBRSKI"/> and <xref target="cPROXY"/>; within these documents that are multiple
options that need to be supported by all BRSKI entities involved in a BRSKI
enrollment, such as pledge, proxy and registrar.</t>

<t><list style="numbers">
  <t>Assume for example a registrar from vendor A is deployed in an enterprise network
or manufacturing plant to support a variety of pledges from an ecosystem of vendors all
using the vendor A registrar, and a particular subset of BRSKI protocol variations.
Later, it becomes necessary to also deploy various pledges from a different ecosystem.
Vendor B provides a registrar for this ecosystem, but they do use some slight variation
of BRSKI. Now the proxies deployed through either the A or B ecosystem discover either
registrars A or B and randomnly pick one. And in case they pick the wrong registrar,
enrollment for the pledge will fail because the proxy variation of BRSKI is not compatible
with the variation(s) supported by the choosen registrar.  <vspace blankLines='1'/>
Now the proxy implementations coming either from A or B start to fix up the issue
by introducing some proprietary extension to only discover "their" type of registrar.
Now a pledge from the A ecosystem can only be enrolled behind an A proxy and a B pledge
only behind a B proxy. The network operator now falls into the next trap: It is not
possible anymore to have networks where both A and B pledges can be enrolled, because
it is physcially not possible or financially feasible to deploy both A and B proxies.
Or if they are deployed, pledges would only randomnly pick the right pledge.</t>
  <t>Some use-case community wants to introduce a new variation aspect, such as introducing
a new encoding method for the message exchanges or a different certificate enrollment
protocol. But now this aspect can be combined with any possible other aspect of BRSKI.
And without appropriate planning upfront this ends up in more chaos of ad-hoc definition
every time some ecosystem prefers one specific variation of options.</t>
  <t>As if variations where not difficult enough, networks may only support one specific
autodiscovery protocol, and specific variations did not bother to define how their
variation of BRSKI could be discovered by another discovery protocol mechanism.
So that variation then invents yet another one-off way to discover its variation
in this new type of discover method in this now more important type of networks.</t>
</list></t>

<t>The following sub-sections attempt to more formally describe the different challenges
in a technically more precise language.</t>

<section anchor="signaling-brski-variation-for-responder-selection"><name>Signaling BRSKI variation for responder selection.</name>

<t>When an initiator uses a discovery mechanism such as <xref target="DNS-SD"/>
to discover an instance of the service that it intends to connect to, it may discover more than one such instance.</t>

<t>For example, BRSKI pledges want to discover Join Proxies or registrars.
In the presence of variations of the BRSKI mechanisms that impact interoperability, performance
or security, not all discovered instances may support exactly what the initiator needs to achieve
interoperability or they may not provide the best desired metric. To support choosing the best
interoperable responder, the discovery mechanism needs to carry the necessary
additional information beside the service name that indicates the service/role of the responder.</t>

</section>
<section anchor="consistent-support-for-variations-across-different-discovery-mechanisms"><name>Consistent support for variations across different discovery mechanisms.</name>

<t>Different BRSKI deployments may prefer different discovery mechanisms, such as <xref target="DNS-SD"/>, <xref target="GRASP"/>,
<xref target="CORE-LF"/> or others. Any variation in discovery already defined for one discovery mechanism usually
has to be re-specified individually for every other discovery mechanism. This makes it often cumbersome
to select the preferred discovery mechanism for a specific type of deployment, because such additional
specification work can take a long time. Indepedent specification of variations for different
discovery mechanisms can also easily lead to inconsistencies and hence the inability to equally
support all variations across all discovery mechanisms.</t>

</section>
<section anchor="variation-agnostic-support-for-join-proxies"><name>Variation agnostic support for Join Proxies</name>

<t>Pledges or Agents often need to connect to a registrar that supports the variation of BRSKI
supported by the pledge or Agent via a Join Proxy. The Join Proxy needs to discover registrars
and the variations they support and then announce themselves to pledges or Agents accordingly
so that when the pledge or Agent connects to the Proxy that it will connect it to the right
registrar.</t>

<t>This document defines variations so that Join Proxies can be implemented and operated agnostic 
of variations: When a Join Proxy supports one variation for a particular IP version and transport
(TCP, UDP stateful/stateless), than it can support all current and future variations for the
same IP version and transport without the need for Join Proxy software or configuration updates.</t>

<t>To support agnostic implementations, variations can only differ in the payload of messages carried
across those TCP/UDP connections, but not the transport mechanisms used. New transport mechanisms can not be
variations, but need to be so-called contexts.</t>

<t>The choice of encoding of variations into different discovery methods also needs to ensure that it
can be discovered by legacy Join Proxy implementations.</t>

<t>Initial support for variations in proxies does create additional coding effort:
When a pledge or Registrar-Agent connects to a Join Proxy with the need to use a specific variation
on a registrar, then the Join Proxy needs to understand which variation that is, so that it can connect
the pledge or registrar to a registrar supporting that variation. This requires that proxies create
per-variation responder sockets.</t>

</section>
</section>
<section anchor="functional-summary"><name>Functional Summary</name>

<t>This document specifies a set of IANA registry tables for BRSKI. These tables allow to define
the attributes for different registry mechanisms to announce and discover different BRSKI role
responders as well as their variations. Defining these via registry tables maximizes consistency
across discovery mechanisms and eases support of variations across different discovery
mechanisms.</t>

<t>Using the discovery information specified through these tables, this document specifies
details of selection and fail-over when discovering more than one interoperable and available responder,
These procedures intend to provide resilience and scalability of BRSKI services not possible without dynamic
discovery mechanisms.</t>

<t>Finally, this document specifies procedures for Join Proxies to discover variations of registrars
using any discovery mechanism, annnounce them to pledges - and connect a pledge accordingly
to the right registrar based on the variation required by the pledge.  These procedures allow
to introduce new variations of BRSKI without need to upgrade proxies.</t>

</section>
</section>
<section anchor="specification"><name>Specification</name>

<section anchor="data-model"><name>Data Model</name>

<t>BRSKI Discovery is about discovery of one or more instances of responders supporting
a specific BRSKI role - and determining whether that responders variation of BRSKI protocol
options is compatible with / desired by the connection initiator. This section gives
the conceptual overview of how this is achieved.</t>

<section anchor="roles-and-services"><name>Roles and Services</name>

<t>In this document, a service is a specific functionality provided by a responder over
a network socket using a particular transport/security/session stack (such as TCP, UDP, COAP, DTLS).</t>

<t>In this document, a role is functionality performed by a BRSKI entity either as an initiator or responder.
<xref target="BRSKI"/> defines the roles of pledge, Join Proxy, registrar, MASA. <xref target="BRSKI-PRM"/>
adds the role Registrar-Agent. Trust anchor is a dependent role required by BRSKI, provided
through <xref target="EST"/> or other protocols in <xref target="BRSKI-AE"/>.</t>

<t>A single entity may implement multiple roles such as registrars that also often implement
the Join Proxy Role or pledges which change stop being a pledge after enrolment but often
then become Join Proxies. Future BRSKI documents may introduce additional roles and many of the definitions in this
document should be extensible to also support such additional roles.</t>

<t>In this document a service is functionality performed as a result of a network connection
from an initator to a responder. The service is commonly named after the role name of the responder,
such as Join Proxy, registrar or MASA.</t>

</section>
<section anchor="service-names"><name>Service Names</name>

<t>The role that a responder socket supports is indicated in each discovery mechanism through an
appropriate signalling element. <xref target="DNS-SD"/> calls this signalling element the Service Name. Due to
the absence of another equally widely used term for this type of signalling element across arbitrary
discovery mechanisms, this document also refers to the role signaling element as the service name,
 independent of the discovery mechanism.  IP Address, IP transport protocol and IP transport
protocol port are not part of the Service name and signalled across discovery mechanisms specific signaling elements.</t>

</section>
<section anchor="variations"><name>Variations</name>

<t>Variations in the BRSKI protocol such as the choice of encoding of messages or features
could impact interoperability between initiator and responder. Initiators
need be able to discover and select responders based not only on the desired role,
but also based on the best variation for the initiator.</t>

<t>Variations of a role could be indicated by using a different Service Name for every variation,
but that approach would have two challenges</t>

<t><list style="numbers">
  <t>Service Names in different discovery mechanisms are typically not hierarchical (e.g.: not
"role.variation"). Relying only on Service Names would thus require the registration for
every variation as a separate Service Name in a "flat" name space; and register them once for each discovery mechanism.
In addition, not all discovery mechanism registry rules may look favorably at the registration
of Service Names for such protocol variations.</t>
  <t>Whenever a new variation is introduced, all deployed BRSKI proxies would need to be configured
to also proxy this new variation - because new Service Names for the same BRSKI role can
be auto discovered by proxies (without additional protocol mechanisms that would be more
complex than the variations approach). Most Join Proxies should be able to operate without
configuration though.</t>
</list></t>

<t>For these reasons, this document introduces the encoding of BRSKI (role) variations
through a secondary signaling element in each discovery method, enabling proxies to transparently
support any variation of BRSKI role connections for which they supports proxying.</t>

<t>In addition, variations only need to be registered once in a BRSKI specific registry table introduced
by this document, and not once for each current or future discovery method.</t>

<t>A variation is hence specified as describing a combination of signaling choices that a BRSKI connection may
use and that impacts interoperability between initiator and responder at the message
exchange and encoding level.</t>

</section>
<section anchor="variation-types"><name>Variation Types</name>

<t>Today, BRSKI connections can exchange vouchers in one out of multiple different
encoding formats. Independent of that option, the BRSKI connection may also use different
commands (so called "Endpoints"). Today, these are based on whether <xref target="BRSKI-PRM"/> is used or not.
Finally, and also independent of those two options, the BRSKI connection may use one out of multiple
different enrollment protocol options.</t>

<t>This document calls these options "Variation Type", and the above three variation types
are called "vformat" for the voucher format, "mode" for the Endpoints being used (such as
PRM or not), and "enroll" for the enrollment protocol used.</t>

</section>
<section anchor="variation-type-choices"><name>Variation Type Choices</name>

<t>The actual choices for each of these variation types are hence called "Variation Type Choices":
"prm" or "rrm" for the variation type "mode". "cmsj", "cose" or "jose" for the variation type "vformat".
"est", "cmp" or "scep" for the variation type "enroll".</t>

<t>"scep" is an example for the ability of the registration to reserve values: it is not adopted
by any current BRSKI specification.</t>

</section>
<section anchor="variation-strings"><name>Variation Strings</name>

<t>The string name of a variation is as a string concatenating a single variation type choice for every
(necessary) variation type. For example "rrm-cmsj-est" could be describing the protocol options
used by a <xref target="BRSKI"/> connection pledge to registrar - potentially through a Join Proxy. This string
representation of a variation is called the variation string and it is consistently
used for signalling across any discovery mechanisms.</t>

<t>When in the future, additional variation types and choices are introduced, existing variation
strings must not be changed to allow full backward compatibility with existing/deployed implementations.</t>

<t>For example, when using BRSKI over UDP, today only COAPS is supported, but BRSKI UDP sockets
could equally work with QUIC (which runs on top of UDP). At that time, a new variation type of e.g.: "proto"
could be introduced with variation type choices "coaps" and "quic". For backward compatibility,
"coaps" then needs to be defined to be the default for BRSKI over UDP, which means that
existing variation strings such as "rrm-cmsj-est" imply the use of "coaps", whereas the use
of QUIC would have to be indicated explicitly via "rrm-cmsj-est-quic".</t>

<t>For variation strings to be semantically unambiguous, the variation type choices across all
variation types have distinct names, and the order in which variation type choices are
concatenated is the order in which variation types are defined in the according registry
table. Hence new variation type choices have to be tail added to the registry table.</t>

<t>Just because a variation name is composed from variation type choices does not mean that
an unspecified variation of (random) variation type choices can work without new implementation
or specification. Or even make sense. This may be the case, or it may not. This is also the reason
why this document specifies a registry that explicitly enumerates all variations that are
known to have sufficient specification and will work.</t>

<t>For example, <xref target="BRSKI-PRM"/> is indicated through the variation type value "prm", but it may also requires
enhancements to the enrolment protocol used, which is specified in the variation type "enroll", such as
new endpoints in that protocol.  The required functional semantic implied by the "enroll" variation type
value in variations with "prm" is thus a different one than in variations not using "prm". And
<xref target="BRSKI-PRM"/> does not necessarily sufficiently specify these enhancements for enrollment protocols
that may not have been known or specified by the time <xref target="BRSKI-PRM"/> was written.</t>

</section>
<section anchor="contexts"><name>Contexts</name>

<t>Variation strings are defined separately for every group of services for which the
set of variation strings is or could be different or could have different semantics.
A group of services for which the same variation strings are defined is called a Context.</t>

<t>Different list of variation strings are necessary when services have different variation types,
different variation type values, different deployed variations or different defaults
for the same variation type values and hence different variation strings.</t>

<t>"tBRSKI" is the context covering <xref target="BRSKI"/> connections (which are using TCP, hence the "t") from pledge to Join Proxy or registrar and from Join Proxy to registrar connections.</t>

<t>"cBRSKI" ("c"onstrained BRSKI) is the context covering <xref target="cBRSKI"/> 
connections (using UDP) from pledge to Join Proxy or registrar and from Join Proxy to registrar connections.</t>

<t>"BRSKI-PLEDGE" is the context covering pledges using <xref target="BRSKI-PRM"/> for connections
from Registrar-Agents to pledges. It can equally cover in the future through variations the discovery of 
<xref target="BRSKI"/> pledges for connections to them for other purposes - by introduction of
appropriate variation types and values for such additional purposes.</t>

<t>This document does not define variations for different end-to-end encryption mechanisms.
However, the mechanisms described here can also be used to introduce backward incompatible new secure transport options.</t>

<t>Also, this document does not introduce contexts for discovery of other BRSKI roles beyond those mentioned,
such as discovery discovery of MASA by registrars. However, the registries introduced by this document are defined such
that those can be introduced later as well through additional registry entries and specifications.</t>

</section>
<section anchor="discussion"><name>Discussion</name>

<t>Variations as defined by this document only cover protocol options that proxies can
transparently support so that the definition of variations allows to make proxies automatically
extensible.</t>

<t>Other responder selection criteria such as different responder priority or performance based selection 
(called weight in <xref target="DNS-SD"/>) are not covered by the variation concept but can
be used without change in conjunction with variations.  Some selection criteria may also only work with
discovery mechanisms that rely on specific procedures. Network distance to responder can for example
only be well supported by discovery mechanisms that can support per-hop forwarding between initiator
and responder, such as <xref target="GRASP"/>. Any of these criteria will work unchanged with the introduction
of Variations. Variations are simply one more selection criteria.</t>

<t>Differences in the supported transport stack of a responder are typically included as a
signaling element of the discovery method: Whether TCP or UDP or another IP transport protocol
is used, and whether the responder uses IP or even another network layer protocol.</t>

<t>In "sane" services where a change in transport spec does not imply a change in signalled messages
and their semantics, gateways could transparently proxy from IP and vice versa or
even between TCP and some other IP transport protocols such as SCTP. However, this is out of
scope of this specification.</t>

<t>The procedures specified in <xref target="cPROXY"/> would allow not only to
run a transport stack of COAP over DTLS, but equally any other transport stack over UDP, such
as QUIC - without any changes to the Join Proxy implementation or configuration when following
the procedures described in this document. All that is needed would be to introduce appropriate
registration entries for the registry tables specified in this document (e.g.: add new Variation Type
for transport and choices such as "coaps" or "quic" ).</t>

</section>
<section anchor="iana-registry-tables"><name>IANA Registry Tables</name>

<t>This sub-section re-states and summarizes the desired Data Model introduced before in it's
instantiation of the IANA Registry (and sub-registries) requested by this document,
the so-called "BRSKI Discovery Parameters" registry (<xref target="reg-discovery"/>).</t>

<t>The detailled requirements for registrations and initial content of the registry tables are
defined in the IANA section for it.</t>

<section anchor="discovery-mechanisms-registry"><name>Discovery Mechanisms registry</name>

<t>The main Discovery Parameters table ({#reg-discovery}) simply defines the abbreviations
for the Discovery Mechanisms specified for use with BRSKI Discovery: CORE-LF, DNS-SD and GRASP.
It allows to add new Discovery mechanisms and track where they are specified - including
outside the IETF.</t>

<t>This table is called the "main" table because the "BRSKI Discovery Parameters" is a
registry with sub-registries and one table has to be associated with the registry itself
instead of a sub-registry.</t>

</section>
<section anchor="contexts-sub-registry"><name>Contexts sub-registry</name>

<t>The IANA "Contexts" sub-registry, <xref target="subreg-contexts"/> registers names for different
groups of services in the overall BRSKI framework: BRSKI for <xref target="BRSKI"/> Registrar-&gt;Proxy-&gt;Pledge,
cBRSKI for constrained BRSKI (<xref target="cBRSKI"/> / <xref target="cPROXY"/>)
Registrar-&gt;(Proxy)-&gt;Pledge, and BRSKI-PLEDGE for <xref target="BRSKI-PRM"/> discovery of pledges.</t>

<t>Grouping services allows to limit registrations/definitions in other registry tables to
these Contexts as opposed to repeating them for every service (Registrar, Statelss-Registrar, Proxy 
for example).</t>

<t>Distinguishing BRSKI from cBRSKI is also necessary so that the different Transport Stack
parameter(s) between the two can be appropriately included into the registries (see <xref target="subreg-service-names"/>)</t>

<t>The Contexts sub-registry also registers the list of Variation Types defined for each context.
The Variation Types are the different aspects of the BRSKI protocols for which different
choices have been specified or could be specified.</t>

</section>
<section anchor="service-names-sub-registry"><name>Service Names sub-registry</name>

<t>The IANA "Service Names" sub-registry, <xref target="subreg-service-names"/> registers the "Service Names"
used to discovery the different BRSKI services for each context and Discovery Mechanism. It also
specifies the necessary (Transport Stack) Parameters that needs to be used in the discovery
mechanism to indicate (discover or recognize in discovery replies) the service. In the
initial table as specified by this document this is primarily used to distinguish BRSKI
services which use TCP and cBRSKI services which use coaps, also represented as UDP  in
some discovery mechanisms (such as DNS-SD).</t>

</section>
<section anchor="variation-type-choices-sub-registry"><name>Variation Type Choices sub-registry</name>

<t>The "IANA Variation Type Choices", <xref target="subreg-choices"/> depends on the definition of Variation Types
from the Contexts sub-registry, <xref target="subreg-contexts"/> by defining the specified choices for each
Variation Type and registers the specification(s) where they are defined.</t>

<t>Registration of a Variation Type Choice is per Context, so that different Contexts can
have different specification (and hence procedures) for the same Variation Type. In
the initial registry content requested by this document, this is used to refer to the
separate specification for BRSKI variations and cBRSKI variations.</t>

</section>
<section anchor="variations-sub-registry"><name>Variations sub-registry</name>

<t>The IANA "Variations" sub-registry, <xref target="subreg-variations"/> registers the so-called "Variation String"
encoding of variations of BRSKI protocols services for each Context. This is ultimately the
encoding specified in this document to be used to signal across all Discovery Methods the
actual Variations supported by a Service Instance. This sub-registry depends on the definitions
of the prior registry tables, which is why it is last.</t>

<t>A Variation is a combination of one Variation Type Choice for every Variation Type. Effectively,
it describes one way that a particular BRSKI service can operate. With the Variation Types
"mode", "vformat" (voucher format) and "enroll" (enrollment protocol) specified in this
document, it is possible to specify a Variation that has a different overall procedure: "mode"
can be "rrm" to indicate the pledge driven progression of BRSKI (as in <xref target="BRSKI"/> and
<xref target="cBRSKI"/>) or the "prm" Variation Type Choice as specified
in <xref target="BRSKI-PRM"/>. "vformat" specifies one one the encoding options possible
for the vocher exchanged in BRSKI, and "enroll" specifies the enrollment protocol, which
logically is separate from BRSKI but factually included into BRSKI because it so far not only
shares most of the time the secure Pledge to Registrar connection, but it also is an
interoperability requirement between Registrar and Pledge: Both need to support the same
encoding for a BRSKI exchange to finish successfully.</t>

<t>Some Variation Type Choices may actually impact other Variation Types, for example, "prm"
does impact also details relating to the enrollment protocol, and <xref target="BRSKI-PRM"/>
accordingly speficies how the <xref target="EST"/> ("enroll" = "est") needs to be modified to operate
"prm". For this reason, the Variations sub-registry only enlists Variations that 
are explicitly specified somewhere as actually being a working combination of Variation
Type Choices. Instead of simply permitting implementations to announce all the Variation
Type Choices seprately - and hope any combinations actually do work.</t>

<t>Variations are encoded as Variation Strings which are combined by concatenating the
Variation Type Choice strings with "-", leaving out those Variation Type Choices that
are the "Default" (Dflt in the sub-registry). This encoding scheme allows to maintain
unchanged old Variation Strings when introducing new Variation Types in a backward
compatible fashion. The backward compatible choice for a new Variation Type is marked
as "Dflt", does hence not need to be included in the Variation Type Choice, and hence
th pre-existing Variation Strings without the new Variation Type can continue to
exist and be used without changes.</t>

</section>
</section>
</section>
<section anchor="redundant-discovery-and-selection"><name>Redundant Discovery and Selection</name>

<t>The following subsections describe requirements for resilient and scalable responder
selection. Resilience is supported by automatically selecting the currently best available
responder. Scalability of simultaneous sessions is supported through distributing the connections from multiple
initiators to different responders if so desired through operator configuration of the
discovery methods parameters.</t>

<t>At the time of this specification, the relevant initiators are BRSKI pledges, Join Proxies and Registrar-Agents,
the relevant responders are Join Proxies and BRSKI Registrars. Nevertheless, the rules defined
in this document can equally apply to other BRSKI connections if and when discoverable and redundant
services are desired and added to the registries created by this document. For example discovery of MASA by BRSKI
Registrars.</t>

<t>Note that this specification does not mandate support for specific discovery methods in BRSKI
implementations, because this is specific to the target deployment scenarios - hence the
option to support different discovery methods.</t>

<t>Note that while pledges are discoverable in the context of this documents technologies, this section
and its subsections do not apply to discovery of pledges because there is no redundancy involved,
and selection of pledges is also only by their ID and not by their supported variation.</t>

<section anchor="responder-selection"><name>Responder Selection</name>

<t>If more than one responder is discovered by an initiator, then the initiator
<bcp14>SHOULD</bcp14> support to sequentially attempt to connect to each feasible responder exactly once until
it successfully connects to one. If it fails to connect to any feasible responder,
the initiator <bcp14>SHOULD</bcp14> wait until at least 30 seconds have elapsed since the start of the
last round and update its discoverable responder information from the discovery mechanism
if that is not already happening automatically by the chosen discovery method before it
restarts connection attempts.</t>

<t>A responder is feasible if it supports one or more of the variations requested by the inititor.</t>

<t>The order of responders to attempt connections to is derived from two criteria: preference and weight.</t>

<t>Preference order is foremost determined by the responders preference across the variations it
supports. Within the set of of responders with the same preference by the initiator because of their
variation, the preference is further determined from discovery method specific preference
parameters such as the "priority" parameter in DNS-SD, or possible future distance
parameters in discovery mechanisms like GRASP.</t>

<t>If a responder socket offers more than one variation supported by the initiator
its preference order is calculated from the most preferred variation supported by it.</t>

<t>Within a set of two or more responders with the same preference, the initiator <bcp14>MUST</bcp14> pick at random,
especially after power-on or other reboot events. This is to ensure that those events have
the chance to overcome possible persistent problems when persistently choosing the same
first responder. If deployments desire reproducable and predictable ordering of connection
attempts by initiators then they have to use the discovery specific mechanisms, such
as a different priority" parameter for each responder in DNS-SD to create such a strict
ordering across the different responder.</t>

<t>Initiators <bcp14>SHOULD</bcp14> support to take discovery mechanism specific weighting 
into account when determining the order of responders with the same preference,
such as the "weight" parameter in DNS-SD.</t>

<t>Support for the so far described resilient selection of responders <bcp14>SHOULD</bcp14> support
selection amongst at least 4 and no more than 10 responders with one or more
supported variation for each supported IP address family (v4 and/or v6). If more responders
are discovered for the preferred variation(s) of the initiator, then it <bcp14>SHOULD</bcp14> pick
a random subset of those responder announcements to select from.</t>

<t>4 Responders for a specific variation are a typical minimum resilience setup in a larger
network setup, in which 2 responders serve as redundancy at the responder host level and
the other 2 responders provide redundancy against network connectivity failure to those
first two responders. Intra-DC and Inter-DC service redundany is a simple example of such a setup.</t>

</section>
<section anchor="service-announcements"><name>Service Announcements</name>

<t>Responder selection as described in <xref target="responder-selection"/> needs to deal with
unresponsive responders because service announcements may be stale. This happens when
service announcements only loosely track aliveness of a service process.</t>

<t>In typical implementations, service announcement may be activated when the
service process starts, and stopped, when it stops. Problems such as a hanging (unresponsive)
service process will not be reflected in the service announcement setup. In addition,
caching of service announcements, such as through the DNS TTL field are a further
possible cause of assuming service aliveness that is not correct. Only actual
connection probing or other similar tracking can determine if a service responder is responsive
to the level of accepting connections.</t>

<t>Responders intended to be used in resilient deployments <bcp14>SHOULD</bcp14> therefore ensure
that their service announcements are not active when the responder died or would
have failed to successfully accept connection for 120 seconds or more. This can
be implemented for example by connection probing once every 30 seconds and
withdrawing the service announcements when this fails or by other forms
of tracking responsiveness of the responder functionality.</t>

<t>The better service announcements indicate actual aliveness of the service instances, the
faster service selection will be. In addition, in large networks, backup/standby
service instances can then be implemented by tracking primary service announcemements
and activating the backup only when the primary ones fail. Such dynamic backup
can further reduce the overall load on the discovery mechanism system used and
on initiators.</t>

</section>
<section anchor="proxy-selection"><name>Responder Selection in Proxies</name>

<t>Unless amended by the requirements listed below, proxies <bcp14>SHOULD</bcp14> follow all the
descripton from <xref target="responder-selection"/>.  Note that the randomn selection of
responders with the same preference also applies to stateful proxies and ensures
load balancing (including weighting) across multiple simultaneously connecting pledges.</t>

<t>Stateful proxies <bcp14>SHOULD</bcp14> optimize selection of responders for each variation across
connections for multiple pledges instead of starting the sequence of responders
to try from the highest precedence anew for every new connecting pledge - and repeatedly run
into timeouts for each new connecting pledge when those primary responders time out
on connection attempts because they are unresponsive or unreachable. Instead, after a
responder first fails to connect, the Join Proxy <bcp14>SHOULD</bcp14> skip this responder in further
connection attempts for other connecting pledges.</t>

<t>Stateless proxies cannot learn unresponsiveness or unreachability of a responder
through connection attempts. Instead, they <bcp14>SHOULD</bcp14> perform a stateless responsiveness/reachability
check for each responder that the Join Proxy is actively forwarding packets to from
one or more pledges.  If no packets are returned from such a responder over a period of more
than 30 seconds, then the responder <bcp14>SHOULD</bcp14> be considered unreachable for at least
180 seconds. Unreachability signaling received in response to packets sent to the
responder <bcp14>SHOULD</bcp14> trigger this unreachability status after it persists for 10 seconds.</t>

<t>Load balancing as described in <xref target="responder-selection"/> is <bcp14>NOT RECOMMENDED</bcp14> for
stateless proxies because per-pledge stateless load balancing may involve more
processing complexity than feasible for proxies on
constrained devices. To avoid changing the selection of
active responders when one responder becomes unresponsive, a "stable hash" approach would have
to be used, such as described in <xref target="HRW98"/>, which is used for example by <xref target="I-D.ietf-bess-evpn-fast-df-recovery"/>.
Supporting weights with stateless proxying is even more complex. Instead of
load balancing, responders simply need to be designed to scale to the maximum
amount of simultaneous initiator connections necessary when supporting stateless
proxying mode.</t>

</section>
<section anchor="announcement-protection"><name>Protection against malicious service announcements</name>

<t>Initiators including proxies <bcp14>SHOULD</bcp14> always pick the highest possible priority and weight
parameters possible in the discovery mechanism used that allows to support the
desired preference goals. For example, any primary initiator should select the highest
numerical values possible.</t>

<t>This recommendation is intended as a protection against erroneous, but not malicious
service announcements whenever the default priorities are lower than the maximum
priority. It can also serve as a weak protection against malicious announcements
because with the selection rules required by this document, initiators still have
the highest chance of picking the non-malicious announcement.</t>

<t>While being weak, this recommendation can still be better than nothing against such
malicious announcement. These recommendations <bcp14>SHOULD</bcp14> be superseded by better
recommendations for more narrowly scoped deployment scenarios.</t>

</section>
</section>
<section anchor="join-proxies-support-for-discovery-and-variations"><name>Join Proxies Support for Discovery and Variations</name>

<section anchor="proxy"><name>Join Proxy support for Variations</name>

<t>A Join Proxy compliant with this specification <bcp14>MUST</bcp14> support announcing its
Join Proxy responder socket(s) to which pledges can connect via at least one
of the discovery methods included in the registry tables specified in this
document. The Join Proxy <bcp14>MUST</bcp14> announce the variation(s)
supported on its responder socket(s) according to the registry table entries.</t>

<t>A Join Proxy <bcp14>SHOULD</bcp14> support to pass packets for any variation for which
it has discovered one or more registrar sockets supporting that variation without the
need for the variation to be known at the time of implementation of the Join Proxy
or configured on the Join Proxy. If a Join Proxy supports this requirements, this is
called support for "arbitrary variations". Supporting this requirement requires
the Join Proxy to discover registrar(s) and their supported variation(s) via one or more
of the discovery mechanisms included in the registry tables specified in this document.</t>

<t>Arbitrary variations support allows to deploy proxies once and add
pledges and registrars supporting new variations later - without upgrade
or change of configuration of proxies.</t>

</section>
<section anchor="registrar-operations-modes"><name>Registrar Operations Modes</name>

<t>Proxies may use different approaches to connect to registrars. The following
subsections discuss the primary relevant options.</t>

<section anchor="direct-connection"><name>Direct Connection Mode</name>

<t>In one Join Proxy implementation option called "direct connections", the Join Proxy creates for every discovered registrar
socket a separate Join Proxy responder socket. It announces this socket with the same set of parameters
as it did learn from the registrar's service announcement, except for the appropriate Join Proxy service name
and socket parameters (IP address, port number). When a pledge connects to that socket, the
Join Proxy passes traffic for that pledge's connection to and from the respective registrar socket.</t>

<t>When using the direct connections approach, the task of selecting the best registrar socket for
a particular variation is left to pledges because they are exposed to at least the same number 
of service announcements from proxies as proxies see service announcements from registrars - and the
pledge has to select the best available one from them.</t>

<t>To reduce the number of sockets that have to be announced by proxies when using direct connections
and to also reduce the number of responder sockets that need to be maintained by a Join Proxy operating
in this approach, these proxies <bcp14>SHOULD</bcp14> limit the number of registrar sockets they maps to between 4 and 10
best registrar sockets as described in <xref target="responder-selection"/> per variation.</t>

</section>
<section anchor="best-registrar"><name>Best Registrar Selection Mode</name>

<t>In the implementation mode "best registrar selection", the Join Proxy creates a separate responder socket
for a set of all registrar sockets that it discovers and that announce support for the same set
of variations.</t>

<t>For pledges to discover the Join Proxy, the Join Proxy then announces this socket with the parameters of
the best discovered registrar socket, replacing the service name and network parameter names with those
for its Join Proxy responder socket as in the case of a direct connection.</t>

<t>The Join Proxy then connects pledges to the best available registrar socket from that set when
it receives a connection to that socket.</t>

<t>When performing best registrar selection for that connection, the Join Proxy has to perform selection of the
best availalable responder as described in <xref target="responder-selection"/>.</t>

<t>Using newly discovered responders in stateless proxies supporting best registrar selection must be done carefully.
Consider the common case that service announcements for a primary responder
did stop due to network issues, now the Join Proxy starts to send packets to a secondary
responder, and then the primary responder becomes reachable and the Join Proxy sees
service announcements for it. If the Join Proxy would now start to forward packets
from pledges to this primary responder due to its higher precedence, then this
could unnecessarily break ongoing connections from clients whose packets
are currently forwarded to the lower preference Join Proxy. Direct connection mode does
not incur this problem, because the pledge can select another Join Proxy responder socket
when it discovers the first one to be unresponsive or erroneous.</t>

<t>Replacing a selected responder in a stateless Join Proxy with a better one
<bcp14>SHOULD</bcp14> hence only be done if no packets have been exchanged between pleges
and the current selected responder through the Join Proxy for more than 300 seconds.
This long timeout specifically intends to not break connections in which the
registrar keeps the pledge waiting for an administrative response such as
an operator performing a policy validation for enrollment.</t>

<t>In addition, stateful proxies implementing best registrar selection <bcp14>SHOULD</bcp14>
optimize selection of registrar for each Join Proxy responder socket across
connections for multiple pledges instead of starting the sequence of responders
to try anew from the highest precedence registrar for every new connecting pledge - and repeatedly run
into timeouts when one or more of the best registrar time out on connection attempts
because they are unresponsive or unreachable. Instead, after a
responder first fails to connect, the Join Proxy <bcp14>SHOULD</bcp14> skip this responder in further
connection attempts for other connecting pledges and re-consider it only for new
connection attempts after at least 60 seconds.</t>

</section>
<section anchor="proxy-in-service-name-only-mode-on-registrars"><name>Proxy in Service Name Only Mode on Registrars</name>

<t>Registrars that implement support for connections from stateful proxies
and/or from pledges may minimize their Join Proxy implementation work by only implementing
the appropriate service name announcements for the same socket to support
connections from both:  announcements as a registrar for connections from
proxies and announcements as a Join Proxy for connections from pledges.
No additional sockets or other Join Proxy specific packet processing code
is required to support this.</t>

<t>Registrars that implement support for connections from stateless proxies can
share that implementation for connections from pledges by also implementing
simple UDP&lt;-&gt;JPY header conversion (see <xref target="cPROXY"/>).
Nevertheless, they do need to do this via
a separate socket and hence need to announce the two sockets separately:
UDP for connections from pledges with the Join Proxy service name, and UDP with JPY header for 
connections from stateless proxies with the stateless registrar service name.</t>

<t>Proxy functionality that is implemented as described here on registrars
is called "proxy in service name only mode", because such an implementation
cannot discover, select and fail over between different registrars.
Such proxies in name only therefore do not share requirements
against discovering and selecting registrars described for the prior specified
modes.</t>

<t>Like other proxies, proxies in name only <bcp14>SHOULD</bcp14> nevertheless track
aliveness of their registrar function and withdraw its service
announcements (both as Join Proxy as well as as registrar) when it does not run,
fails or becomes unresponsive.</t>

<t>Proxies in name only <bcp14>SHOULD</bcp14> default to the same discovery method priority and
weight parameter as those configured for the registrar service announcements.
This is so that in the absence of separate proxies in the network selection
of registrars co-located proxies would follow the same criteria as those
used by proxies and which use the registrar service announcement parameters.</t>

</section>
<section anchor="proxy-mode-discussion"><name>Proxy Mode Discussion</name>

<t>This document defines no requirements against the implementation mode for proxies.
Those are left for solution or deployment (profile) specifications. Instead, this
section discusses some considerations for those choices.</t>

<t>The list of possible modes presented is exemplary and not meant to be exhaustive.
Other modes are equally able to support the requirements, such as mixtures
of the described modes. Likewise, introduction of new variations may not
only work well via arbitrary variation support in proxies, but through
explicit configuration of variations on proxies - this all depends on
the target deployment environment. The presented modes where choosen
primarily as the ones providing most configuration free deployment options and
for registrar implementations most simplicity in implementation.</t>

<t>If a deployment has a larger number of service announcements and (extremely)
constrained pledges, direct connection mode may be inappropriate because it shifts
the burden of best available discovery and selection and onto the pledge. If
simultaneously proxies in such deployments can support more scalable complex implementations,
then best registrar selection mode may be most appropriate.</t>

<t>In environments, where all pledges are expected to become proxies after enrollment,
implementers may simply want to implement the option for which both pledge and
Join Proxy code together is easiest to implement.</t>

<t>Even on registrars, proxy in service name only mode may not suffice deployment requirements
or provide best redundancy.  For example, the co-located registrar may incur 
problems, not applicable to alternative registrars, such as for example Internet
connectivity problems to MASAs when different registrars have different
Internet connectivity. If the registrar co-located Join Proxy is then
still the only Join Proxy available to some candidate pledges, then this Join Proxy
needs to be able to connect to an alternative registrar, which would
not be possible if it was a proxy in service name only.</t>

<t>Likewise, proxy in service name only mode will disturb the introduction of new variations
on pledges and other registrars in the network if the registrar node implementing
proxy in service name only mode becomes a necessary Join Proxy for a pledge requiring a
variation not supported by this registrar, but by another registrar that
would only be reachable through this registrar node. Therefore, Join Proxy
in name only mode is best suited for node types not deployed on an edge
of the network where a future variety of pledges may connect to, and those
pledges will require the use of a Join Proxy.</t>

</section>
</section>
<section anchor="extensibility-to-non-brski-services"><name>Extensibility to non BRSKI services</name>

<t>Join Proxy implementations using the procedures described in this document can easily
be reused for any other protocols beside BRSKI as long as they use TCP or UDP.
For this, it would simply be required that the Join Proxy can be configured with
pairs of service names other than those used by tBRSKI/cBRSKI: A service name to
discover, and a service name to use for the Join Proxy responder socket service announcements.</t>

</section>
<section anchor="scaling-service-discovery-and-selection"><name>Scaling service discovery and selection</name>

<t>Discovering and selecting an available service instance can become a design challenge
in large networks with many redundant service announcements.</t>

<t>Consider for example the common case of allowing BRSKI registration in a network
with many geographically spread out sites such as in enterprise,  industrial or
building construction environments. During initial bringup of such sites, 
Internet connectivity may be non-existing, or intermittant, and hence one or more
local registrar in each such site is higly desirable. Such registrars may of course
require private mobile network connectivity to MASA, or rely on out-of-band provisioning
of vouchers.</t>

<t>Later, when such a site does get a well working wide-area network connection,
it may be more appropriate to use more centralized registrars, but a local registrar
as a backup may be considered useful. However, if the service announcements of such
per-site decentralized registrars would be discoverable across the whole geographically
spread out network, then this could introduce a potentially significant
overhead to the service announce and discovery system when for example more
than 100 registrar service announcments exist in the network, and pledges/proxies
connect to them.</t>

<t>Such large number of redundant service announcements is typically highly undesirable,
and appropriate configurations of service discovery mechanisms need to be used
to avoid them. For example, in GRASP, service announcements can be scoped to small hop counts,
Anycast addressing can be used to make all decentralized registrars overload
the same ip address, and hence make them all share the same service announcement.</t>

</section>
</section>
<section anchor="brski-pledge"><name>Discoverable BRSKI Pledges</name>

<section anchor="brski-pledge-context"><name>BRSKI-PLEDGE context</name>

<t>BRSKI-PLEDGE is the context for discovery of pledges by nodes such as Registrar-Agents.
Pledges supporting <xref target="BRSKI-PRM"/> <bcp14>MUST</bcp14> support it. It may also be used by other variations of BRSKI
outside of the PRM use case, for example for inventorizing pledges.</t>

<t>Pledges supporting BRSKI-PLEDGE <bcp14>MUST</bcp14> support DNS-SD for discovery via mDNS, using link-local scope.
For DNS-SD discovery beyond link-local scope, pledges <bcp14>MAY</bcp14> support DNS-SD via <xref target="DNSSD-SRP"/>, using
automatic discovery of the SRP server and registering the below defined DNS-SD data with it.</t>

<t>These DNS-SD requirements are defaults. Specifications for specific deployment contexts such as specific
type of radio mesh network solutions may need to specify their own requirements overriding or amending these
requirements.</t>

<t>Pledges <bcp14>MUST</bcp14> support to be discoverable via their DNS-SD service instance name.</t>

<t>Pledges <bcp14>SHOULD</bcp14> support to be discoverable via DNS-SD browsing, so that Registrar-Agents can find
unexpected pledges or can enumerate expected pleges more easily, especially in the presence of multiple
different subnets and use of mDNS. A pledge can also only be found by browsing if it is not
possible for the owner to aquire serial-number information of a pledge by the time BRSKI-PRM  needs it
(to create a service instance name).</t>

<t>When pledges are discoverable vis DNS-SD browsing, the "brski-registrar" PTR service name is a
so-called shared resource record. When it is requested via mDNS (multicast), all pledges supporting
BRSKI-PLEDGE and browsing will respond simultaneously, potentially creating congestion/contention.
To avoid this, <xref target="mDNS"/> specifies the following requirement: "each responder <bcp14>SHOULD</bcp14> delay its
response by a random amount of time selected with uniform random distribution in the range 20-120 ms."</t>

<t>It is equally <bcp14>RECOMMENDED</bcp14> to apply the same random delay rule for answers to multicasted or
flooded queries in other discovery mechanisms that have the same response burst problem - even when
they do not specify such a mechanism, such as in GRASP.</t>

<t>If browsing is not desired by a pledge, the pledge does simply not respond to queries for the
"brski-registrar" service name in mDNS or other discovery mechanism queries for the equivalent
service name, or does not register its PTR RR for this service name when using unicast DNS-SD via
<xref target="DNSSD-SRP"/>. This does not affect operations for the service instance name.</t>

<t>This specification does not introduce the procedures to discover pledges via CORE-LF or GRASP
because it is unclear if there is currently demand for this, and because it can easily be added
via additional specs and adding entries to the registry.  For CORE-LF, browsing of entries
can be supported via CORE-RD ({RFC9176}}), with appropriate auto-discovery of the CORE-RD server.
For GRASP, this could be done via a method mapping DNS-SD into GRASP, such as <xref target="I-D.eckert-anima-grasp-dnssd"/>,
specifically to support browsing of pledge instance names.</t>

</section>
<section anchor="service-instance-name"><name>Service Instance Name</name>

<t>The service instance name chosen by a BRSKI pledge <bcp14>MUST</bcp14> be composed from information which is</t>

<t><list style="symbols">
  <t>Easily known by BRSKI operations, such as the operational personnel or software automation,
specifically sales integration backend software.</t>
  <t>Available to the pledge software itself, for example by being encoded in some attribute of the IDevID.</t>
</list></t>

<t>Typically, a customer will know the serial number of a product from sales information, or even
from bar-code/QR-codes on the product itself. If this serial number is used as the service instance
name to discover a pledge from a Registrar-Agent, then this may potentially (but unlikely) lead to (duplicate) replies
from two or more pledges having the same serial number, such as in the following cases:</t>

<t><list style="numbers">
  <t>A manufacturer has different product lines and re-uses serial-numbers across them.</t>
  <t>Two different manufacturers re-use the same serial-number space.</t>
</list></t>

<t>If pledges enable browsing of their service instance name, they <bcp14>MAY</bcp14> support DNS-SD specified
procedures to create unique service instance names when they discover such clashes, by appending
a space and serial number, starting with 2 to the service instance name: "&lt;service-instance-name&gt; (2)",
as described in <xref target="DNS-SD"/> Appendix D.</t>

<t>Nevertheless, this approach to resolving conflicts is not desirable:</t>

<t><list style="symbols">
  <t>If browsing of DNS-SD service instance name is not supported, Registrar-Agents would have to
always (and mostly wrongly) guess that there is a clash and (mostly unnecessarily) search
for "&lt;service-instance-name&gt; (2)".</t>
  <t>If a clash exists between pledges from the same manufacturer, and even if the Registrar-Agent
then attempts to start enrolling all pledges with the same clashing service instance name,
it may not have enough information to distinguish pledges other than by the randomn numbering. This would happen
especially if the IDevID from both devices (of different product type), had the same serial
number, and the trust anchor certificate of both was the same (e.g. same root CA certificate), which is likely when they are from the same manufacturer.
Even if some other IDevID field was used to distinguish their device model, the Registrar-Agent
would not be able to determine that difference without additional vendor specific programming.</t>
</list></t>

<t>In result:</t>

<t><list style="symbols">
  <t>Vendors <bcp14>MUST</bcp14> document a scheme how their pledges form a service instance name from
information available to the customer of the pledge.</t>
  <t>These service instance names <bcp14>MUST</bcp14> be unique across all IDevID of the manufacturer that
share the same trust anchor.</t>
</list></t>

<t>The following mechanisms are recommended:</t>

<t><list style="symbols">
  <t>Pledges <bcp14>SHOULD</bcp14> encode manufacturer unique product instance information in their
subject name serialNumber. <xref target="RFC5280"/> calls this the X520SerialNumber.</t>
  <t>Pledges <bcp14>SHOULD</bcp14> make this serialNumber information consistent with easily accessible
product instance information when in physical possession of the pledge, such as
product type code and serial number on bar-code/QR-code to enable <xref target="BRSKI-PRM"/> discovery
without additional backend sales integration. Note that discovery alone does not
allow for enrollment (so it does not introduce a security risk by itself)!</t>
  <t>Pledges <bcp14>SHOULD</bcp14> construct their service instance name by concatenating
their X520SerialNumber with a domain name that is used by the manufacturer
and thus allows to disambiguate devices from different manufacturer using the
same serialNumber scheme, and hence the likelihood of service instance name clashes if manufacturer names are not used.</t>
  <t>Pledges <bcp14>MAY</bcp14> re-use the service instance name as their host name in their AAAA or A RRs.</t>
</list></t>

</section>
<section anchor="example"><name>Example</name>

<t>This section discusses an example manufacturers approach using the recommendations
from above.  <xref target="service-name-example"/> shows the different data involved in DNS-SD records
for a pledge from manufacturer "Example".</t>

<figure title="Example IDevID and DNS-SD data" anchor="service-name-example"><artwork><![CDATA[
    1. Manufacturer published information:
    
      1.1 IDevID trust anchor certificate.
    
      1.2 IDevID X520 identification schema:
        Brand: Example
          O = example.com, serialNumber = "PID:Model-<PID> SN:<SN>"
          ; Explanation:
          ; SN = Serial Number, PID = Product Identifier
          ; O = Organization
    
      1.3 DNS-SD Instance Schema:
        <X520SerialNumer>.example.com
    
    2. Example Purchase Order Pledge Information
       Brand: Example, Model: 0815, Serial: WLDPC2117A99
    
    3. DNS-SD Instance string:
      "PID:Model-0815 SN:WLDPC2117A99.example.com"
    
    4. DNS-SD RR for the pledge (using mDNS, hand hence .local):
      ; PTR RR to support discovering the pledge through browsing,
      ; e.g. when the serial number is not known in advance
      _brski-pledge._tcp.local  IN PTR
        PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com._brski-pledge._tcp.local
    
      ; SRC and TXT RR for the service instance name
      PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com._brski-pledge._tcp.local
        IN SRV 1 1
        PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com.local
      PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com._brski-pledge._tcp.local
        IN TXT ""
    
      ; AAAA address resolution for the target host name
      PID:Model-0815\\ SN:WLDPC2117A99\\.example\\.com.local
        IN AAAA fda3:79a6:f6ee:0000::0200:0000:6400:00a1
    
    5. Example Pledge IDevID certificate information:
        ; Format as shown by e.g.: openssh
        Subject: serialNumber = "PID:Model-0815 SN:WLDPC2117A99",
         O = example.com, CN = Model-0815
]]></artwork></figure>

<t>Using the information from the above Example picture, a Registrar-Agent
implementation operates as follows.</t>

<t><list style="numbers">
  <t>Initially, it is configured with the Manufacturer published information (1.),
and as not shown it will likely have a list of such information for various
brands of products.</t>
  <t>After a pledge purchase and initial physical deployment,
it is provided with the Purchase Order information for the pledge (2.),
this order information tells it, that the Manufacturers Brand is "Example",
that the pledge product Model &lt;PID&gt; is "0815" and its Serial Number &lt;SN&gt;
"WLDPC2117A99".</t>
  <t>It looks up the IDevID X520 identification schema for brand "Example" and
uses the template value for the serialNumber field together with the
pledge information values from (2.) for O, &lt;PID&gt; and &lt;SN&gt; to determine 
the DNS-SD Instance of the pledge (3.). That instance is the concatenation
of the X520 serialNumber value of the pledge with the Organization
domain name of the manufacturer. With the Organization being a global
DNS domain "example.com", including this in the Instance makes it unique
across manufacturers.</t>
  <t>It then uses standard DNS-SD via mDNS to find the pledge, using the DNS-SD 
Resource Records (RR) shown in 4.</t>
  <t>Once it receives a response from the device claiming to be the pledge,
it can use any appropriate authentication mechanism to validate
ownership of the IDevID private key. In <xref target="BRSKI-PRM"/> this is done through
the initial TLS handshake in which it learns the presumed IDevID of the
pledge. When the signature in the IDevID matches the public key of the
desired Manufacturer from (1.1), then it trusts that this pledge is from
that manufacturer. When the O and serialNumber of the certificate match
what it constructed from the &lt;PID&gt;/&lt;SN&gt; values from purchase information 
from (3.) then it also trusts that this is indeed the pledge it was
looking for.</t>
</list></t>

<t>Instead of using sales receipt information, the customer may also use scanned
QR/Barcode or RF-Tag information from packaging after receiving shipments for
example for step 2. Scanning packaging information will likely will introduce additional
complexity because the manufacturer name can often only be derived from
information such as EAN-13 barcodes.</t>

<t>The process steps may also be simpler if the customer can know the IDevID of the pledge
through the purchase process instead of having to match the IDevID from sales receipt information
(step 2).</t>

<t>The process steps may also become more complex. The manufacturer may have multiple
brands using the same trust anchor. Or the manufacturer may have certificate
chains and different production sub-companies may use different sub-CA certificates in the signing
chain. Or the serialNumber alone is not unique across the certificate chain,
but further Subject fields of the certificate are required for a unique
identification, such as the O)rganization field. It could contain for example
one out of multiple brand names that use simple numerical serialNumber formats
and hence could collide.  None of such complexities are desirable for new designs,
but they may be necessary to support BRSKI for existing products.</t>

<t>For the described mechanism to work, the manufacturer does not necessarily
have to own a domain name such as "example.com" in the example. Owning a
domain name and using it for the DNS-SD Instance Schema is just a simple
way to ensure usage of a unique Instance Schema - if all manufacturers
agree to use this approach.</t>

<t>The RR used to discover the pledge by its serial number is the
"IN SRV" RR.  The "IN PTR" RR is optional and allows for the pledge to
be discovered with DNS-SD browsing, which is necessary if the
pledges serial number information can not be known by the time the
pledge needs to be enrolled by a Registar-Agent.</t>

<t>The instance string is also re-used in the host name of the "IN SRV"
RR and hence the domain name of the "IN AAAA" RR. The is just an option,
and the pledge can use whatever host name it wants.</t>

</section>
<section anchor="webpki-derived-instance-schema"><name>WebPKI derived instance schema</name>

<t>There is currently no automated mechanism to avoid the configuration of
manufacturer trust anchor certificates in BRSKI components that need to
authenticate pledges. However, the configuration of additional instance
schemas for different manufacturer device names in BRSKI
equipment could be avoided if it is deemed appropriate by vendors and
operators of BRSKI-PLEDGE installations to rely on WebPKI trust anchors.</t>

<t>The trust anchor certificate itself (or a sub-CA in the certificate chain)
would then have to have a WebPKI trust anchor signature and a DNS Name
that can easily be identified as being used for IDevID, such as
"*.idevid.example.com". And the implied schema for the instance
string is then "&lt;&lt;X520SerialNumer&gt;.DNS-name&gt;", authenticating instance
names of the format "&lt;X520SerialNumer&gt;.idevid.example.com&gt;".</t>

<t>Obtaining a WebPKI signature for their trust anchor for these wildcard domain
names from a WebPKI trust anchor is the added effort for manufacturer of this scheme.</t>

</section>
</section>
<section anchor="variation-signaling-and-encoding-rules-for-different-discovery-mechanisms"><name>Variation signaling and encoding rules for different discovery mechanisms</name>

<section anchor="dns-sd"><name>DNS-SD</name>

<section anchor="signaling"><name>Signaling</name>

<t>The following definitions apply to any instantiation of DNS-SD including DNS-SD via mDNS as defined in
<xref target="DNS-SD"/>, but also via unicast DNS, for example by registering the necessary DNS-SD Resource Records (RR) 
via <xref target="DNSSD-SRP"/>.</t>

<t>Because of the different options of how to run DNS-SD, the requirements in this document do not guarantee
interoperability when using DNS-SD. One side could use unicast DNS-SD, the other mDNS, and there may be
no mapping between the two. Therefore the recommendations in this document need to be amended
with deployment specific specifications / requirements as to which signaling variation, such as mDNS
or unicast DNS with SRP is to be supported between initiator and responder. When using unicast DNS
(with SRP), additional mechanisms are required to learn the IP address(es) of feasible DNS and
SRP servers, and deployment may also need agreements for the (default) domain they want to use in
unicast DNS. Hence, a mandatory to implement (MTI) profile is not feasible because of the wide range
of variations to deploy DNS-SD.</t>

<t>In the absence of overriding deployment profile requirements, implementations are
<bcp14>RECOMMENDED</bcp14> to support mDNS and <bcp14>MAY</bcp14> support <xref target="DNSSD-SRP"/> and fall back to mDNS
if <xref target="DNSSD-SRP"/> fails to work, e.g.: it fails to discover SRP server and/or default domain.</t>

</section>
<section anchor="variation-string-encoding"><name>Variation String Encoding</name>

<t>Variation Strings from the IANA registry <xref target="fig-variations"/> are encoded as DNS-SD Keys with
a value of 1 in the DNS-SD service instances TXT RR using the shortened encoding of "key" instead of "key=1".
In result, the value of the TXT RR is a sequence of zero terminated strings, each one indicating a single supported
variation type choice.</t>

<t>A variation may have the option of being represented by the empty string "". This is not allowed
in the DNS-SD encoding, and instead the alternative variation string <bcp14>MUST</bcp14> always be used for DNS-SD.</t>

<t>Variation strings in DNS-SD are case insensitive as required by DNS-SD. It is <bcp14>RECOMMENDED</bcp14> to only
announce lowercase variation strings in DNS-SD.</t>

<t>The use of variation strings can easily break the DNS-SD rule that they keys should be no more than
9 characters long. This is justified by the absence of value fields to keep the total length of the
TXT RR reasonably short.</t>

</section>
<section anchor="service-instance-and-host-names"><name>Service Instance and Host Names</name>

<t>To be able to specify for each responder socket individually its supported variations as well
as its selection criteria (priority weight), it needs to be represented in DNS-SD as a
service instance name with an SRV and TXT RR. In BRSKI-PLEDGE <xref target="brski-pledge"/> the service instance
name is significant as it is what a Registrar-Agent may need to discover, but in tBRSKI and cBRSKI
it is merely an artefact of DNS-SD encoding: Unlike typical user-centric DNS-SD use-cases, there are
no users that need to make sense of the meaning of the service instance name, for example to know,
which printer to pick. Only operators may need to look at them for troubleshooting.
The choice of instance name (the first component of a service instance name) is hence arbitrary. The same
is true for the host names used in the DNS-SD records for BRSKI.</t>

<t>Registrars <bcp14>SHOULD</bcp14> support automatic generation of their service instance name for their DNS-SD
operation to avoid additional need for operator configurations. Registrars <bcp14>SHOULD</bcp14> likewise support the
configuration of such a name - if the operator so desires to support operational troubleshooting.</t>

<t>If the host on which the registrar is running already has a DNS host name for the IP addresses
used by the registrar and for the desired DNS method (mDNS = .local, unicast DNS = default domain),
then the registar <bcp14>SHOULD</bcp14> be able to use that host name as the target domain name in the SRV RR.
This requirement avoids the unnecessary addition of DNS A/AAAA RRs because of the registrar,
when useable RRs already exist.</t>

<t>If such a DNS RR does not exist, but a DNS host name for a different DNS method, or a different set of
addresses than used by the registrar, then the registrar <bcp14>MAY</bcp14> be able to use a target domain
name derived from that primary domain name by appending a unique name element. This requirement
exist to avoid the creation of unnecessarily inconsistent host names.</t>

<t>If no DNS host name exists, the registrar <bcp14>MUST</bcp14> be able to automatically create a DNS host name
and the A and/or AAAA RRs for the address(es) used by the registrar for use in the SRV RR target field.
This requirement exists to ensure that operators are not unnecessarily required to configure a host name
on a system that does not need one - and none is required to run a registrar.</t>

<t>A registrar <bcp14>MAY</bcp14> use any unique identifiers of its host system as its instance name or host name.
This can avoid or at least minimize the need to automatically pick another name in case the chosen
name is already taken by another system. This for example would happen if a registrar tried to
use an instance component such as "registrar" and there is already another registrar. Using a
known unique identifier allows a registrar to raise an alert and claim an operational error 
with a high degree of confidence.</t>

<t>MAC addresses are only unique when an application such as a registrar understands what hardware it
is running on, and that the MAC address was assigned by registering its OUI with IEEE and that
MAC addresses from the OUI were assigned uniquely. This is for example not necessarily the
case for IoT equipment or registrars running in a virtual context in the cloud. IP addresses
can be assumed to be unique (enough) when they have global scope or ULA.</t>

<t>When registrar software does not know that no other registrar software or instance of the same
software may run on the same host (for example when being packaged as an application), the
registrar <bcp14>SHOULD</bcp14> not assume that a host unique name is actually unique, but instead disambiguate
it by appending an additional name element to make it unique, such as a process number of the
running process.</t>

<t>Picking well-known or unique identifiers for registrar also helps operator to troubleshoot by often
eliminating the need to also know the IP addresses associated with the name.</t>

<t>Target host names need to follow the requirements for host names. By those requirements, it is not
permitted to use ":" in target host names, for example as part of MAC or IP address based host names.
Instance names do not share these syntactical limitation. For operational simplicity,
instance names <bcp14>SHOULD</bcp14> be constructed in the same manner as target hostnames in an implementation.
For example by replacing ":" with "-".</t>

<t>If the responder needs to indicate different sockets for different (set of) variations, for example,
when operating as a Join Proxy, according to <xref target="proxy"/>, then it needs to signal for each socket a
separate service instance name with the appropriate port information in its SRV record and the
supported variations for that socket in the TXT Record of that service instance name. A responder
<bcp14>MAY</bcp14> create the instance and host name for such different variation sockets by appending the variation
string to the previously determined instance and host names.</t>

</section>
<section anchor="examples"><name>Examples</name>

<t>These example use OUI and IPv6 addresses reserved for documentation
purposes. Do not re-use these addresses in actual deployments</t>

<figure title="DNS-SD for single registrar supporting tBRSKI/cBRSKI variations" anchor="dnssd-example-1"><artwork><![CDATA[
# tBRSKI context
_brski-registrar._tcp.local
               IN PTR  0000-5e00-5314._brski-registrar._tcp.local
0000-5e00-5314._brski-registrar._tcp.local
               IN SRV  1 2 4555 0000-5e00-5314.local
0000-5e00-5314._brski-registrar._tcp.local
               IN TXT  "est-tls" "prm-jose" "cmp"

# cBRSKI
_brski-registrar._udp.local
                IN PTR  0000-5e00-5314._brski-registrar._udp.local
0000-5e00-5314._brski-registrar._udp.local
                IN SRV  1 2 5684 0000-5e00-5314.local
0000-5e00-5314._brski-registrar._udp.local
                IN TXT  "rrm-cose"

# Host name
0000-5e00-5314.local
               IN AAAA  2001:DB8:0815::5e00:5314
]]></artwork></figure>

<t>In example <xref target="dnssd-example-1"/>, a registrar on a router, that is using mDNS for being discovered
supports tBRSKI with "rrm" and "prm" modes across the same TCP socket port 4555, with "est" and "cmp".
This leads to the three supported and IANA registry defined variations "est-tls", "prm-jose", and "cmp".
For cBRSKI (UDP), it supports the only variation registered through this document, "rrm-cose".</t>

<t>Such a registrar implementation might even support a combination of "prm" with "jose" and "cmp",
but at the time of this specification, this exact interoperability aspects of such a combination
have at the time of writing of this spec not been investigated and hence it is not listed 
in the IANA registry. Nevertheless, this may happen later, so it is useful for registrar
implementations to allow configuration of variations for its service announcements to allow
operational modifications.</t>

<t>This registrar implementation is running on a router that otherwise has no for a 
host name registered in DNS or DNS-SD, so it is using it's MAC-address as its target host name,
"0000-5e00-5314.local", the same name is used in the registrar service instance names.
Running on a router without modular software, the registrar knows that no other registrar
instances can run on the same host and hence the name has no further disambiguating elements.</t>

<t>Note also that there is never a need for two different service instance names between
tBRSKI and cBRSKI, because they are distinguished bt the "_tcp" versus "_udp" component of the service
instance name.</t>

<figure title="DNS-SD for a tBRSKI/cBRSKI registrar applications" anchor="dnssd-example-2"><artwork><![CDATA[
# tBRSKI registrar application
_brski-registrar._tcp.example.org
     IN PTR  noc-registrar-brski-37253._brski-registrar._tcp.example.org
noc-registrar-brski-37253._brski-registrar._tcp.example.org
     IN SRV  1 2 4555 noc-registrar.example.org
noc-registrar-brski-37253._brski-registrar._tcp.example.org
     IN TXT "est-tls" "cmp"

# cBRSKI registrar application
_brski-registrar._udp.example.org
     IN PTR  noc-registrar-cbrski-5376._brski-registrar._udp.example.org
noc-registrar-cbrski-5376._brski-registrar._udp.example.org
     IN SRV  1 2 7533 noc-registrar.example.org
noc-registrar-cbrski-5376._brski-registrar._udp.example.org
     IN TXT "rrm-cose"

# tBRSKI, PRM variation application
_brski-registrar._tcp.example.org
               IN PTR noc-registrar-prm-9735._brski-registrar._tcp.example.org
noc-registrar-prm-9735._brski-registrar._tcp.example.org
               IN SRV 1 2 17355 noc-registrar.example.org
noc-registrar-prm-9735._brski-registrar._tcp.example.org
               IN TXT "prm" 

# Host name
noc-registrar.example.org
               IN AAAA  2001:DB8:0815::5e00:5333
]]></artwork></figure>

<t>In the second example <xref target="dnssd-example-2"/>, a server system in the NOC of customer with
domain example.org is set up as the registrar for various BRSKI options. It uses <xref target="DNSSD-SRP"/>
to register its DNS-SD names into the example.org domain which it discovers as the default domain.
The host name of the server is set to noc-registrar.example.org.</t>

<t>The operator installs three separate registrar applications on this server.
One from a vendor whose pledges use tBRSKI, one from an integrator supporting pledges
from various "IoT" vendors that use cBRSKI, and one from a manufacturer that has
pledges using BRSKI-PRM.</t>

<t>Each of the three applications operates the same way for discovery. It opens a socket for
its registrar responder and notes the port number it receives. It determines that
SRP is usable, that the default domain is "example.org", and that the host name
is noc-registrar. It then forms a unique name from noc-registrar by appending
some string  abbreviation indicating its mode of operation ("brski", "cbrski", "prm"),
and its numeric process identifier - just in case more than one instance of the
same application can be started. It then publishes its PTR, SRV and TXT DNS-RR,
using these creates unique service instance names, the respective port number in the
SRV RR and the variation(s) in the TXT RR.</t>

</section>
</section>
<section anchor="grasp"><name>GRASP</name>

<section anchor="signaling-1"><name>Signaling</name>

<t>This document does not specify a mandatory to implement set of signaling options to guarantee
interoperability of discovery between initiator and responders when using GRASP. Like for the
other discovery mechanisms, these requirements will have to come from other specifications
that outline what in <xref target="GRASP"/> is called the "security and transport substrate" to be used for
GRASP.</t>

<t><xref target="ACP"/> specifies one such "security and transport substrate", which is zero-touch deployable.
It is mandatory to support for initiators and responders implementing the so-called
"Autonomic Network Infrastructure" (ANI). DULL GRASP is used for link-local discovery of
proxies, and the ACP is used to automatically and securely build the connectivity for multi-hop discovery
of registrars by proxies.</t>

</section>
<section anchor="encoding-and-examples"><name>Encoding and Examples</name>

<t>To announce protocol variations with <xref target="GRASP"/>, the supported Variation is indicated in the
objective-value field of the GRASP objective, using the method of forming the Variation String
in <xref target="subreg-variations"/>, and listed in the Variation String column of the <xref target="fig-variations"/> table.</t>

<t>If more than one Variation is supported, then multiple objectives have to be announced, each with
a different objective-value, but the same location information if the different Variations can be
supported across the same socket because they will all be connected to the same registrar.
Different sockets require different objective structures in GRASP anyhow.</t>

<t>Compared to DNS-SD, the choice of encoding for GRASP optimizes for minimum parsing effort, whereas
the DNS-SD encoding is optimized for most compact encoding given the limit for DNS-SD TXT records.</t>

<figure title="GRASP example for a BRSKI registrar supporting RRM and PRM" anchor="grasp-example-1"><artwork><![CDATA[
[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
    [
     [["AN_Join_Registrar", 4, 255, ""],
      [O_IPv6_LOCATOR,
       h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]],

     [["AN_Join_Registrar", 4, 255, "prm"],
      [O_IPv6_LOCATOR,
       h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]],

     [["AN_Join_Registrar", 4, 255, "rrm"],
      [O_IPv6_LOCATOR,
       h'fe800000000000000000000000000001', IPPROTO_UDP, 4684]]

     [["AN_Join_Registrar_rjp", 4, 255, "rrm"],
      [O_IPv6_LOCATOR,
       h'fe800000000000000000000000000001', IPPROTO_UDP, 4686]]
    ]
]
]]></artwork></figure>

<t><xref target="grasp-example-1"/> is an example for a GRASP service announcement by a registrar in support of BRSKI
with both "rrm" and "prm" supported on the same TCP port 4443 and for cBRSKI (COAP over DTLS) on UDP
port 4684 in stateful mode and port 4686 for stateless mode . The first variation for "rrm" uses an objective-value of ""
for backward compatibility with <xref target="BRSKI"/> where it was introduced. With cBRSKI introducing definitions
for the use of GRASP only with this document, this special case is not proliferated, which is why "rrm" is
used in the cBRSKI announcements.</t>

<t>Note that one or more complete service instances (in the example 3) can be contained within a single GRASP message
without the need for any equivalent to the Service Instance Name of the DNS-SD PTR RR or the
Target name of the DNS-SD SRV RR. DNS-SD requires them because its encoding is
decomposed into different RR, but it also intentionally introduces the Service Instance Name
as an element for human interaction with selection (browsing and/or diagnostics of selection),
something that the current GRASP objective-value encoding does not support.</t>

<figure title="GRASP example for a BRSKI Join Proxy supporting RRM and PRM" anchor="grasp-example-2"><artwork><![CDATA[
[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
   [
    [["AN_Join_Registrar", 4, 1, ""],
     [O_IPv6_LOCATOR,
      h'fe800000000000000000000000000001', IPPROTO_TCP, 5553]],

    [["AN_Join_Registrar", 4, 1, "prm"],
     [O_IPv6_LOCATOR,
      h'fe800000000000000000000000000001', IPPROTO_TCP, 5555]],

    [["AN_Join_Registrar", 4, 1, "rrm"],
     [O_IPv6_LOCATOR,
      h'fe800000000000000000000000000001', IPPROTO_UDP, 5684]],

    [["AN_Join_Registrar_rjp", 4, 1, "rrm"],
     [O_IPv6_LOCATOR,
      h'fe800000000000000000000000000001', IPPROTO_UDP, 5686]],
   ]
]
]]></artwork></figure>

<t><xref target="grasp-example-2"/> shows a corresponding GRASP service announcement by a Join Proxy that
did discover the registrar from <xref target="grasp-example-1"/> and is now announcing the services that
it can now proxy. Whereas registrar announcements as in <xref target="grasp-example-2"/> typically
use TTL of 255 to be seen across the whole network, Join Proxy announcements are
only intended to reach link local neighboring pledges and hence use a TTL of 1.</t>

<t>The use of "" for "rrm" in BRSKI is again for backward compatibility with
<xref target="BRSKI"/>. The absence of two announcements for cBRSKI is because there is no stateless
mode from Join Proxy to pledge or Registrar-Agent. Instead, the Join Proxy will have
have to decide whether to connect to the registrar via stateful or stateless mode,
but this decision is invisible on its GRASP announcements.</t>

<t>Noteworthy too is the use of two different ports for "rrm" versus "prm". As the Registrar
did announce support for both variations on the same TCP port, the Join Proxy could have
done the same, but by using different ports, the Join Proxy can choose independently
which Registrar to connect "rrm" versus "prm" sessions to. For example, another Registrar
could announce itself for only "prm" and might be preferred by the Join Proxy.</t>

<figure title="GRASP example for a BRSKI Registrar supporting RRM and PRM via separate processes" anchor="grasp-example-3"><artwork><![CDATA[
[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
    [["AN_Join_Registrar", 4, 255, "",
     [O_IPv6_LOCATOR,
     h'fe800000000000000000000000000001', IPPROTO_TCP, 4443],
     ["AN_Join_Registrar", 4, 255, "",
     [O_IPv6_LOCATOR,
     h'fe800000000000000000000000000001', IPPROTO_UDP, 4684]]
]

[M_FLOOD, 42310815, h'fe800000000000000000000000000001', 180000,
    [["AN_Join_Registrar", 4, 255, "prm",
     [O_IPv6_LOCATOR,
     h'fe800000000000000000000000000001', IPPROTO_TCP, 44000]]
]
]]></artwork></figure>

<t>In <xref target="grasp-example-3"/>, a separate application process supports "prm" and hence
uses a separate socket with port number 44000 from "rrm", with port 4443.
Assuming there is no shared GRASP implementation across the two separate process,
such as a separate GRASP process, the announcements from both processes can
not be merged into a single GRASP packet. Instead, each one will send its own
GRASP announcements separately. This exampe primarily serves as a reminder, that
it is necessary for receivers to support receiving multiple announcements from the
same sender in GRASP not only within a single packet, but also when they arrive
via separate packes. To support implementation cases just as this one.</t>

<t>For a more extensive, DNS-SD compatible encoding of the objective-value that also
supports Service Instance Names, see <xref target="I-D.eckert-anima-grasp-dnssd"/>.</t>

</section>
</section>
<section anchor="core-lf"><name>CORE-LF</name>

<section anchor="overview-1"><name>Overview</name>

<t>"Web Linking", <xref target="RFC5988"/> defines a format, originally for use with
HTTP headers, to link an HTTP document against other URIs. Web linking is not a standalone
method for discovery of services for use with HTTP.</t>

<t>Based on Web Linking, "Constrained RESTful Environments (CoRE) Link Format", <xref target="CORE-LF"/> introduces a
standalone method to discover resources, such as service instances.
CORE-LF was introduced primarily for use with <xref target="COAP"/> but it can equally be used for discovery of
service instances that use HTTP or any other suitable (web transfer) protocols.
This makes CORE-LF an alternative to DNS-SD and GRASP for any of the BRSKI variations.</t>

<t>In CORE-LF, an initiator may use (link-local) IPv6 multicast UDP packet to the COAP port (5683)
to discover a possible responder for a requested resource. The responder will reply with unicast UDP.
If the IPv6 address of a responder has been configured or is otherwise known to the initiator, it
may instead of multicast equally query the parameters of the desired resource via unicast to the default COAP UDP or
TCP port (5683).</t>

<t><xref target="RFC9176"/> defines a "Resource Directory" mechanism for CORE-LF which is abbreviated CORE-RD. Initiators
can learn the IPv6 address protocol (TCP or UDP) and port number of a CORE-RD server by some other
mechanism (such as DNS-SD) and then use a unicast UDP or TCP COAP connection to the CORE-RD server
to discover CORE-LF resources available on other systems. Resource providers can likewise register
their resources with the resource directory server using CORE-RD registration procedures.</t>

<t>In summary, CORE-LF including CORE-RD is a mechanism for registration and discovery of resources and
hence services which may be preferred in deployments over other options and can equally be applicable
to register/discover any variation of BRSKI for any type of BRSKI service.</t>

</section>
<section anchor="background"><name>Background</name>

<t><xref target="cBRSKI"/> specifies the use of CORE-LF as the reference method
for pledges to discover registrars - in the absence of any proxies, to allow deployments
of scenarios where no proxies are needed - and hence also where <xref target="cBRSKI"/>
is not needed. Because BRSKI is designed so that pledges can be agnostic of whether they connect
to a registrar directly or via a Join Proxy, the resource/service that the pledge needs to discover
is nevertheless called "(BRSKI) Join Proxy (for pleges)", and encoded in CORE-LF as the value
"brski.jp" for the resource type attribute ("rt=resource-type") according to <xref target="CORE-LF"/>.</t>

<t>The following picture, <xref target="corelf-example-1"/> shows the encoding and an example of this discovery.
"ff02::fd" is the link-local scope address for "All Coap Nodes" in IPv6, as introduced in <xref target="RFC7390"/>,
which also defines IPv6 and site-scoped address options.</t>

<figure title="CORE-LF discovery of registrar/proxy by pledges" anchor="corelf-example-1"><artwork><![CDATA[
Template:

REQ: GET coap://[All_Coap_Nodes_IP_multicast_addr]/.well-known/core?rt=brski.jp

RES: 2.05 Content
   <coaps://[Responder_IP_unicast_address]:join-port>; rt="brski.jp"

Example:

REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski.jp

RES: 2.05 Content
   <coaps://[fe80::c78:e3c4:58a0:a4ad]:8485>;rt=brski.jp
]]></artwork></figure>

<t><xref target="cPROXY"/> introduces the operations of a CoAP based Join Proxy
both as a connection based Join Proxy as in <xref target="BRSKI"/> (only using UDP connections for COAPs instead
of TCP for TLS as in <xref target="BRSKI"/>), but also as a new, stateless Join Proxy - to eliminate the
need for potentially highly constrained Join Proxy nodes to keep connection state and avoid
the complexity of protecting that state against attacks. The new resource type "brski.rjp" is
defined to support stateless Join Proxies to discover registrars and their UDP port number
that support the stateless, so-called JPY protocol.</t>

<t>The following picture, <xref target="corelf-example-2"/> shows the encoding and an example of this discovery.
<xref target="cPROXY"/> introduces the new scheme "coaps+jpy" for the packet
header used by the stateless JPY" protocol. The request in the template is assumed to be
based on unicast, relying on another method to discover the IP address of the registrar first.
It could equally use COAP site-scoped IP multicast, but in general, the assumption is that
registrar will not necessarily be link-local connected to proxies (this may be different in
specific deployments). Even though the registrar IP address is hence known, the reply still
needs to include this address again because in the <xref target="CORE-LF"/> link format, and <xref target="RFC3986"/>, Section 3.2, the
authority attribute can not include a port number unless it also includes the IP address.</t>

<figure title="CORE-LF discovery of registrars that support stateless JPY protocll by proxies" anchor="corelf-example-2"><artwork><![CDATA[
Template:

REQ: GET /.well-known/core?rt=brski.jpy

RES: 2.05 Content
     <coaps+jpy://[Responder_IP_unicast_address]:join-port>;rt=brski.jpy

Example:

REQ: GET /.well-known/core?rt=brski.jpy

RES: 2.05 Content
     <coaps+jpy://[2001:db8:0:abcd::52]:7633>;rt=brski.jpy
]]></artwork></figure>

</section>
<section anchor="corelf-spec"><name>Specification</name>

<t>This section specifies the use of CORE-LF for BRSKI variations.
These specifications are backward compatible extensions to what is specified in <xref target="cBRSKI"/>
and <xref target="cPROXY"/>, except for noted exceptions, where the requirements
are narrowed. The following uses terms from the ABNF in section 2 of <xref target="CORE-LF"/> and from <xref target="RFC3986"/> (URI) for explanations
and relies on the following template example, <xref target="corelf-template"/>.</t>

<figure title="Template for BRSKI discovery with variations" anchor="corelf-template"><artwork><![CDATA[
Template:

REQ: GET /.well-known/core?rt=brski.*

RES: 2.05 Content
     <scheme://[address]:port path-abempty>;\
       rt=brski-service(;var="brski-variation-string(s)");\
       pw="priority weight"
]]></artwork></figure>

<t>BRSKI responder sockets are indicated in CORE-LF as a URI-Reference. The URI-Reference <bcp14>SHOULD</bcp14> be
a URI with a scheme, the IP address of the responder socket and the port used by the responder.
It may optionally be followed by a non-empty path-abempty.</t>

<t>URL-references <bcp14>SHOULD</bcp14> not use a domain name instead of an address to allow responders to
select a BRSKI responder without requiring DNS support. Likewise, port and scheme
<bcp14>MUST</bcp14> be included so that the information can be passed on to consumers without having to
modify it. When omitting this information, the full information can only be known in the
context of the connections scheme and port through which it was retrieved.</t>

<t>Note that these URL-Reference requirements are stronger than those from <xref target="cBRSKI"/>
and <xref target="cPROXY"/> to make extensibility easier.</t>

<t>BRSKI responder sockets <bcp14>MUST</bcp14> include a resource type field indicating a resource type
value indicating a BRSKI service, indicated as "brski-service" in <xref target="corelf-template"/>.
This <bcp14>MUST</bcp14> be registered in the IANA "Resource Type Link Target Attribute Values" registry table,
and also referenced in the "BRSKI Contexts" registry table <xref target="subreg-contexts"/>. 
A brski-service is a string without "." (single component string).</t>

<t>Discovery of registrar sockets  by stateful proxies uses the resource type "brski.rs".
This can be used in conjunction with any scheme: https:// for BRSKI and coaps:// for cBRSKI.
Stateless registrar sockets use the resource type "brski.rjpy". This currently only support
the coaps+jpy:// scheme. By its nature, it can only be used with schemes that rely on UDP.
These resource type uses are no change over <xref target="cBRSKI"/>
and <xref target="cPROXY"/>. This document does not specifiy how to discover
BRSKI-PLEDGE via CORE-LF.</t>

<t>The variations supported by a BRSKI responder socket are indicated via the optional "var="
link-extension. The value is a quoted-string of one or more space contatenated
BRSKI variation strings. The absence of a "var=" link-extension indicates support for only
the default variation for the BRSKI context to which the BRSKI service belongs. This
can also be indicated as "var=".</t>

<t>The optional "pw" target attribute indicates priority and weight for the selection of 
the resource target with the semantic and format defined in <xref target="RFC2782"/> for priority
and weight in DNS SRV resource records. If the attribute pw is absent, then
it is assumed to mean pw="65535 0".</t>

<t>A non-empty path-abempty indicates a path prefix for the endpoints supporting the BRSKI
service and variation that is shorter than the default endpoint paths specified for
the service.</t>

</section>
<section anchor="examples-1"><name>Examples</name>

<figure title="CORE-LF examples for BRSKI variations" anchor="corelf-example-4"><artwork><![CDATA[
REQ: GET /.well-known/core?rt=brski.*

RES: 2.05 Content
Content-Format: 40
Payload:
 <https://[2001:DB8:0815::5e00:5314]:4555>;        # [1]
        rt=brski.rs;var="est-tls prm-jose cmp";
        pw="1 2",
 <https://[2001:DB8:0815::5e00:5314]:4555>;        # [2]
        rt=brski.jp;var="est-tls prm-jose cmp";
        pw="1 2",
 <coaps://[2001:DB8:0815::5e00:5314]:5684/b>;      # [3]
        rt=brski.rs;var=,
        pw="1 2",
 <coaps://[2001:DB8:0815::5e00:5314]:5684/b>;      # [4]
        rt=brski.jp;var=,
        pw="1 2",
 <coaps+jpy://[2001:DB8:0815::5e00:5314]:6534/b>;  # [5]
        rt=brski.rjpy;var=,
        pw="1 2"
]]></artwork></figure>

<t><xref target="corelf-example-4"/> shows example BRSKI variations in CORE-LF format. Note that
the example is pretty-printed through indentation and breaking long lines. This
additional white space is not compatible with actual CORE-LF output. Likewise, the text following
"#" are editorial comments.</t>

<t>Example [1] is the equivalent announcement for a BRSKI registrar service as
shown for DNS-SD in <xref target="dnssd-example-1"/> except for the absence of any
service instance. Note the use of "var=" to indicate the list of variation
strings supported and "pw=" to indicate priority and weight as in DNS-SD.</t>

<t>[3] is likewise the comparable example for the cBRSKI registar example with
DNS-SD. Note that here, a non-empty path-abempty "/b" is used to indicate a
shortened endpoint prefix path for the service. There is no equivalent
in DNS-SD defined. When discovering a service via DNS-SD, the service
will need to use the (longer) pre-defined endpoint prefixes, such as
"/brski" and "/est" instead of "/b".</t>

<t>Example [2] is the same socket as [1], but announced as a Join Proxy
socket for pledges. Likewise, [4] is the same socket as [2] announced
as a Join Proxy socket for pledges. Finally, [5] announces the registrars
socket in support of stateless Join Proxies using the JPY header encapsulation.</t>

</section>
<section anchor="brski-resources"><name>Resource Type Considerations</name>

<t>CORE-LF expresses information about resources of a target identified by
a resource type. This specification encodes BRSKI services in CORE-LF also as
a resource types, as specified in <xref target="corelf-spec"/>. For the purpose of CORE-LF,
a BRSKI service is just another resource, except that it characterizes the
overall functionality available across a connection to the target, composed
of a sequence of endpoint instantiations. In addition, this behavior is
further refined by the list of supported variations indicated.</t>

<t>Often, resources in CORE-LF do - instead of a service - describe details of
as little as a single endpoint, such as its URL prefix and format encoding.
The reason why this fine-grained specification is not a good replacement
for the concept of service and variation is that the avilability of a set
of endpoints with specific encodings does not imply whether the target does
support the desired specific sequencing of instantiating those endpoints,
including the use of any endpoint encoding option in any combination.</t>

<t>Making such arbitrary combinations a requirement can easily
lead to more generic, but also more costly implementations and testing
requirements without necessarily gaining deployment benefit.</t>

<t>BRSKI resource types which are not treated as services according to 
this specification can still be used if so desired to amend the
discovery of shortened endpoints, as shown in <xref target="corelf-shortenings"/>.</t>

<figure title="CORE-LF resource examples" anchor="corelf-shortenings"><artwork><![CDATA[
RES: 2.05 Content
Content-Format: 40
Payload:
 <https://[2001:DB8:0815::5e00:5314]:4555/b>;      # [1]
        rt=brski.rs;var="est-tls prm-jose cmp";
        pw="1 2",
 <https://[2001:DB8:0815::5e00:5314]:4555/b/rv>;   # [2]
        rt=brski.rs.requestvoucher,                           
 <https://[2001:DB8:0815::5e00:5314]:4555/b/vs>;   # [3]
        rt=brski.rs.voucher_status,                           
 </b/rv>;rt=brski.rs.rv,                           # [4]
 </b/vs>;rt=brski.rs.vs,                           # [5]
]]></artwork></figure>

<t>[1] shows how the prefix for all BRSKI endpoints over "https://"
can be shortened from "/.well-known/brski" to "/b". Nevertheless,
this would still make it necessary to use "/b/requestvoucher"
and "/b/voucher_status" as endpoints.</t>

<t>[2] and [3] show how to shorten those two endpoints to
"/b/rv" and "/b/rs" by creating resource types "brski.rs.rv"
and "brski.rs.vs". By using resource type prefix "brski.rs."
for both of them as well as path prefix "/b", it can be implied
that these endpoints are part of the service specified in [1],</t>

<t>These discovery options can be further compacted such as
shown in example [4] and [5] when assuming that the
abbreviations "rv" and "vs" are also known even by BRSKI
implementations from <xref target="cBRSKI"/>. Likewise,
the full socket details can be avoided when one can infer it
from context.</t>

<t>While these shortenings can be highly useful in often called
resources, each endpoint in BRSKI is typically only  instantiated
once by a pledge, so the overall savings in communication data
becauseof these shortenings is likely negligible, and it is
better to define short endpoint paths into the variation
specification if they are likely needed, such as done in
<xref target="cBRSKI"/>, such that it is not
necessary in cBRSKI to add such shortenings in discovery.
For these reasons, this document does not specify if or how
to use such resource targets in cunjunction with BRSKI discovery
but only discusses possibilities and limitations here.</t>

<t>Considerations for such non-service resource type use in BRSKI
nevertheless introduces one requirement to avoid conflicts:
The names of BRSKI services
<bcp14>MUST</bcp14> not duplicate the endpoint names of any resources specified
for BRSKI protocols. This means that "rv" or "vs" can not be
used to create BRSKI service name resource types "brski.rv" or
"brski.rs", and likewise, additional BRSKI endpoints can not
be called "rs", "jp", "jpy" or any other string registered in the
BRSKI discover registry tables.</t>

</section>
</section>
</section>
</section>
<section anchor="updates"><name>Updates</name>

<section anchor="updates-to-rfc9733"><name>Updates to RFC9733</name>

<t>This document updates <xref target="BRSKI-AE"/>, section 5.1 with the following
text which is to be read as if appended to the end of that section.</t>

<t>Instead of using the minimalist "brski-reg-cmp" specified in <xref target="BRSKI-AE"/>,
this document RECOMMENDS for new implementations of BRSKI with CMP and
DNS-SD discovery to use the signaling elements specified in this document
with the following benefits.</t>

<t>For DNS-SD, the equivalent for "brski-reg-cmp" is "brski-registrar"
(see {#subreg-service-names}) with the TXT string "cmp"
(see <xref target="subreg-variations"/>). This automatically allows to use Join Proxies
supporting this specification. They will use "brski-proxy" with TXT
string "cmp" to indicate their support to transparently proxy also for a
CMP supporting registrar. Note that this will allow to use CMP in
cBRSKI as both "brski-registar" and "brski-proxy" are also registered
for use with UDP.</t>

<t>Likewise, "brski-registrar-rjp" with TXT string "cmp" and UDP
can be used to support CMP with stateless Join Proxies supporting
this specification and the registrations in {#subreg-service-names}
allow to discover Registrars / Proxies for BRSKI and cBRSKI with CMP 
also with GRASP and CORE-LD Discovery Mechanisms.</t>

<t>If backward compatibility is required, "brski-reg-cmp" can continue to
be announced by registrars unchanged.</t>

</section>
<section anchor="updates-to-brski-prm"><name>Updates to BRSKI-PRM</name>

<t>This documents updates <xref target="BRSKI-PRM"/> by adding
the following text to the end of section 6.1.1.</t>

<t>With the procedures specified in this document, Registrar Agents can discover
Registrars supporting PRM by discovering Registrars that announce a variation
which includes "prm". Because <xref target="BRSKI-PRM"/> specifies the
use of JOSE for voucher encoding, the correct Variation String to discover is
"prm-jose", as also registered in <xref target="subreg-variations"/>. Discovery can use
DNS-SD, CORE-LF or GRASP using the encodings specified in this document and
registered in <xref target="subreg-variations"/> for the Variation String and 
<xref target="subreg-service-names"/> for the Service Name.</t>

<t>Registrar Agements <bcp14>MAY</bcp14> use Join Proxies supporting the procedures of this
document to reach Registrars supporting PRM andusing the procedures of this
document. This may be of interest if the network available in the location
where the Registrar Agent is operating to access the Pledge is not fully
trusted but Join Proxies are used to only allow connections to Registrars.</t>

<t>This documents updates <xref target="BRSKI-PRM"/> section 6.1.2 with the
procedures specified in <xref target="brski-pledge"/>. Those procedures are meant to be
fully backward compatible with those specified in <xref target="BRSKI-PRM"/>,
but adds more details and suggestions for encoding of signaling elements.</t>

</section>
<section anchor="updates-to-rfc6690"><name>Updates to RFC6690</name>

<t>This document adds the text of <xref target="adtl"/> to <xref target="CORE-LF"/>. It recommenda to IANA to document that
addition as indicated in <xref target="rtreg"/>.</t>

<section anchor="adtl"><name>Additional Resource Type requirements for "brski"</name>

<t>The following text is to be read as if inserted into <xref target="CORE-LF"/> section 7.4 after the second paragraph.</t>

<t>For the Resource Type (rt=) Link Target Attribute table, values starting with the
characters "brski" are also subject to the following paragraph requirements.</t>

<t>Resource Type values with the "brski" prefix <bcp14>SHOULD</bcp14> support BRSKI discovery as specified in ([ThisRFC]).
The specification of such a Resource Type <bcp14>SHOULD NOT</bcp14> prohibit or conflict with the ability to
combine variation type values as established by [ThisRFC]. The specification <bcp14>SHOULD</bcp14> include
or point to a definition how the Resource Type is to be included into the "BRSKI Context Registry Table"
<xref target="contexts"/>. Review of these requirements is to be coordinated between Designated Experts for
the Core parameters (core-parameters@ietf.org) and those for the BRSKI Discovery Parameters Registry 
(<xref target="reg-discovery"/>).</t>

</section>
</section>
</section>
<section anchor="IANA"><name>IANA considerations</name>

<section anchor="core-parameters"><name>Core Parameters</name>

<section anchor="rtreg"><name>Resource Type Link Target Attribute Values</name>

<t>This document introduces additional requirements for the registration of Core Resource
Type values with prefix "brski" into the "Resource Type (rt=) Link Target Attribute Values" sub-registry
of the "Constrained RESTful Environments (CoRE) Parameters" registry, as specified in <xref target="adtl"/>.</t>

<t>IANA is suggested to document these additions by adjusting the registration procedure table 
for the "Resource Type (rt=) Link Target Attribute Values" sub-registry as shown in <xref target="fig-rtproc"/>.</t>

<texttable title="Suggested updated registration procedure table for Core (rt=) Rink Target Ranges" anchor="fig-rtproc">
      <ttcol align='left'>Range</ttcol>
      <ttcol align='left'>Registration Procedures</ttcol>
      <ttcol align='left'>Note</ttcol>
      <c>value starts with "core"</c>
      <c>IETF Review</c>
      <c>&#160;</c>
      <c>value starts with "brski"</c>
      <c>Specification Required</c>
      <c>Additional requirements in ThisRFC <xref target="adtl"/></c>
      <c>all other values</c>
      <c>Specification Required</c>
      <c>&#160;</c>
</texttable>

</section>
<section anchor="target-attributes"><name>Target Attributes</name>

<texttable title="Target Variation and Priority/Weight Attributes" anchor="fig-attrs">
      <ttcol align='left'>Attribute Name</ttcol>
      <ttcol align='left'>Brief Description</ttcol>
      <ttcol align='left'>Change Controller</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>var</c>
      <c>List of supported variations of target</c>
      <c>IETF</c>
      <c>[ThisRFC]</c>
      <c>pw</c>
      <c>DNS SRV compatible priority and weight of resource target</c>
      <c>IETF</c>
      <c>[ThisRFC]</c>
</texttable>

<t>IANA is asked to add entries for "var" and "pw" according to above <xref target="fig-attrs"/> to
the "Target Attributes" table.</t>

<t>The "var" target attribute is meant to be used for BRSKI targets as specified in
this document. It is also meant to be usable for other targets if so desired - to
indicate variations of the resource type of the target. For targets with a non-BRSKI
resource target (not using "rt=brski.*"), the format of the value may be different
than specified for BRSKI.</t>

<t>The "pw" target attribute indicates priority and weight for the selection of
the resource target with the semantic and format defined in <xref target="RFC2782"/> for priority
and weight in DNS SRV resource records. If the attribute pw is absent, then
it is assumed to mean pw="65535 0".</t>

</section>
</section>
<section anchor="service-name-registry"><name>Service Names Registry</name>

<t>IANA is asked to modify and amend the "Service Name and Transport Protocol Port Number Registry"
registry (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt) as follows.</t>

<t><list style="symbols">
  <t>brski-proxy, brski-registrar and brski-registrar-rjp are to be added as Service Names for the "udp" protocol
using ThisRFC, <xref target="subreg-service-names"/> as the reference.</t>
  <t>The registrations for brski-proxy and brski-registrar for the "tcp" protocol are to be updated to also
include ThisRFC, <xref target="subreg-service-names"/> as their reference.</t>
  <t>The Defined TXT keys column for brski-proxy, brski-registrar and brski-registrar-rjp for "tcp" and "udp"
protocols are to state the following text:  <vspace blankLines='1'/>
Defined TXT keys: &lt;variation-string(s)&gt;, See ThisRFC <xref target="variation-string-encoding"/>, <xref target="subreg-variations"/></t>
</list></t>

</section>
<section anchor="grasp-registry"><name>GRASP Objective Names Registry</name>

<t>IANA is asked to add the following entry to the
 "GeneRic Autonomic Signaling Protocol (GRASP) Parameters Registry" page,
"GRASP Objective Names Registry".</t>

<texttable title="GRASP Objective Names Registry addition" anchor="fig-grasp-registry">
      <ttcol align='left'>Objective Name</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>AN_join_registrar_rjp</c>
      <c>ThisRFC, <xref target="subreg-service-names"/></c>
</texttable>

</section>
<section anchor="reg-discovery"><name>BRSKI Discovery Parameters</name>

<t>IANA is asked to add a registry called "BRSKI Discovery Parameters"
to the "Bootstrapping Remote Secure Key Infrastructures (BRSKI) Parameters"
registry webpage (https://www.iana.org/assignments/brski-parameters/brski-parameters.xhtml).</t>

<t>The BRSKI Discovery Parameters registry includes several sub-registries that
depend on each other.  Due to the requirement of an IANA registry with sub-registries,
one table has to be choosen to represent the overall registry. The table
used to represent the BRSKI Discover Parameters is the list of discovery
mechanisms supported.</t>

<t>The Registration Procedure for this registry is Specification Required, where Expert Review has to ensure compliance
of entries with the following rules.</t>

<t>Additions to this registry require a specification of the use of the newly registered discovery mechanism
with BRSKI discovery procedures in the way they are specified in this document for DNS-SD, GRASP and CORE-LF.</t>

<t>Changes/extensions to the procedures for any existing registered discovery mechanism, including
DNS-SD, GRASP or CORE-LF can be done by adding such specification to the Reference(s) colum.</t>

<t>Any incremental changes to a discovery mechanism procedures require the same or higher level 
of specification as the first one introducing the discovery mechanism. Changes to the procedures
for DNS-SD, GRASP, CORE-LF do hence require an IETF standards track specification for updates.</t>

<t>The initial content is as follows.</t>

<dl>
  <dt>Designated Experts:</dt>
  <dd>
    <t>TBD.</t>
  </dd>
  <dt>Registration Procedure:</dt>
  <dd>
    <t>Specification Required.</t>
  </dd>
  <dt>Notes:</dt>
  <dd>
    <t>See [ThisRFC], <xref target="reg-discovery"/></t>
  </dd>
</dl>

<texttable title="Discovery Mechanisms initial registry table" anchor="fig-discovery-mechanisms">
      <ttcol align='left'>Discovery Mechanism</ttcol>
      <ttcol align='left'>Reference(s)</ttcol>
      <ttcol align='left'>Notes</ttcol>
      <c>DNS-SD</c>
      <c>ThisRFC</c>
      <c>&#160;</c>
      <c>GRASP</c>
      <c>ThisRFC</c>
      <c>&#160;</c>
      <c>CORE-LF</c>
      <c>ThisRFC</c>
      <c>&#160;</c>
</texttable>

<section anchor="subreg-contexts"><name>Contexts</name>

<t>IANA is asked to create a sub-registry called "Contexts" in the "BRSI Discovery Parameters" registry.</t>

<t>The Registration Procedure for this registry is Specification Required, where Expert Review has to ensure feasibility
of entries with the following behavior/rules.</t>

<t>A Context is a name for a group of one or more BRSKI services. This sub-registry register
a Contexts name and the list of Variation Types defined for the Context.</t>

<t>Variation Types are case independent consisting only of the letters a-z and the digits 0-9,
 must start with a letter and be at most 12 characters long.</t>

<t>Registration of new Contexts <bcp14>MUST</bcp14> include a specification of how to use discovery with the new Context
using the specifications for BRSKI, cBRSKI and BRSKI-PLEDGE in this document as examples.</t>

<t>Technically, Contexts with the same set of Variation Types exist for example to allow registering and
hence discovering different protocol stacks for otherwise logically the same type of services, or
else a BRSKI pledge might be discovering a cBRSKI registrar. See <xref target="subreg-service-names"/> for more details.</t>

<t>The order of Variation Types defines the order in which Variation Type Values are concatenated
to generate Variation Strings as described in <xref target="subreg-variations"/>. Therefore Variation Types
ones registered <bcp14>SHOULD NOT</bcp14> be changed or deleted so that new Variation Strings will be constructed
consistently with old ones. Only new Variation Types may be appended through regisrtration updates.</t>

<t>Registration of additional Variation Types <bcp14>MUST</bcp14> include a specification of how they map
to specific function of the services that use them as this specification does for BRSKI, cBRSKI and
BRSKI-PLEDGE.</t>

<t>Registrations of a new Context <bcp14>MAY</bcp14> initially not define any Variation Types if Variations
are not yet considered for a Context.</t>

<t>The initial content of this sub-registry is as follows.</t>

<dl>
  <dt>Designated Experts:</dt>
  <dd>
    <t>TBD.</t>
  </dd>
  <dt>Registration Procedure:</dt>
  <dd>
    <t>Specification Required.</t>
  </dd>
  <dt>Notes:</dt>
  <dd>
    <t>See [ThisRFC], <xref target="subreg-contexts"/></t>
  </dd>
</dl>

<texttable title="Contexts initial sub-registry table" anchor="fig-subreg-contexts">
      <ttcol align='left'>Context</ttcol>
      <ttcol align='left'>Variation Types</ttcol>
      <ttcol align='left'>Reference(s)</ttcol>
      <ttcol align='left'>Notes</ttcol>
      <c>BRSKI</c>
      <c>mode, vformat, enroll</c>
      <c>ThisRFC</c>
      <c>&#160;</c>
      <c>cBRSKI</c>
      <c>mode, vformat, enroll</c>
      <c>ThisRFC</c>
      <c>&#160;</c>
      <c>BRSKI-PLEDGE</c>
      <c>mode, vformat, enroll</c>
      <c>ThisRFC</c>
      <c>&#160;</c>
</texttable>

</section>
<section anchor="subreg-service-names"><name>Service Names</name>

<t>IANA is asked to create a sub-registry called "Service Names" in the "BRSI Discovery Parameters" registry.</t>

<t>The Registration Procedure for this registry is Specification Required, where Expert Review has to ensure feasibility
of entries with the following behavior/rules.</t>

<t>Each entry registers a Service Name intended for discovery of a BRSKI related service 
using a specific Discovery Mechanism. The service is to be accessed via specific service (transport) stack Parameter(s)
that are required to be known by the discovery mechanism.</t>

<t>Because they may be used in the future in protocol encodings, Variation Type Choices
<bcp14>SHOULD</bcp14> be as simple as possible. They <bcp14>SHOULD</bcp14>  consist only of the letters a-z and the digits 0-9,
<bcp14>SHOULD</bcp14> start with a letter and be at most 12 characters long.</t>

<t>Depending on the discovery mechanism, the Service Name represents a different signaling element
of the discovery mechanism as follows.</t>

<t>o For DNS-SD, the tables Service Name is the DNS-SD Service Name which <bcp14>MUST</bcp14> also be registered in
  the IANA "Service Name and Transport Protocol Port Number Registry" for use with the DNS-SD
  protocol indicated in the Parameter(s) column.</t>

<t>o For GRASP, the Service Name is the GRASP Objective Name which <bcp14>MUST</bcp14> also be registered
  in the IANA "GeneRic Autonomic Signaling Protocol (GRASP) Parameters" /
  "GRASP Objective Names" registry.</t>

<t>o For CORE-LF, the Service Name is the CoRE Resource Type (rt=) value, which
  <bcp14>MUST</bcp14> be registered in the IANA "Constrained RESTful Environments (CoRE) Parameters" /
  "Resource Type (rt=) Link Target Attribute Values" registry.</t>

<t>Context is a grouping of one or more services with the same set of Variation Types and Values 
as defined below (<xref target="subreg-contexts"/>). Re-use of the same Service Name across multiple
Contexts requires distinction of the services through Parameter(s) that are used as
additional distinguishers (beside the Service Name) in the discovery mechanism.</t>

<t>For example, AN_Proxy is used as the GRASP Objective (aka: "Service Name") to discover <xref target="BRSKI"/>
BRSKI Join Proxies and connect to them via TCP. This is indicated through the IPPROTO_TCP parameter in GRASP.
Likewise, when a constrained BRSKI proxy as described in <xref target="cPROXY"/> is to be
discovered via GRASP, IPPROTO_UDP is to be used in GRASP to distinguish such a cBRSKI Proxy from a
BRSKI Proxy.</t>

<t>Informal names for services are best documented in the Notes column.</t>

<t>The initial registrary table adds to the registrations from other BRSKI RFCs new registrations
to discover BRSKI Registrar and Join Proxy via CORE-LF. These do not require new registrations in
the CORE registry because those registrations do not distinguish on the transport stack, and hence the
prior CORE registrations for cBRSKI are equally applicable to BRSKI.  In addition, the registrations
to discover cBRSKI stateful and stateless Registrars and Join Proxies via GRASP and DNS-SD are included.
The necessary additional registrations for these are included in <xref target="service-name-registry"/> for DNS-SD
and <xref target="grasp-registry"/> for GRASP.  With these registrations, both BRSKI and cBRSKI services can use DNS-SD, GRASP or CORE-LF for discovery.</t>

<t>The initial content of this sub-registry is as follows.</t>

<dl>
  <dt>Designated Experts:</dt>
  <dd>
    <t>TBD.</t>
  </dd>
  <dt>Registration Procedure:</dt>
  <dd>
    <t>Specification Required.</t>
  </dd>
  <dt>Notes:</dt>
  <dd>
    <t>See [ThisRFC], <xref target="subreg-service-names"/></t>
  </dd>
</dl>

<texttable title="Service Name(s) initial sub-registry table" anchor="fig-subreg-service-names">
      <ttcol align='left'>Service Name(s)</ttcol>
      <ttcol align='left'>Context</ttcol>
      <ttcol align='left'>Discovery Mechanism</ttcol>
      <ttcol align='left'>Parameter(s)</ttcol>
      <ttcol align='left'>Reference(s)</ttcol>
      <ttcol align='left'>Notes</ttcol>
      <c>brski.jp</c>
      <c>BRSKI</c>
      <c>CORE-LF</c>
      <c>https</c>
      <c>THIS-RFC</c>
      <c>Proxy</c>
      <c>brski.rs</c>
      <c>BRSKI</c>
      <c>CORE-LF</c>
      <c>https</c>
      <c>THIS-RFC</c>
      <c>Registrar (stateful)</c>
      <c>brski-proxy</c>
      <c>BRSKI</c>
      <c>DNS-SD</c>
      <c>tcp</c>
      <c>RFC8995</c>
      <c>Proxy</c>
      <c>brski-registrar</c>
      <c>BRSKI</c>
      <c>DNS-SD</c>
      <c>tcp</c>
      <c>RFC8995</c>
      <c>Registrar (stateful)</c>
      <c>AN_Proxy</c>
      <c>BRSKI</c>
      <c>GRASP</c>
      <c>IPPROTO_TCP</c>
      <c>RFC8995</c>
      <c>Proxy</c>
      <c>AN_join_registrar</c>
      <c>BRSKI</c>
      <c>GRASP</c>
      <c>IPPROTO_TCP</c>
      <c>RFC8995</c>
      <c>Registrar (stateful)</c>
      <c>brski.jp</c>
      <c>cBRSKI</c>
      <c>CORE-LF</c>
      <c>coaps</c>
      <c>I-D.ietf-anima-constrained-voucher</c>
      <c>Proxy</c>
      <c>brski.rs</c>
      <c>cBRSKI</c>
      <c>CORE-LF</c>
      <c>coaps</c>
      <c>I-D.ietf-anima-constrained-join-proxy</c>
      <c>Registrar (stateful)</c>
      <c>brski.rjp</c>
      <c>cBRSKI</c>
      <c>CORE-LF</c>
      <c>coaps</c>
      <c>I-D.ietf-anima-constrained-join-proxy</c>
      <c>Registrar (stateless)</c>
      <c>AN_Proxy</c>
      <c>cBRSKI</c>
      <c>GRASP</c>
      <c>IPPROTO_UDP</c>
      <c>THIS-RFC</c>
      <c>Proxy</c>
      <c>AN_join_registrar</c>
      <c>cBRSKI</c>
      <c>GRASP</c>
      <c>IPPROTO_UDP</c>
      <c>THIS-RFC</c>
      <c>Registrar (stateful)</c>
      <c>AN_join_registrar_rjp</c>
      <c>cBRSKI</c>
      <c>GRASP</c>
      <c>IPPROTO_UDP</c>
      <c>THIS-RFC</c>
      <c>Registrar (stateless)</c>
      <c>brski-proxy</c>
      <c>cBRSKI</c>
      <c>DNS-SD</c>
      <c>udp</c>
      <c>THIS-RFC</c>
      <c>Proxy</c>
      <c>brski-registrar</c>
      <c>cBRSKI</c>
      <c>DNS-SD</c>
      <c>udp</c>
      <c>THIS-RFC</c>
      <c>Registrar (stateful)</c>
      <c>brski-registrar-rjp</c>
      <c>cBRSKI</c>
      <c>DNS-SD</c>
      <c>udp</c>
      <c>THIS-RFC</c>
      <c>Proxy (stateless)</c>
      <c>brski-pledge</c>
      <c>BRSKI-PLEDGE</c>
      <c>DNS-SD</c>
      <c>tcp</c>
      <c>I-D.anima-brski-prm, THIS-RFC</c>
      <c>&#160;</c>
</texttable>

</section>
<section anchor="subreg-choices"><name>Variation Type Choices</name>

<t>IANA is asked to create a sub-registry called "Variation Type Choices" in the "BRSI Discovery Parameters" registry.</t>

<t>The Registration Procedure for this registry is Specification Required, where Expert Review has to ensure feasibility
of entries with the following expectations/rules.</t>

<t>Each row registers one Variation Type Choice for one Context (as registered in <xref target="subreg-contexts"/>) and 
specifies the Variation Type (also as registered in <xref target="subreg-contexts"/>) for which it is a choice.</t>

<t>All Variation Type Choices <bcp14>MUST</bcp14> be unique across all Variation Types so that the Variation Type can
always be deduced from the Variation Type Choice, permitting future encodings that do not necessarily
have to use the Variation String representation (as registered in <xref target="subreg-variations"/>), and also allowing
to recognize erroneous variation repesentations easier.</t>

<t>Because they are used in protocol encodings, Variation Type Choices
<bcp14>MUST</bcp14> be as simple as possible. They <bcp14>MUST</bcp14> consisting only of the characters a-z and 0-9.</t>

<t>The "Dflt" flag indicates that the Variation Type Choice is the default choice for its Variation Type.
Default choices are not included in the Variation String encoding of Variations. When new Variation
Types are added to a Context to introduce variations of a new aspect of BRSKI, then the choice that
is backward compatible has to become the Default choice for that new Variation Type.</t>

<t>The "Rsvd" flag indicates a choice that has not sufficiently been vetted/specified to allow its use in
Variations (<xref target="subreg-variations"/>, but that is known to be a possible candidate and is reserved to track
that possible extension through future specification work.</t>

<t>References in parenthesis specify the necessary functionality for a Variation Type Choice but do not
specify the actual registration of the Veriation Type Choice.</t>

<t>The initial content is as follows.</t>

<dl>
  <dt>Designated Experts:</dt>
  <dd>
    <t>TBD.</t>
  </dd>
  <dt>Registration Procedure:</dt>
  <dd>
    <t>Specification required.</t>
  </dd>
</dl>

<texttable title="Variation Type Choices initial sub-registry table" anchor="fig-choices">
      <ttcol align='left'>Flags</ttcol>
      <ttcol align='left'>Variation Type Choice</ttcol>
      <ttcol align='left'>Variation Type</ttcol>
      <ttcol align='left'>Context</ttcol>
      <ttcol align='left'>Reference(s)</ttcol>
      <ttcol align='left'>Note(s)</ttcol>
      <c>Dflt</c>
      <c>rrm</c>
      <c>mode</c>
      <c>BRSKI</c>
      <c>(RFC8995),ThisRFC</c>
      <c>Registrar Responder Mode</c>
      <c>&#160;</c>
      <c>prm</c>
      <c>mode</c>
      <c>BRSKI</c>
      <c>(I-D.ietf-anima-brski-prm),ThisRFC</c>
      <c>Pledge Responder Mode</c>
      <c>Dflt</c>
      <c>cmsj</c>
      <c>vformat</c>
      <c>BRSKI</c>
      <c>(RFC8368,RFC8995),ThisRFC</c>
      <c>CMS-signed JSON Voucher</c>
      <c>&#160;</c>
      <c>jose</c>
      <c>vformat</c>
      <c>BRSKI</c>
      <c>(I-D.ietf-anima-jws-voucher),ThisRFC</c>
      <c>JOSE-signed JSON</c>
      <c>&#160;</c>
      <c>cose</c>
      <c>vformat</c>
      <c>BRSKI</c>
      <c>ThisRFC</c>
      <c>CBOR with COSE signature</c>
      <c>Dflt</c>
      <c>est</c>
      <c>enroll</c>
      <c>BRSKI</c>
      <c>(RFC7030,RFC8995),ThisRFC</c>
      <c>Enrollment over Secure Transport</c>
      <c>&#160;</c>
      <c>cmp</c>
      <c>enroll</c>
      <c>BRSKI</c>
      <c>(RFC9733,RFC9483),ThisRFC</c>
      <c>Lightweight CMP Profile / BRSKI-AE</c>
      <c>Rsvd</c>
      <c>scep</c>
      <c>enroll</c>
      <c>BRSKI</c>
      <c>ThisRFC</c>
      <c>common legacy option</c>
      <c>Dflt</c>
      <c>rrm</c>
      <c>mode</c>
      <c>cBRSKI</c>
      <c>(I-D.anima-constrained-voucher),ThisRFC</c>
      <c>Registrar Responder Mode</c>
      <c>Dflt</c>
      <c>cose</c>
      <c>vformat</c>
      <c>cBRSKI</c>
      <c>(I-D.ietf-anima-constrained-voucher),ThisRFC</c>
      <c>CBOR with COSE signature</c>
      <c>&#160;</c>
      <c>cmsj</c>
      <c>vformat</c>
      <c>cBRSKI</c>
      <c>ThisRFC</c>
      <c>CMS-signed JSON Voucher</c>
      <c>&#160;</c>
      <c>jose</c>
      <c>vformat</c>
      <c>cBRSKI</c>
      <c>ThisRFC</c>
      <c>JOSE-signed JSON</c>
      <c>Dflt</c>
      <c>est</c>
      <c>enroll</c>
      <c>cBRSKI</c>
      <c>(RFC9148), ThisRFC</c>
      <c>Enroll via EST over COAP</c>
      <c>&#160;</c>
      <c>cmp</c>
      <c>enroll</c>
      <c>cBRSKI</c>
      <c>(RFC9733,RFC9483),ThisRFC</c>
      <c>Lightweight CMP Profile / BRSKI-AE</c>
      <c>Dflt</c>
      <c>prm</c>
      <c>mode</c>
      <c>BRSKI-PLEDGE</c>
      <c>(I-D.ietf-anima-brski-prm),ThisRFC</c>
      <c>Pledge responder Mode</c>
      <c>Dflt</c>
      <c>jose</c>
      <c>vformat</c>
      <c>BRSKI-PLEDGE</c>
      <c>(I-D.ietf-anima-brski-prm),ThisRFC</c>
      <c>JOSE-signed JSON</c>
      <c>Rsvd</c>
      <c>cmsj</c>
      <c>vformat</c>
      <c>BRSKI-PLEDGE</c>
      <c>(I-D.ietf-anima-brski-prm),ThisRFC</c>
      <c>CMS-signed JSON Voucher</c>
      <c>Rsvd</c>
      <c>cose</c>
      <c>vformat</c>
      <c>BRSKI-PLEDGE</c>
      <c>(I-D.ietf-anima-brski-prm),ThisRFC</c>
      <c>CBOR with COSE signature</c>
      <c>Dflt</c>
      <c>est</c>
      <c>enroll</c>
      <c>BRSKI-PLEDGE</c>
      <c>(I-D.ietf-anima-brski-prm),ThisRFC</c>
      <c>Enroll via EST modified for PRM</c>
      <c>&#160;</c>
      <c>cmp</c>
      <c>enroll</c>
      <c>BRSKI-PLEDGE</c>
      <c>(RFC9733,RFC9483,I-D.ietf-anima-brski-prm),ThisRFC</c>
      <c>Lightweight CMP Profile with PRM</c>
</texttable>

</section>
<section anchor="subreg-variations"><name>Variations</name>

<t>IANA is asked to create a sub-registry called "Variations" in the "BRSI Discovery Parameters" registry.</t>

<t>The Registration Procedure for this registry is Specification Required, where Expert Review has to ensure feasibility
of entries with the following behavior/rules.</t>

<t>Each row registers one or more Variation String(s) that are representing one Variation
in one Context for and specifies the combination of Variation Type Values indicated by that Variation.</t>

<t>Variation Type Values <bcp14>MUST</bcp14> be listed in the order in which they appear in <xref target="subreg-contexts"/>,
including the default Variation Type Values for the Variation Types known at the time of registration.
Once a Variation String for a Context is registered, its listed Variation Type Values <bcp14>SHOULD
NOT</bcp14> be modified (except for erroneous registration).</t>

<t>The primary Variation String <bcp14>SHOULD</bcp14> be derived by concatening the Variation Type 
Values listed, concatenated by "-", except for default values. This is called the standard Variation String construction rule.
The empty string is represented as "".</t>

<t>Any Variation String not meeting that construction scheme <bcp14>SHOULD</bcp14> receive a note explaining why.</t>

<t>When later potentially new Variation Types are introduced into the XXX table, 
then they will not lead to a change in the Variation String(s), instead it is understood
that the Variation will represent the default Variation Type Values for any such additional
Variation Types.</t>

<t>This registry table exists to document which specification(s) utilize specific
Variations so that implementations do not have to consider supporting arbitrary
possible (but not validated by specification) Variations.</t>

<t>The subregistries specified below register the permissible Context and Variation Type Values.</t>

<t>The initial content is as follows.</t>

<dl>
  <dt>Designated Experts:</dt>
  <dd>
    <t>TBD.</t>
  </dd>
  <dt>Registration Procedure:</dt>
  <dd>
    <t>Specification required.</t>
  </dd>
  <dt>Notes:</dt>
  <dd>
    <t>(1) The Variation String "EST-TLS" is equivalent to the Variation String "" and
is required and only permitted for the AN_join_registrar objective value in GRASP
for backward compatibility with <xref target="BRSKI"/>, where it is used for this variation. Note that AN_proxy uses "".</t>
  </dd>
</dl>

<texttable title="Variations initial sub-registry table" anchor="fig-variations">
      <ttcol align='left'>Variation String</ttcol>
      <ttcol align='left'>Context</ttcol>
      <ttcol align='left'>Variation</ttcol>
      <ttcol align='left'>Specification(s)</ttcol>
      <ttcol align='left'>Notes</ttcol>
      <c>"" / "EST-TLS"</c>
      <c>BRSKI</c>
      <c>rrm cmsj est</c>
      <c>RFC8995</c>
      <c>See Note (1)</c>
      <c>cmp</c>
      <c>BRSKI</c>
      <c>rrm cmsj cmp</c>
      <c>RFC9733</c>
      <c>&#160;</c>
      <c>prm-jose</c>
      <c>BRSKI</c>
      <c>prm jose est</c>
      <c>(I-D.ietf-anima-jws-voucher,I-D.ietf-anima-brski-prm),ThisRFC</c>
      <c>I-D.ietf-anima-brski-prm also includes required extensions to EST</c>
      <c>""</c>
      <c>cBRSKI</c>
      <c>rrm cose est</c>
      <c>I-D.ietf-anima-constrained-voucher</c>
      <c>&#160;</c>
      <c>prm-jose</c>
      <c>BRSKI-PLEDGE</c>
      <c>prm jose est</c>
      <c>I-D.ietf-anima-brski-prm</c>
      <c>&#160;</c>
</texttable>

</section>
</section>
<section anchor="brski-well-known-uris-fixes-opportunistic"><name>BRSKI Well-Known URIs fixes (opportunistic)</name>

<t>The following change requests to "https://www.iana.org/assignments/brski-parameters/brski-parameters.xhtml#brski-well-known-uris" are cosmetic in nature and are included in this document solely because support for Endpoint URIs is implied by the mechanisms specified in this document and the existing registry has these cosmetic issues.</t>

<t><list style="numbers">
  <t>IANA is asked to change the name of the first column of the table from "URI" to "URI Suffix". This is in alignment with other table columns with the same syntax/semantic, such as "https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml".</t>
  <t>IANA is asked to change the Reference from "RFC8995"  to "RFC8995, Section 8.3.1".</t>
  <t>IANA is asked to include the following "Note" text: The following table contains the assigned BRSKI protocol Endpoint URI suffixes under "/.well-known/brski"." - This note is added to introduce the term "Endpoint" into the registry table as that is the term commonly used (instead of URI) in several of the memos for which this discovery document was written. It is meant to help readers map the registry to the terminology used in those documents.</t>
</list></t>

</section>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>

<t>In <xref target="BRSKI-PRM"/>, pledges are easier subject to DoS attacks than in <xref target="BRSKI"/>, because attackers
can be initiators and delay or prohibit enrollment of a pledge by opening so many connections to
the pledge that a valid Registrar-Agents connection to the pledge may not be possible. Discovery
of the pledge via DNS-SD increases the ability of attackers to discover pledges against which such
DoS attacks can be attempted.</t>

<t>Especially when supporting DNS-SD browsing across unicast DNS,
pledges <bcp14>MUST</bcp14> implement DoS prevention measures, such as limiting the number and rate of accepted TCP
connections on a per-initiator basis. If feasible for the implementation, simultaneous connections
<bcp14>SHOULD</bcp14> be possible, so that an ongoing attacker connection will not delay a valid Registrar-Agent
connection. When accepting connections, a strategy such as LRU <bcp14>MAY</bcp14> be used to ensure that an attacker
will not be able to monopolize connections.</t>

<t>Browsing via DNS-SD, especially via unicast DNS which makes information available network-wide does
also introduce a perpass attack, gathering intelligence against what type and serial number of
devices are installed in the network. Whether or not this is seen as a relevant risk is highly
installation dependent. Networks <bcp14>SHOULD</bcp14> implement filtering measures at mDNS and/or DNS RR/services
level to prohibit such data collection if there is a risk, and this is seen as an undesirable attack
vector.</t>

<t>Service instance names as defined in <xref target="brski-pledge"/> are used to discover pledges
by their manufacturer assiged serial numbers. Today, DNS-SD does not provide security
against impersonation of such service instance names. Instead, impersonation can and
will only be discovered after performing BRSKI connections to the pledge. It should
be noted, that the scheme used by <xref target="brski-pledge"/> could actually be used to protect
against impersonation when <xref target="DNSSD-SRP"/> with some security extension is used:
Pledges need to signal their IDevID for their SRP TLS connection, and the SRV server
needs to have the same manufacturer Service Instance Name schema and manufacturer
trust anchor information as BRSKI registrars and can then allow only the permissible
service instance name DNS-SD RRs for this pledge. In fact, the SRP server could
create the all necessary <xref target="brski-pledge"/> required DNS-SD RRs from the IDevID
information even if the pledge itself is not requesting them or is requesting other
DNS-SD RRs. Definition of these procedures is outside the scope of this specification
though.</t>

<t>None of the discovery mechanisms (DNS-SD, GRASP or CORE-LF) are necessarily secure. Instead,
it is a matter of their deployment, how trustworthy service announcements are. In an
unprotected deployment with DNS-SD via mDNS for example, an attacker could attract
connections from responders by announcing itself with the best priority value. When a
deployment instead uses a secure domain deployment model, such as an <xref target="ACP"/>,
a secured wireless mesh technology, or discovery via a secured DNS server, then
service announcements are typically assumed to be trustworthy and with them their
service parameters. In those deployments, the security question is then primarily the
attack vectors to impair such a responder to make it behave in undesirable means.</t>

</section>
<section anchor="acknowledgments"><name>Acknowledgments</name>

<t>Many thanks for reviews by Arthur Hecker, Steffen Fries and discussions/feedbacks by Brian Carpenter, Michael Richardson, Michael Kovatsch. 
Special thanks to Amanda Barber for her IANA section review.</t>

<section anchor="change-log"><name>Change log</name>

<t>[RFC Editor: please remove this section.]</t>

<t>WG draft 09:</t>

<t>Small editorial fix. Table incorrectly split by empty lines.</t>

<t>WG draft 08:</t>

<t>Overhauled IANA section after IANA early review. Changed tables so every table has only
 one key registered item which is usually in the first colum. Eliminated formatting
based registration, eg.: no more "multi-line" registration - does notwork because the
registries are databased. Removed optical beautification of keeping cells empty to
indicate repetition of previous row content. This too does not work for IANA registry
because they allow re-ordering of rows by column.</t>

<t>Also rewrote/shortened the Registry Data Model section to fit the new IANA section.
Put Discussios section before IANA discussion so it is clear it is part of the
overall data model, not the IANA representation.</t>

<t>Added updates to BRSKI-AE and BRSKI-PRM text that details how BRSKI Discovery is
to be used for both RFCs mechanisms. Also made this doc an update to BRSKI-AE to
ensure it is tracked that way.</t>

<t>Moved all other IANA consideration before the ask for the new BRSKi Discover Parameters,
as this looks more logical - except for the opportunistic ask.</t>

<t>In result of creating more tables and hence removing colums, the tables "should"
actually fit into the 72 character TXT rendering as soon as the I-D... draft
references in them are replaced by RFC references, which should happen in RFC
editor queue before this document gets published (hope, hope...).</t>

<t>Removed appendix "possible future variations"</t>

<t>Made document update to rfc6690 to allow formalizing request to update CORE RT= parameter range table with BRSKI entries, see section 4.1.1.</t>

<t>WG draft 07:</t>

<t>Defined document to be update to draft-ietf-anima-brski-prm (for the specifiation of IDevID derived DNS-SD discovery of pledges)</t>

<t>Resolved open Q text wether SRP allows discovery of SRP server. According to Stuart Cheshire this is supported.</t>

<t>Incorporated initial Feedback from Michael Kovatsch</t>

<t>Added section explaining that there is no spec for how to do pledge discovery via CORE-LF or GRASP.</t>

<t><list style="symbols">
  <t>Rewrote 2.1 Challenges to now be a more comprehensive set of 3 example deployment issues without this work.</t>
</list></t>

<t>Incorporated review by Artur Hecker</t>

<t><list style="symbols">
  <t>Rewrote abstract to more comprehensively (and easier understandable) describe the scope of this document</t>
  <t>Simplified terminology: removed "variation context", not only calling it "context".</t>
  <t>changed name of BRSKI context in IANA registry to 'tBRSKI' (TCP BRSKI) - to make it easier to know when text refers to BRSKI
as an overall cncept or specifically to the TCP based set of variations of BRSKI.</t>
  <t>Removed duplicate text paragraphs in proxy sections.</t>
  <t>Added note about (in)security of discovery mechanisms in general and how deployments typically defer to the "secure domain" context to overcome this issue.</t>
  <t>Large number of textual fixes (thanks a lot for the thorough read!).</t>
</list></t>

<t>WG draft 06:</t>

<t>Initial overview review feedback from Michael Kovatch and Artur Hecker</t>

<t>Made abstract and Challenges introduction hopefully better explaining the scope of
the document and motivate it's need.</t>

<t>Review Steffen Fries:</t>

<t>Cleaned up terminology IP/IPv6 -&gt; IP/IPv4/IPv6.</t>

<t>CA -&gt; trust anchor</t>

<t>BRSKI proxy -&gt; Join Proxy for consistency with RFC8995.</t>

<t>Added mentioning of Registrar-Agent from BRSKI-PRM where appropriate</t>

<t>Rewrote 2.1.3 to make the functionalty of variation agnostistic proxying clearer (hopefully)</t>

<t>Rewrite 3.1.1 to clearer define role and services and distinguish them.</t>

<t>Changed "cms" to "cmsj"(as well as derived variation strings) so that it is clear that this variation type does not mean all possible encoding options for CMS but only JSON.</t>

<t>Added explanation about the fact that a variation may introduce changes to a variation type component that shares the same name (3.1.6)</t>

<t>Noted that discovery of pledges does not apply in 3.2 which talks about redundant service discovery/selection.</t>

<t>removed last paragraph from 3.3.2.2 - duplicate from earlier section.</t>

<t>Improved 3.4.3 by better structuring the example figure and rewriting the explanation text as a step-by-step explanation how a Registrar-Agent would perform the steps.</t>

<t>Fixed small bugs in GRASp example section 3.5.2.2 but ended up improving examples a lot and make them more useful (registrat AND proxy )</t>

<t>Still can not figure out how to nicely get hotlinks to the terminology section definitions. They just
show up in text format as "Section 1" or the like. Giving up on the idea. TBD: Maybe ask RFC editor/RSWG.
Likewise, i can not have references to BRSKI RFCs both with a logical name like BRSKI-PRM and in other
places references with the RFC number. I need to define both as references and then the same RFC will
have two entries. Stupid. Now i only have logical references, but in all places where i need to
actually reference the RFC by number, such as IANA registries or pictures, i do not use references
anymore.</t>

<t>WG draft 05:</t>

<t>Mayor update to specifiy resilience aspects in selection of responders.</t>

<t>Mayor update/simpliciation of CORE-LF section.</t>

<t>WG draft 02/03:</t>

<t>Fix up tables to be correctly rendered by html output.</t>

<t>WG draft 01:</t>

<t>Core-LF improvements  / interim work.</t>

<t>WG draft 00:</t>

<t>Added section for CORE-LF. Still missing to update existing text with the CORE-LF definitions.</t>

<t>Individual version 01:</t>

<t>Various enhancements</t>

<t>Individual version 00:</t>

<t>Initial version.</t>

</section>
</section>


  </middle>

  <back>


    <references title='Normative References' anchor="sec-normative-references">



<reference anchor="RFC2782">
  <front>
    <title>A DNS RR for specifying the location of services (DNS SRV)</title>
    <author fullname="A. Gulbrandsen" initials="A." surname="Gulbrandsen"/>
    <author fullname="P. Vixie" initials="P." surname="Vixie"/>
    <author fullname="L. Esibov" initials="L." surname="Esibov"/>
    <date month="February" year="2000"/>
    <abstract>
      <t>This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="2782"/>
  <seriesInfo name="DOI" value="10.17487/RFC2782"/>
</reference>

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

<reference anchor="RFC5280">
  <front>
    <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
    <author fullname="D. Cooper" initials="D." surname="Cooper"/>
    <author fullname="S. Santesson" initials="S." surname="Santesson"/>
    <author fullname="S. Farrell" initials="S." surname="Farrell"/>
    <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
    <author fullname="R. Housley" initials="R." surname="Housley"/>
    <author fullname="W. Polk" initials="W." surname="Polk"/>
    <date month="May" year="2008"/>
    <abstract>
      <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5280"/>
  <seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference>

<reference anchor="CORE-LF">
  <front>
    <title>Constrained RESTful Environments (CoRE) Link Format</title>
    <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
    <date month="August" year="2012"/>
    <abstract>
      <t>This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6690"/>
  <seriesInfo name="DOI" value="10.17487/RFC6690"/>
</reference>

<reference anchor="mDNS">
  <front>
    <title>Multicast DNS</title>
    <author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
    <author fullname="M. Krochmal" initials="M." surname="Krochmal"/>
    <date month="February" year="2013"/>
    <abstract>
      <t>As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.</t>
      <t>Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.</t>
      <t>The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6762"/>
  <seriesInfo name="DOI" value="10.17487/RFC6762"/>
</reference>

<reference anchor="DNS-SD">
  <front>
    <title>DNS-Based Service Discovery</title>
    <author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
    <author fullname="M. Krochmal" initials="M." surname="Krochmal"/>
    <date month="February" year="2013"/>
    <abstract>
      <t>This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6763"/>
  <seriesInfo name="DOI" value="10.17487/RFC6763"/>
</reference>

<reference anchor="RFC7390">
  <front>
    <title>Group Communication for the Constrained Application Protocol (CoAP)</title>
    <author fullname="A. Rahman" initials="A." role="editor" surname="Rahman"/>
    <author fullname="E. Dijk" initials="E." role="editor" surname="Dijk"/>
    <date month="October" year="2014"/>
    <abstract>
      <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This specification defines how CoAP should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed based on existing CoAP functionality as well as new features introduced in this specification. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7390"/>
  <seriesInfo name="DOI" value="10.17487/RFC7390"/>
</reference>

<reference anchor="GRASP">
  <front>
    <title>GeneRic Autonomic Signaling Protocol (GRASP)</title>
    <author fullname="C. Bormann" initials="C." surname="Bormann"/>
    <author fullname="B. Carpenter" initials="B." role="editor" surname="Carpenter"/>
    <author fullname="B. Liu" initials="B." role="editor" surname="Liu"/>
    <date month="May" year="2021"/>
    <abstract>
      <t>This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and Autonomic Service Agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8990"/>
  <seriesInfo name="DOI" value="10.17487/RFC8990"/>
</reference>

<reference anchor="ACP">
  <front>
    <title>An Autonomic Control Plane (ACP)</title>
    <author fullname="T. Eckert" initials="T." role="editor" surname="Eckert"/>
    <author fullname="M. Behringer" initials="M." role="editor" surname="Behringer"/>
    <author fullname="S. Bjarnason" initials="S." surname="Bjarnason"/>
    <date month="May" year="2021"/>
    <abstract>
      <t>Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8994"/>
  <seriesInfo name="DOI" value="10.17487/RFC8994"/>
</reference>

<reference anchor="BRSKI">
  <front>
    <title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title>
    <author fullname="M. Pritikin" initials="M." surname="Pritikin"/>
    <author fullname="M. Richardson" initials="M." surname="Richardson"/>
    <author fullname="T. Eckert" initials="T." surname="Eckert"/>
    <author fullname="M. Behringer" initials="M." surname="Behringer"/>
    <author fullname="K. Watsen" initials="K." surname="Watsen"/>
    <date month="May" year="2021"/>
    <abstract>
      <t>This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8995"/>
  <seriesInfo name="DOI" value="10.17487/RFC8995"/>
</reference>

<reference anchor="BRSKI-AE">
  <front>
    <title>BRSKI with Alternative Enrollment (BRSKI-AE)</title>
    <author fullname="D. von Oheimb" initials="D." role="editor" surname="von Oheimb"/>
    <author fullname="S. Fries" initials="S." surname="Fries"/>
    <author fullname="H. Brockhaus" initials="H." surname="Brockhaus"/>
    <date month="March" year="2025"/>
    <abstract>
      <t>This document defines enhancements to the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol, known as BRSKI with Alternative Enrollment (BRSKI-AE). BRSKI-AE extends BRSKI to support certificate enrollment mechanisms instead of the originally specified use of Enrollment over Secure Transport (EST). It supports certificate enrollment protocols such as the Certificate Management Protocol (CMP) that use authenticated self-contained signed objects for certification messages, allowing for flexibility in network device onboarding scenarios. The enhancements address use cases where the existing enrollment mechanism may not be feasible or optimal, providing a framework for integrating suitable alternative enrollment protocols. This document also updates the BRSKI reference architecture to accommodate these alternative methods, ensuring secure and scalable deployment across a range of network environments.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9733"/>
  <seriesInfo name="DOI" value="10.17487/RFC9733"/>
</reference>


<reference anchor="BRSKI-PRM">
   <front>
      <title>BRSKI with Pledge in Responder Mode (BRSKI-PRM)</title>
      <author fullname="Steffen Fries" initials="S." surname="Fries">
         <organization>Siemens AG</organization>
      </author>
      <author fullname="Thomas Werner" initials="T." surname="Werner">
         <organization>Siemens AG</organization>
      </author>
      <author fullname="Eliot Lear" initials="E." surname="Lear">
         <organization>Cisco Systems</organization>
      </author>
      <author fullname="Michael Richardson" initials="M." surname="Richardson">
         <organization>Sandelman Software Works</organization>
      </author>
      <date day="3" month="June" year="2025"/>
      <abstract>
	 <t>   This document defines enhancements to Bootstrapping Remote Secure Key
   Infrastructure (BRSKI, RFC8995) as BRSKI with Pledge in Responder
   Mode (BRSKI-PRM).  BRSKI-PRM supports the secure bootstrapping of
   devices, referred to as pledges, into a domain where direct
   communication with the registrar is either limited or not possible at
   all.  To facilitate interaction between a pledge and a domain
   registrar the registrar-agent is introduced as new component.  The
   registrar-agent supports the reversal of the interaction model from a
   pledge-initiated mode, to a pledge-responding mode, where the pledge
   is in a server role.  To establish the trust relation between pledge
   and registrar, BRSKI-PRM relies on object security rather than
   transport security.  This approach is agnostic to enrollment
   protocols that connect a domain registrar to a key infrastructure
   (e.g., domain Certification Authority).

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-anima-brski-prm-23"/>
   
</reference>


<reference anchor="cBRSKI">
   <front>
      <title>Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI)</title>
      <author fullname="Michael Richardson" initials="M." surname="Richardson">
         <organization>Sandelman Software Works</organization>
      </author>
      <author fullname="Peter Van der Stok" initials="P." surname="Van der Stok">
         <organization>vanderstok consultancy</organization>
      </author>
      <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
         <organization>Cisco Systems</organization>
      </author>
      <author fullname="Esko Dijk" initials="E." surname="Dijk">
         <organization>IoTconsultancy.nl</organization>
      </author>
      <date day="18" month="October" year="2025"/>
      <abstract>
	 <t>   This document defines the Constrained Bootstrapping Remote Secure Key
   Infrastructure (cBRSKI) protocol, which provides a solution for
   secure zero-touch onboarding of resource-constrained (IoT) devices
   into the network of a domain owner.  This protocol is designed for
   constrained networks, which may have limited data throughput or may
   experience frequent packet loss. cBRSKI is a variant of the BRSKI
   protocol, which uses an artifact signed by the device manufacturer
   called the &quot;voucher&quot; which enables a new device and the owner&#x27;s
   network to mutually authenticate.  While the BRSKI voucher data is
   encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher.  The
   BRSKI voucher data definition is extended with new data types that
   allow for smaller voucher sizes.  The Enrollment over Secure
   Transport (EST) protocol, used in BRSKI, is replaced with EST-over-
   CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP
   (CoAPS).  This document Updates RFC 8995 and RFC 9148.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-anima-constrained-voucher-29"/>
   
</reference>


<reference anchor="cPROXY">
   <front>
      <title>Join Proxy for Bootstrapping of Constrained Network Elements</title>
      <author fullname="Esko Dijk" initials="E." surname="Dijk">
         <organization>IoTconsultancy.nl</organization>
      </author>
      <author fullname="Michael Richardson" initials="M." surname="Richardson">
         <organization>Sandelman Software Works</organization>
      </author>
      <author fullname="Peter Van der Stok" initials="P." surname="Van der Stok">
         <organization>vanderstok consultancy</organization>
      </author>
      <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
         <organization>Cisco Systems</organization>
      </author>
      <date day="19" month="October" year="2025"/>
      <abstract>
	 <t>   This document extends the constrained Bootstrapping Remote Secure Key
   Infrastructures (cBRSKI) onboarding protocol by adding a new network
   function, the constrained Join Proxy.  This function can be
   implemented on a constrained node.  The goal of the Join Proxy is to
   help new constrained nodes (&quot;Pledges&quot;) securely onboard into a new IP
   network using the cBRSKI protocol.  It acts as a circuit proxy for
   User Datagram Protocol (UDP) packets that carry the onboarding
   messages.  The solution is extensible to support other UDP-based
   onboarding protocols as well.  The Join Proxy functionality is
   designed for use in constrained networks, including IPv6 over Low-
   Power Wireless Personal Area Networks (6LoWPAN) based networks in
   which the onboarding authority server (&quot;Registrar&quot;) may be multiple
   IP hops away from a Pledge.  Despite this distance, the Pledge only
   needs to use link-local communication to complete cBRSKI onboarding.
   Two modes of Join Proxy operation are defined, stateless and
   stateful, to allow different trade-offs regarding resource usage,
   implementation complexity and security.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-anima-constrained-join-proxy-18"/>
   
</reference>


<reference anchor="JWS-VOUCHER">
   <front>
      <title>JWS signed Voucher Artifacts for Bootstrapping Protocols</title>
      <author fullname="Thomas Werner" initials="T." surname="Werner">
         <organization>Siemens AG</organization>
      </author>
      <author fullname="Michael Richardson" initials="M." surname="Richardson">
         <organization>Sandelman Software Works</organization>
      </author>
      <date day="15" month="January" year="2025"/>
      <abstract>
	 <t>   This document introduces a variant of the RFC8366 voucher artifact in
   which CMS is replaced by the JSON Object Signing and Encryption
   (JOSE) mechanism described in RFC7515.  This supports deployments in
   which JOSE is preferred over CMS.  In addition to specifying the
   format, the &quot;application/voucher-jws+json&quot; media type is registered
   and examples are provided.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-anima-jws-voucher-16"/>
   
</reference>

<reference anchor="EST">
  <front>
    <title>Enrollment over Secure Transport</title>
    <author fullname="M. Pritikin" initials="M." role="editor" surname="Pritikin"/>
    <author fullname="P. Yee" initials="P." role="editor" surname="Yee"/>
    <author fullname="D. Harkins" initials="D." role="editor" surname="Harkins"/>
    <date month="October" year="2013"/>
    <abstract>
      <t>This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7030"/>
  <seriesInfo name="DOI" value="10.17487/RFC7030"/>
</reference>

<reference anchor="RFC8368">
  <front>
    <title>Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM)</title>
    <author fullname="T. Eckert" initials="T." role="editor" surname="Eckert"/>
    <author fullname="M. Behringer" initials="M." surname="Behringer"/>
    <date month="May" year="2018"/>
    <abstract>
      <t>Operations, Administration, and Maintenance (OAM), as per BCP 161, for data networks is often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes.</t>
      <t>Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on. Changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns.</t>
      <t>This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to the aforementioned circular dependencies.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8368"/>
  <seriesInfo name="DOI" value="10.17487/RFC8368"/>
</reference>

<reference anchor="RFC9483">
  <front>
    <title>Lightweight Certificate Management Protocol (CMP) Profile</title>
    <author fullname="H. Brockhaus" initials="H." surname="Brockhaus"/>
    <author fullname="D. von Oheimb" initials="D." surname="von Oheimb"/>
    <author fullname="S. Fries" initials="S." surname="Fries"/>
    <date month="November" year="2023"/>
    <abstract>
      <t>This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and Internet of Things (IoT) scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and transfer based on HTTP or Constrained Application Protocol (CoAP) in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the most crucial types of operations and options are specified as mandatory. More specialized or complex use cases are supported with optional features.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9483"/>
  <seriesInfo name="DOI" value="10.17487/RFC9483"/>
</reference>

<reference anchor="DNSSD-SRP">
  <front>
    <title>Service Registration Protocol for DNS-Based Service Discovery</title>
    <author fullname="T. Lemon" initials="T." surname="Lemon"/>
    <author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
    <date month="June" year="2025"/>
    <abstract>
      <t>The Service Registration Protocol (SRP) for DNS-based Service Discovery (DNS-SD) uses the standard DNS Update mechanism to enable DNS-SD using only unicast packets. This makes it possible to deploy DNS-SD without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly IEEE 802.11 (Wi-Fi) and IEEE 802.15.4 networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9665"/>
  <seriesInfo name="DOI" value="10.17487/RFC9665"/>
</reference>

<reference anchor="RFC9148">
  <front>
    <title>EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol</title>
    <author fullname="P. van der Stok" initials="P." surname="van der Stok"/>
    <author fullname="P. Kampanakis" initials="P." surname="Kampanakis"/>
    <author fullname="M. Richardson" initials="M." surname="Richardson"/>
    <author fullname="S. Raza" initials="S." surname="Raza"/>
    <date month="April" year="2022"/>
    <abstract>
      <t>Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9148"/>
  <seriesInfo name="DOI" value="10.17487/RFC9148"/>
</reference>

<reference anchor="RFC9176">
  <front>
    <title>Constrained RESTful Environments (CoRE) Resource Directory</title>
    <author fullname="C. Amsüss" initials="C." role="editor" surname="Amsüss"/>
    <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
    <author fullname="M. Koster" initials="M." surname="Koster"/>
    <author fullname="C. Bormann" initials="C." surname="Bormann"/>
    <author fullname="P. van der Stok" initials="P." surname="van der Stok"/>
    <date month="April" year="2022"/>
    <abstract>
      <t>In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9176"/>
  <seriesInfo name="DOI" value="10.17487/RFC9176"/>
</reference>

<reference anchor="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname="S. Bradner" initials="S." surname="Bradner"/>
    <date month="March" year="1997"/>
    <abstract>
      <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
  <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>

<reference anchor="RFC8174">
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <date month="May" year="2017"/>
    <abstract>
      <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="8174"/>
  <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>




    </references>

    <references title='Informative References' anchor="sec-informative-references">




<reference anchor="I-D.ietf-bess-evpn-fast-df-recovery">
   <front>
      <title>Fast Recovery for EVPN Designated Forwarder Election</title>
      <author fullname="Patrice Brissette" initials="P." surname="Brissette">
         <organization>Cisco</organization>
      </author>
      <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
         <organization>Cisco</organization>
      </author>
      <author fullname="Luc André Burdet" initials="L. A." surname="Burdet">
         <organization>Cisco</organization>
      </author>
      <author fullname="John Drake" initials="J." surname="Drake">
         <organization>Independent</organization>
      </author>
      <author fullname="Jorge Rabadan" initials="J." surname="Rabadan">
         <organization>Nokia</organization>
      </author>
      <date day="20" month="November" year="2024"/>
      <abstract>
	 <t>   The Ethernet Virtual Private Network (EVPN) solution in RFC 7432
   provides Designated Forwarder (DF) election procedures for multihomed
   Ethernet Segments.  These procedures have been enhanced further by
   applying the Highest Random Weight (HRW) algorithm for Designated
   Forwarder election to avoid unnecessary DF status changes upon a
   failure.  This document improves these procedures by providing a fast
   Designated Forwarder election upon recovery of the failed link or
   node associated with the multihomed Ethernet Segment.  This document
   updates RFC 8584 by optionally introducing delays between some of the
   events therein.

   The solution is independent of the number of EVPN Instances (EVIs)
   associated with that Ethernet Segment and it is performed via a
   simple signaling in BGP between the recovered node and each of the
   other nodes in the multihoming group.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-bess-evpn-fast-df-recovery-12"/>
   
</reference>

<reference anchor="RFC5988">
  <front>
    <title>Web Linking</title>
    <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
    <date month="October" year="2010"/>
    <abstract>
      <t>This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5988"/>
  <seriesInfo name="DOI" value="10.17487/RFC5988"/>
</reference>

<reference anchor="COAP">
  <front>
    <title>The Constrained Application Protocol (CoAP)</title>
    <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
    <author fullname="K. Hartke" initials="K." surname="Hartke"/>
    <author fullname="C. Bormann" initials="C." surname="Bormann"/>
    <date month="June" year="2014"/>
    <abstract>
      <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t>
      <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7252"/>
  <seriesInfo name="DOI" value="10.17487/RFC7252"/>
</reference>

<reference anchor="RFC8894">
  <front>
    <title>Simple Certificate Enrolment Protocol</title>
    <author fullname="P. Gutmann" initials="P." surname="Gutmann"/>
    <date month="September" year="2020"/>
    <abstract>
      <t>This document specifies the Simple Certificate Enrolment Protocol (SCEP), a PKI protocol that leverages existing technology by using Cryptographic Message Syntax (CMS, formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8894"/>
  <seriesInfo name="DOI" value="10.17487/RFC8894"/>
</reference>


<reference anchor="I-D.eckert-anima-grasp-dnssd">
   <front>
      <title>DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling Protocol (GRASP)</title>
      <author fullname="Toerless Eckert" initials="T. T." surname="Eckert">
         <organization>Futurewei Technologies USA
      Inc.</organization>
      </author>
      <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
         <organization>Orange</organization>
      </author>
      <author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
         <organization>Orange</organization>
      </author>
      <author fullname="Michael H. Behringer" initials="M. H." surname="Behringer">
         </author>
      <date day="7" month="July" year="2025"/>
      <abstract>
	 <t>   DNS Service Discovery (DNS-SD) defines a framework for applications
   to announce and discover services.  This includes service names,
   service instance names, common parameters for selecting a service
   instance (weight or priority) as well as other service-specific
   parameters.  For the specific case of autonomic networks, GeneRic
   Autonomic Signaling Protocol (GRASP) intends to be used for service
   discovery in addition to the setup of basic connectivity.
   Reinventing advanced service discovery for GRASP with a similar set
   of features as DNS-SD would result in duplicated work.  To avoid
   that, this document defines how to use GRASP to announce and discover
   services relying upon DNS-SD features while maintaining the intended
   simplicity of GRASP.  To that aim, the document defines name
   discovery and schemes for reusable elements in GRASP objectives.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-eckert-anima-grasp-dnssd-08"/>
   
</reference>


<reference anchor="HRW98" target="https://www.microsoft.com/en-us/research/wp-content/uploads/2017/02/HRW98.pdf">
  <front>
    <title>Using Name-Based Mappings to Increase Hit Rates</title>
    <author initials="D. D." surname="Thaler" fullname="Dave D. Thaler">
      <organization></organization>
    </author>
    <author initials="C. V." surname="Ravishankar" fullname="Chinya V. Ravishankar">
      <organization></organization>
    </author>
    <date year="1998"/>
  </front>
</reference>


    </references>


<?line 2511?>


    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
        <name>Contributors</name>
    <contact initials="T." surname="Werner" fullname="Thomas Werner">
      <organization>Siemens AG</organization>
      <address>
        <postal>
          <country>Germany</country>
        </postal>
        <email>thomas-werner@siemens.com</email>
        <uri>https://www.siemens.com/</uri>
      </address>
    </contact>
    <contact initials="S." surname="Fries" fullname="Steffen Fries">
      <organization>Siemens AG</organization>
      <address>
        <postal>
          <country>Germany</country>
        </postal>
        <email>steffen.fries@siemens.com</email>
        <uri>https://www.siemens.com/</uri>
      </address>
    </contact>
    <contact initials="H." surname="Brockhaus" fullname="Hendrik Brockhaus">
      <organization>Siemens AG</organization>
      <address>
        <postal>
          <country>Germany</country>
        </postal>
        <email>hendrik.brockhaus@siemens.com</email>
        <uri>https://www.siemens.com/</uri>
      </address>
    </contact>
    <contact initials="M." surname="Richardson" fullname="Michael Richardson">
      <organization></organization>
      <address>
        <postal>
          <country>Canada</country>
        </postal>
        <phone>+41 44 878 9200</phone>
        <email>mcr+ietf@sandelman.org</email>
      </address>
    </contact>
    <contact initials="D." surname="von&nbsp;Oheimb" fullname="David von&nbsp;Oheimb">
      <organization abbrev="Siemens">Siemens AG</organization>
      <address>
        <postal>
          <street>Otto-Hahn-Ring 6</street>
          <city>Munich</city>
          <code>81739</code>
          <country>Germany</country>
        </postal>
        <email>david.von.oheimb@siemens.com</email>
        <uri>https://www.siemens.com/</uri>
      </address>
    </contact>
    </section>

  </back>

<!-- ##markdown-source:
H4sIAHeE9mgAA9y9+3LkxpE3+n89Bb5WxBG5291zH83Qtnap4cia3blwScpe
h61QoLtBEpom0AugSbUn9D3LeZbzZCfvlQWgqct6vxNxHGF7SAKFumTl9ZeZ
s9ksLOtVWV0dZdvucvYihK7s1sVR9vlXZ+f//iZble2yvi2aXZZXq+w2b8q8
K+uq/Tzki0VT3B5l9NzMngurelnlNzDCqskvu1lZwLB5Vd7ks0XTfizjk7OH
L0PbwbDf5+u6ghe6ZluEctPQv9ru8cOHLx8+Du12cVO2LXz0YreBp968vvg6
5E2RH2UfNkXD06HZvcur/Kq4Kaou3MF6jt+/eXccPt7BK1VXNFXRzU5wSmG7
WeVd0e6d4aa5mWbN5fL585cP6R8vv3jyJCzz7ihruxXsV9UWVbttZcab8ihk
WVcvYdN2BewM/bAqNt31UfYMflrWN5t82cU/t7ubprhs3S/qpkt/A9tQ1V15
WRYr+GVV01NdU8Zh8m13XTdHYZaVFbx4Mc9eLz8WTQcP8v5f1EWzLto2/r6p
8WSLVdnVDfxYN7BLX2+7bVPcFWX27fkx/FKP1X5PC9hWXbM7kkeKm7xcw+K7
4l+X7fwy385XhU7j9Tw7KX/4aJN43X6s9Tf0vTf1BW7gdg0nv9zNq3UcsIBn
5yt49l/Luus9hLsOy19sO16zLPG6vsnb7M94uo2f6B+L5iavdvrR8xLJos2O
/+imT+/O7ujdf235iTmcFTyybcqj7LrrNu3Rgwd3d3dz9+cH9vXzrri8LKrs
66Ys2l/59ZbfnV/iu7/p698U1aopP2ZfNfXy43W+/bUzuOb35wt9/zfN4l25
vM6LdXaG/9+s2rry03gFN3KVw28213TDJ//89FH29Gn24osX2Uu435M4nZtl
8894E/+1hatcrGH2c5i6ktXJPLutq/+rWrSb3324LsqbhVHYSX5brkb+Oly4
krb8km9UUcCN+tB19eyb/LqanQErzJ7jGsoOFvBuW8HCaEkrZIovHn3x5OXn
4zstC1nhfOYwn3lNU/lV2xqqGobrytsCecrZ168ef/HisfzzycsXz+Wfzx6/
eIj/fPXh7PXs7ddH+DvkVvCrm5P35/zzF88fw8/w4+z8RH/zhN+HRdD7fzw7
Pj+lv714SW8fv7Ifn8KPxNv1F8/0F7Pj1/Q7Yov6u9Ozd3C5ZyfzMXaKGyZj
9R7Ba941eVkVq9ltvV1e8z0+Pfvwn3+59+Ef6rKCoesfcev/7c/nsz99+PbV
N6/PBi/9cNe6kV+fX9Dcv3j45CHvxYsnz1/Itr58+uLJEe/Z+cns/Iz34uXz
58/k74+e2qOPvoDDCKGsLv2J2bcXwHhnxe2mml3mbTdbXc6agsWeHuHLFy/4
CI/5M188fvZYZvTi5VMdrCDeLUu5avJ2M1tVbbvCv39z9ueXNAYIHBbak29b
pN/3cDFmX+VtgTJxs4FftSCSQAwuQWy2RfZN2WVnKAIn9DJKw6Ps0cuXL+hH
FSwZ/Wcm/++uW4HX8eI6X9OOjj306rqsdnn2pzl85rZsr/PqY87PdnlzhTfO
34CbctnUbX3Z0R0oqtm2fdAUbZE3y+sHdxs89g6E+oPtZl3nq/bB44ePvnjw
8PEDWv98s7oMYTabwfVG4lh2IVxcl20GesgWdYGs3RRLFKRtdl3f4T7c5B8L
ploUzTd4xVWLAPECX7ssr+CaVlfTrPgRvtyWi3VBGgbMqlyXqGCUFQiQIrvM
l0VWX2ZteUPCqqi3bbZt6XerEjh8gzOIahP+Ht/jrwP54vfW2QH9PLXrNQ12
qaaZo/pMngO1qStItg/+iIP+CIs9xCNy2xDiNuR44nl2AyxtPc3eHL8/hoVd
lTAOa3m2NRtg2jB9GHFZrEAbICrKl9dlATTQwejz/l6vangIFJdsVVzCnGC4
XVYVd06NvCmAulbtHKgRZGC+mmZl17oJZfl6Xd+1Ab7UlldVTr/IltuGdvIA
53dJqsnh3m29zG/K9Q5/pxvM+wQrhDHWu3Bb5u50ih/hD3htQEO8q5uPyWRB
qlVle4MiiBjpNHtVH5+6Rw6EBx/S1hFDnYfjFehYMLF8/YAnOzpmtswrWF1b
Z4sia7ebDWiBcIzddVNvr65pQcnhwG4fA4Eit1kaKS75zPBmzOCiIdlmoB1n
RZUD1aajGWGOzAUHgWcCbBncWJg7DgQPI12XG6B/kMOojRW02T0SaWH6y+sM
VDGZa97wiP8GXDo7ZYrcT5A4t5TIZDd6y4IBD5CdHsIRl2tcQrYFZaGhH3GX
+Y7K4urL0MCI1SqHQ45ThV1k3RY/ibtRAFvZ3dAqbGVN8V/bEufiFwDzzDvi
EXQEQJc7mygSuhJppFG+xpFQe1uQ7d0C5FTJp5FU9Ft48/RcdReX8fFd5CuL
4hr4b93o6d5HAXSXC50Sc8QMhJt7GG8U0NQVzGexw/HKJntzUty+OcGjL0Eh
qldbWAL+1RhYViJVXBKHIq7pNmDOnPumXK3WRQifZRegTZVVva6vdtmnz7r4
0088u4/FLoM7umqzybtvzy8mU/7/7P0H+vfZ6//49s3Z6xP89/k3x2/f2j+C
PHH+zYdv357Ef8U3X3149+71+xN+GX6bJb8Kk3fHf4G/4EZOPpxevPnw/vjt
ZLAgunodXegSjc5NU+CVztuwKtol2C+8CV+9Ov1//u9HT7NPn/4X6niPHr38
6Sf5ATTMp/DDHajn/LW6AjLjH2HHdwEEOkhGHIUYY74pO+AhUzyBFsimAsW+
KWBj/+mvuDPfHWW/Xyw3j55+Kb/ABSe/1D1Lfkl7NvzN4GXexJFfjXzGdjP5
fW+n0/ke/yX5Wffd/fL3/7JGOTN79OJfvgx9adQUa7w7NctqR00inugsPn0i
Uv3pp3mWIYld1iiAkN/gCy2daDy8Td6ABKHdFx4PW/0KFZQfu6NwlB1nbdHh
RTkvmtsSuSVeoTuwNWkOLahH+oQTX3CmOFNYwJtTkMint0/pf5/jiG96JIZ/
wQtVNMQpD8pqud62oH+ud4f0Klg+9DKI2EuQ9aQrMG3yV/AtIirghyo4QfBl
cMWR77dEZ3HL2mRQ2g7gIitY9psKNiAngxwXfl23HbPIEnUg5tg4WRAHVUuc
yxgTTKHkt4Fpo3CuiiUxHPgMPZ7zj6hvgDoBJM3DI9MtmJUBmwSODtzfzyRr
wZgt9CTo3yr6RZ7BlEp9GpeG5whDwaptcnjr7Aead7W9WaCYaeAY767BIgSl
BZ00soTWraDtLYF1pjjb7KDbbUR4fHtyik9fvDo9hEV8WPyAQ4Bqhfo7LuG8
KJSO6Hfw0FnR1tsGfiZn2N5n+Fu/6VxkpvhPfxIwT3dMKB+LFiQmbQkOp3vq
v/8LTiNuzC89DDT8+ThgHnoYOkzLK5DJCXFHNXvf1p+hY2z0rl1uqyVrcmW3
E/qBP+APyAPiJY66A201qXbLDrmyP3xcDTCD1ut7jg/gW4uoLMItU30EJohi
dF3cojYzEDvEBFYFKwFnqoNNvVJAG0nSe058LtX7lSGSXE8EGqnjpJORZrDz
870k1WLH05sTLZI+KwwRdvbcKAC/CVrYoqxsv/KbLDl0JstIjLiR2w7U3L+T
1eKv4oEqnHCCeJBwnqyBp48RBeSRwHFG7rLovNBqpcUcAL/cLphBH7KF5wng
wfEpGVi35Yr3KrezQm3bHTRTu+h7yEbx8pUVMLISz5yuzadPbFOAuF9sYaUV
WXTE7e7K1lQx1B9wU5HrDk8euQvw9R2zyh2/7nS2wfz59L0wpIEX+qqzCeJ1
YWsJjvhr2KTix/wGKGlKWgmsgoweWASxl4I4h34/IX7hALjPYsfiBqdsD65A
06hCjEr4bb6WZZL8lMPDA0MTEr4u9tdPP/FwCYPMDpruD4f7xhT2kIwJKoRj
rH+y242/hT/aL5inJfSM0hT+GznC8rrGcQuwmGnRBR1I/HuHMyShvCTqkTUu
+fLg9HC8hMDGvBZz4IjJsYhvwo0j2+3ZVdnS6DJHnN4E7W9Qcfu/Liq43uuJ
KKPL9I+37P6a+L0x2ZRcLRw2R5LumPHbNWcFCfk4aiHww03d6Edats6zA/x1
vpOf1PnCfoCpcNUCVe9rfRO9iMBPOqDmSoh4oQwIaBR4xHV9hdeC1CGi/PRk
+vaqscjoaOi9YDuYbNn+Lcpe0UwHO+UdR+ut2Z2ke5bL7TrvT5W2Biy9YkAK
3dA7w8to3VbBxJvmRma7wX/hLMaWyQtEP8SrU5z25LjK0CVR1TdggSLXh3Vn
p+u8wm349AkeA706sBlML3xV1x3KJvJKwmW9qTvUX5Zoj/87GHdvqssGLPxm
u8SzpUFUPZdh0PtMn15jUI88r9lr2m9a46m5fLxuHweC191Y6LXGwezB7K7s
rmEFKCczkqXKvd7x2eow8CaNs4xre+V9cb9qndmBTeCQvrGMiyYHMQ6PNOI/
ccycgw7m1FQcdE/xGPiijMBRgv4cz16fX1xu17B7t2VTV+wCgQHOXh9mb8vq
I5ISEu7Uc1lcMnvn+8M5XYNYfLIDdiy8PBqBBpP4BA6G/2SvtcroExVj9JZK
S3gL3fj4ijt4Ejeywxeq2dJ78DC9xNEOfO2PRVWcAcVG2j0nX6OfKb0qok1f
nlFkwCZ7fgIHcrOBI0DePJg00s8v+VJ2QIPzqd3n9KeJ+FgHTgR+Jk8pbNuf
OMyRHQOfuATts/3Zg3CD0eDru1fveIvellfX3V2B/5u9KnBApLXCBdk90b0D
7Qt+vCzXfEckmEJjUkQKhyRX4hKoHn2p9Bj+iZ45f/WaP3teIuNKvkhnnHxQ
P4GBEnr9s+zDLe5+cQcm9GefAWNFO7G6QpP6qzNgYXc5Mj7ZJudfpCnNbotq
hXzXeQJBwSOZQezg70VTm72fr1MfqQgjdR7/sG07/wW6yKSqNMUSF7Er8gZ0
XfWrhp8NDrBkM2VwCqfNqm/CiqZZ8BzOMxFi7PHS/Y4WxdMGLVOlg4oZ+JbN
rd6ICYt/qQreu8RZjTrwei1TJsMIFa2yuq3Xt6yu5vzHUNhVnZq3mO0RsvbE
QjH/MZzqo3l23LZbkYoi00ijlGdYjZbTO0aVho9QPkyWGvrgUJmW88EgFOkS
1RZvCIV5YBp5lRwaK0pFl7g81dQtlnW7a7vihpw49PEWNwGHZvMaD9Fm1URr
TOyTKMbN1uifeSQKFOnZW7gHDUZKYPNBhcEYCxBT2+YN6/1oHvDS6U0MQqWz
9uEOnT6N/Cee5ldq1bTp/pIeAPtqL03JVEFHJBAOuZPbGl1aa2IUNm3a5ksl
/vcYd2NDnJzZdkoanChKUsDwmeOMphM32UwJfghHdkEGeZxIB/6nvkHHFlgt
H1HfBPqpiBSWGPWkSdOf8Dt3IPGu3OHguJFETQPibYQbA0SOUQY8gHzLownZ
jrgASg6CLU044OjESog09IWD9jC9SqKT1W1RJTcB3vZ7CJIFrwJOVB0HIFpg
ObKPdOayM22XN0Tbl+WP2XZDY5Rwq2hKi5157fF1Okr4wAZpH2lLwp/siCOf
oZ3GhNz/E9Y/YeFuujLbXDePpsNnG48VlXMacVHIvuMWFMCXVnjJjh1PyJE8
aSgiK36JH2TC/XHHRq3y4JpwYbD8CqZxCVeTghO18GkwiVAaHmVvOjkoHHZT
txrn3ZEBAs+jSq2DtsKHF2ArwOwoTmqXTPw2uo6pUgkOXNJXNte7dlmSSEHK
sK/BJEEdzyv522WR8+87u9DpByWUhgN/aLLykqmafdR8qaY2q7t6u5b4Qe9u
kP+Ubqx4hEJ4PM/O8fhh1jO6LmJkAg+8y0k61DHCAxuPUd1I+WzYRcbuqAqn
yo8XFUMNJQZsd+wGORnQSfEjeh5w5uhWcixr6bSBeEfp1NSvk30FbKmiOwK7
LXamHIsZfXQD0UkSt5/uSzRLmWHhyMg58Pl6S45zuhT4fZQVJPe3G6DrSqJx
Bboe4XYBrxHrNa9Jnuer2XW9ZKOrVM7IjoCuvBHuGW/FRhz7aCxbZC9hMCKS
4cSeoHhEEnAaBNMoBeBh91DKAMOvkMdOIyGjtUhUoeLOfy0wAqSOHiTdY5Zf
w1kBPy9X9M0FbyfRLoX/r5lplcS1R/jkkig08XiSRlH1vVgmGM07RYd0XrNq
4sxhdEmB+kEKza7obCxY46y+vARi3iUOKkQfJGJLPWxIscrc7GmhXHsG1kfn
DfwYNpK0CHlFd1vCqjGqBDJ/1mqsIO/g1DfEn2kcchWQw00iTnRB3E2Iii2p
Vt69QQMAAS1R3QEqvdrmdLM/A4U4Gh19kx4voXPRFWueGrz3Z9xKHy5B3tA6
l6eLHtvFj1ZaSNyAleEH+m43jkx0FC8VB74EGuCfpPMgvcYTIN58nbPDjT6r
I2Nk3zs/RKdSbig6no2UxNdpF1SrmIc3lQhb0JBlzvv0dO8vpaUQ2JfDvySI
FiW6XoEtFw0dL4wXMFKFpir9Aa8OKtHuEkSwBS5e7ymsbNlRNDjvWJDb0aBy
7uE5of/9jJntjgYkEcQKH42zKNqO7CP8NtB4Uy5BokZ9mHQS1WzxYT+893tP
hV6HBGITRGfsTkSx6LAh2laZAepq5N2tztA7aWWfqxVJhNb//QFGIvR8fIQQ
L8ErwwDZwpD6fRwWgWitu297gBIn9oCg5J3liPvLbPxnxpmOXBrnc5gG53XB
0yM+1qJO63VOoGGH0V83Rb6K0Rz1u44dyLbdItsI13krVl1TzGLIAbcX6GPL
aol5r/uMOfJj9pYitq7FS1tfwkZnSwrDoJAjQBdxF71ZsDVIbmNzo7hSFDXG
hm2bTcOSPYy2eYpfIXWQ/MCI+cuzNSr9KHjRIofhipWD4SxNOvVCXHaO4X4Y
FypvsFtrOANWlwx1tiTcHYjPa2InfHf1ZsKjxX/xYZgBul6P0KVnEj2KRPqO
3uX8qqpbRIl5Ovf8LoRTYYtoo14J+AlPTK38yIMTi5CunozaptaMifUwsGnE
ENBvZQjAy53DkNV350A0bmHcOnLnoGAmt0HE2SIWa8V6AGhq9Vb2+waI75bB
D5vB0vPlsm5QNcUjEJ3iTkEQ/cnLzrQar+EZqxgjS1E3r7TAFWnbwdt0Y8GF
1q9JJzLAgS2KaP9hcBDjMmTx4A968iEh46OMpbnfYzvFNGrFd885Kd6cKjSE
d1Z9q+Hg4tXplCLphDG53K4fGDD1cMpCuuwS6JrHckaYXP++IQ6RkDL7Pm2a
OYsR4XR+bUDMd2gVMWyBAL28PEn+wQNw/h7dtZ5dPe0H58UGRnagjr9NvkOU
ImEl2ZBpJeC4CnJvO4r4w249wM1yWBH2pqA0JrSNLc8xF8LaZO9RGR37M06K
VG/vSJRhnb+unglyRoKCqpZKKA/mbsZZyv7Ibh6XY4TjZcZn1xXzohrT6cIA
z4AMYV1c5cudP63erhugZ71PTsOb5kvCmBbi2hFJFNUIWUxxCW92R6LLuqts
GInZ8FInt8S8NrqdKHTyETMoIJF6b5+hqMb4GuFWKftNYp/ehCGoztQYgNwh
mWJIeZJjzSmnlq1jrc3bSCKpDeKqAAnmL7STAdjJLM6oH8JngZN9bdCC7Hx7
c4OK3F7ofa6otxR20qH62EZIAAkC9K7x7wl8Eu1JWjqYTJQHVvRkcxzUa+R1
FAK41yZOVj0NDvXG4LBIoBTdFcCs8lZwrs4jm52QNc/qMEwWpVl/RTf5j+UN
4VaiDrALpl/uAWBjdkYbzfLLX6abhkQT+NYU9ZULREWlOqp4DhpuW94PGdsJ
hlXR5eWajB+zEpmHw69ntKkkMvWr5OhJjLXUZiDP3i2827MgAlOAA0OzZUiS
W2wWA7/zMC0wNzNz1LfQKgAz8bep4FjtwJIol6MKHdqRoJ2BPrZ3N/z0+rpV
orakVqNTYhSItxujBnS1eN3Fay0zWrJqGMbTvArjdQ7HERYUWxU0rL/dxAh6
yhqjYdODoOsYEkdg4gZ0AHrdZ+Oam6smX1kIYJ5h0O7c693EUk4wDwQj7WuJ
0PtoKkxgQWfnAekEuxG3QJKi4C5zZIXBce548WVPgcIJFYUHA6QsIYm880ON
OLHUN2XRsrJ1nn8WIA/MulYvf8RSmhEvjFmcQ9lVCfpqkIeXxaYDE4Gi3Bjn
xM9fq7sTd4bN/pWYAmeEF8RFKQ45hCG4MTezumy9TEtBjyneLcoCnErIzeku
6C6ha69AmuLyQH0e8A/K6EbFcfkxAfORQjmltLhpdnLx9vxwPj51Ojj4XW+y
7GTR2bq45E6jIwjJ9F4t7wCbh4gE8UAZxl9aMNADK6de5r87Pj+ep4FZdG7E
QfqKB5w55rrDjEAVa/gc0C6tyDClN/z9FCCXHklQFi4gB3MTuMynCINh6Avc
vOMMD2ld6Magy8J0sJjxw4seyezhQDEqfmwz2ruhp+6c1RziMB8cqTrs5Yez
rzegHQq5CBeD8Rr28dNcUI+lbwTSpjj62csqkmwe8cRYNJsWFQMWUTVs7G7c
EGCSnUXRQ9+qezdEvn+tjmqXEKiBVxXXPU+EgGKHxJteu33kq8Bh9OATXk7v
WeQcQSPSOHEi5RRqzla1+xaGdMiCQS/aSjbbKJNca33X2TTo+Y9SPB4u07z4
mR24tmUTg8YWBNsAC2o2KKFj2aFH7nUCTY65hpTi8yr4sAznCpKHu2BanHt8
7ZKCgHQMwydpxQmGPjvZ4vmyvrkwF7DGEsRbA6wdBJXgZwnja/Fy9ViNfEx9
Oc2ixB3cjaogfcWDCC0mfdiZtebXt+ETfygd6jTg3hpTUYIf8+GhxX2scOzx
FAG8OP4vIU2VyCX+hPxfP3XunbeksPG2IA3eoxGbPBqscuDxah22slXLvIep
UELu9tq9Zr9jVBbsIFR6Aseo9nj1gSV0d0XhxYnkCesVtMSINpAutECKkgBv
jI6s1DfqVA1W13AvJVtH+BTrEXj804D8kTNIvW5H7vzUo5NEC+bJbnEaBlKT
hePiVVzsTKJHy8PflTFkM8+L7zzeUbzLHIymiDrCfF0gC3E+Cd9gn/Z9rnNO
szN0Ou4RqD8NJozjr7KDYn41P9LQ/gQXN7fZTQ7nIIXXOzp02dn0+zzX7npr
VrIwReZ6uqkxlOsD4cTegfrzLmUqjIWaXK7zbsI3oQWSKn7nYE/MjW8YZU37
uocLUvDzTcxBG8aQPMs027TZriWitK7rj2C43dZoi4Gi1A0WKAiedGNwTnSN
RoFKiCFAR0vBwP8UIVD6BNEpz1VhQEniuuy+816pAw/0HawgIGJ3I25XCdXG
L80sNoC/Hy6g0zw8ZwAsc1owXs6tu5l8AXRiB4YHiEJ+GJgW9ehO7xJaJjg2
mgTr4kc2h3vua70lQJnvMFsrMSej8qGMQ7y9amTx6N7Jib++upZ4KJv3WPlB
kvvSxCE5E8mOcNyQt+cA98fn2pvOiXQOn10hUGgoh8ZkOHoMp5yZTrC7aC+z
NMkbzs/3SdUjBpfwqphx5zIIXBygZRKBL7ESFi+LN1hJHYq0phexkFyHCGCM
4ij19TiyDv3sKYZMMAv3V1pd4ChnhvUBcJsQY5/eHo4cuZygVkECzJ57uVXx
RBTkLzqYIi/M/gR+EMipSWETi2C3v1rYKRsRMRoUz8OuLaWsNbCH9SBihfkQ
qDDWq3w3HcyR/dw2npRzIUFB9j9ZCdFwifE6+yr7v1oN+zlNCCbNhvvUKQ3p
9lj+lRsZdekc8QoHba1pqZPX1WoDV7drUcbIWvj6ocAyGa3OhcROtPQpwq11
8+iDIk8ZzmCgxWFYgZJmNuL337sCSvwfblVwuNAIfjSmFsFGqV9X1WlcmXo9
JulhSq48a9A11QtpCu92opQZLORmu6eJMsal5Zzl8KaSfmJ/tt0WK5J2T30J
AUsP8FZKhpBl5ej7YyuW1OYhcUqyjhg1CB3GKINcLbvYrPC2g3XS+fMN1tWO
Dz85CpyCg8lVjc/F6aX8SCpONlnetD9gztESiIFf+4H+te+9mI40ATWR3rzZ
8Ivtstjsf1G2D3ZHHizJkaK4bH3NOWIHShOnF4NELiS16UjgkaS+rICUmIn6
ahop880FnJQe0HmH7mY5m5Z+MHO2l/TGCho/gn41kKPINImFilekt3CX7kba
Xjgw4Mph79kkP5LOb4bHM8ONdmC3yLY7n54sNyloPmYe85f8dRZXCe2lmuEz
ML4Q2MIo0iih0xA7Wr+08tAUDG3qYi5uuk0u0T7+XrYNLxMfW1JVh6ZNGmI0
etXYHXdzt4oySxL6pl6/Gtwj9H3LrcubItEprZBPjMnxjEHnRR8bx0nF/bRi
RRLjS5dbUEYX+fLjXd6szHXLVEzeWx34QUwvGEQsh4mxbDcx+ZKZR47NDqUC
qx3o4zzHbTS8BAdu+RWKq3O4TWxQczugG4gm9h/fvnkFaimpPs224lIX9QbP
ExOi59mxmGEIeZkOdHL1UrC1NCFCnARnBVpBF/ra6L1okfPkm1bSB8FaWk74
Gozv6DTo8+TRs4DooogJlvSTOOVydIBZfNBtJK/6psglPyUMjz/T41fTv3cj
8RTZHS91cWRqU8bRiq8AcdzwN9prb8XWqaVc/IjpeCXi8zAgmHxqxtvCVDKc
ngTpC1AotK7QFtjXAhT6eitSfc/mR2RQ6F8VmuWK9mTZETtso0yumxVDGAbR
52R0MF0ik0S6b3/+bS2Z4kr+uPCUac+BtOc51rHsx5HSSbjdxggkcgcmEide
RBfH9Di86WoAeqZG8kBCM3WrOfh7vml1zJC+mLzg/+GGmfqd2CUHjK/viwMb
DrVXu7UcFrvr8RCChCZCDgH+IHAqrleHJWcLA9nt9IYgVH+Kwltwsqg58kOl
YDN4l9D4C3fX/eoOPkAftxI5hiPnooKHG4Ja9nBpmjEWPlZYeUhTJtotYs/L
IbSO4A4IkMLN6DPNgTYc75YvYtbbYtIjOG2ZuadshHhMGeMAdsA1BgYlz62O
6t9Q+1POUraZR0PepxIZkjNwmoOqpWVl4ArJUiCPvAV0ou/fLj9RRRnjhKa0
pp8OvGz4gAf/I5Nm7ZHu6bZNvHao/jMmK3kLqZxFFb1KOVMhPQu7Dar4lJQ8
oIeMP0htEFZ+k90mvWmoaaMfITeaZbpZoHHJpBRvQ9wLSphIZ4Z5nXdN2QF/
iiBfAjj5ZHvls54vqY8uQbdeAZltGOGQVG8S10LoV26ykcuWkWaWzmCbrr8V
bqy/1/MG1eH45z7L3qrhRxM2aypb7qqvRJzyGusmjE6dHPaWTUiai02jN+ke
n5+GfX8S7X7q3biqOnnnSwKRZlnfhsRHNzquQ9KOzUBWhoZKR8QyUbmlJTEM
oDKmYLeqUXGpK3yM4tIRujvpJocsPqIu7qKeCSqLEDL4qHsgUd3dh3HGS5nx
wWQ56df2PLxnHZbsG5KV8PypOs7/0ITlOr59ffLH1/s3WiPAPJ/0El8mtaVa
Dmv24uQeuDvHzD1yCIlCLJk83ogwkZGChFPsiAv2W7psOheRFRzZk8j6tkH9
AYE4Ln1SNIEkJjlmuwgBmyPdu5Jl4J8tqroPnY6SZ9bVs4Ldbc1uw+4fZ259
U98hp5uKn85c1rHAHSWQ+cKkWtInxtJNsUeAu+FcUPS1XH4hRg2jA+kYhhut
R4ILi2MrPnVYeZJ335fDWhQ7KlRGbjAcED4F8tsi1vH1ZCCMV+PRuXyfLNkX
+QMnsvualsNSjyZN4JMs0Hg2CtOOr68xhdtghWahO7iAql9Fxd/22XZmZqKI
Q0jUlvAzSRwvb7O9VbzI3uRr0nc39PCfeRUSZ3yENwgaNQVL9EGKVi2MlFYd
NamZGiKGAqve0bGOZKBlSyyVBSNn8Twj1FMfh6tWN5Le5BKsxNcaBwsHIh6l
pAWhYhQecGhRaxf1SfU9gWCRhol7pBdDFXrxTJf05A+i1/XMZqAzzrEdWaOp
rFzuU22F8YQTAaVx6NLCEhGoh3hxK2XMSXexsB9sGlKnK6kQNA+bSDNJ3tj/
eY/qR7Twdb3BMZEvIIcfhApCEirwuU9aY4USm8yBajtj9gKYX+q6MVC2Z79o
pP/J7bW/GlhAg6191IIJLDg8BKcwLQtDEbjCzMbWGLaW1i/sxaSlIh8DecIw
PjaCwsC4DyVq0JWIhe0oHVqgJ6OYjCChA6uE1Wk1hTg7yt18Q2ORUakDKqxo
ne8cc+CI2aTFQk5RHeTs4twRu9sSIEPH0Gmv/ZMR8qEoC83jKZuoDU+zK+CT
d/muFbU55UUc8yX9AOsGojxF1yzmiOSwskArU9LDDSQeilfunt2L7qHzVxen
iSxgM5pjJgEOaiMAqWgbmkP64jqByiamY6y9Ig4k9jsatKOrQ7OldN4hhaGT
kL1eCIZkE1f1nljvb/CiuclIMsHayH01iynt6GGXbHuxh/cmZAyTaMhKsJTm
0KVrT0odp/Wes+O11HWksH2BF8Qi5WmFgahIhSSGoOJRzYQ+8r5ntHspKLAQ
ELqkraQRGLY7bB+9o9nch+K5xFgJefSyQxHJlNVwpjO54JmIHucSvinFsmNP
ClImZU1QloCH9kQQdKJ/FJeMcc7K7nNM/0bO3kUfFI6QTuOAv7GYRYXmUIuj
jigJUzrHmCo06QOwT8FgvkGMNGyB7frBp0/w79jVCaSp3AZOGMCRxOER/QH+
QHkrSkn4kV4PveiRHS76mnqeRVqz7u8lecIEjfiZm/u7KL7MAUmzvAH7anSN
Et0/+PRZur5DlSQeH8ytZRQhoaQ5+vlIn5ecUs/SrLfZR9rbZSqNB3x7gTe+
LKtS88koToqz5oAjWH1ErhYSZzETUYUXGTiDZVxjny01RQTokISFJrhzE/mT
r4pzL92gVzLYqdLKUwqVMpOSj5LF7OS8betlSe5AE/82UNmBOL+kS1FwLl7u
x90ZRah7KPkrUwIR0kQfmCRPoHcSfkZKUAsFmLmCRVr2rvdyhcmr0yZuHSFZ
KudpVbMucXdQBh/pL+rGOSaiIfwlMWf4P8agS+lBNVl7bUAOnEvggZNAh8EN
eEAjHtqQsf2HGPR+LuoMHGkHgPXxcLVU30IXG0l0Xd6UXXrpH/Tw1rWYAel1
ZwhuW8RjA3KoN+y/J5V2U+SS4iZGOjvyFP564Gohn1NuatvO3O9Y3AWnDB+S
FkiBpG3ZXscQHmkdS6vvJHmP6jdLrCOzU6wOIX58+TFs9CZg5SfVU8i1iZBI
thmd4PNqpBUwclfloC2KSJiy5hnRIh40UfUowat3XMkXx1UPYQ+Tk9QSYPCS
uhdx+P7TedMvWcLFdfYUt/OeToet8ZEfcgpHduXdrPZbu94p2m/fHU+e2nvR
e/vZ267eIKFf+XjX24ZeUlp/N+nmjcgL8nXhafXapUTKO+gR2WEiw7Rwn3LR
WETa2R7BwetrC7tkBwZQJpG9rK8q0FXSihNwA9ekVzjQ+ZzrqGMNEhbqzMrz
tu/ST+pYi7INlH/DAQa3o3obtb5ANEiQcLacXM0qW2+f4xOku02V8gX+wPYZ
2liwrECWwqjJaxlKLIxF7duHERohvAlR3h7Mj5cu/CtKP9pQPRzDfXuXSx84
ZyXWRq/7uPRaiAqjOJR4OH1YU79usUcst/5dtoaQufXUDWEieE/PvDJPgnp0
V4gWgPRkQTEbOl4pWys6ZPrxlSTueBADBtFOOUzRwOkskIZDBM0795xqqPco
0kbMW5NTl1wXi4NIgg4fttrpFWdqPUknSOuU+PZzuvjIXjYXxx3wOGcL9LFW
k7CnYMAgLbIdYXoaobJINcIRb1ji4RbZ2PcYc13indZeYbFQimemXKoARxbg
XrJ1vpapSZA3WlQqMyPONUvYczXbYC0nynqgzrjIMkbiGUK1ztuOwL5xhykJ
sAfnRY14/J5EpadPwa/hMlBl/fVuGsrO7HKu+EGF0AaFxRP2ySUvGGw+z/6s
Wnef+VjZcwNwHqTIzcMUf3kwEg4+HB51iPdJaihqErdrRuG5B63mOu9FvUXX
tnt/JNBJLU7BKEsv97pYYGHVlOhSgpevGklZjcj4PK0xjosMUes+lIpbEpEf
PzwvE4PL1OTq4m5Ho/TXPgMpXF98+bpFZoLe1nQOCp3m7lPSDcCfSapdjByQ
EG9Y11fq4WxjogvJH94WdFBd8jUb6K/yhBiLJQUVLvPGPGEBW71hikrdmguA
ov6sXVBw6dQimKbHu4idYUAYMI0cdFgKzfkjTAuPg+G+8EfAIMPim5oeEPuv
schI0OUx2VhR6lRztUKtBZQH1NYQZ7ijnigDcWOaA8UBbPM46Yxto96tm3oP
/pSJLJD/Vd6SosBctKEp1mIn1fsPmMtEJ6nLsagAUgjhPVqt6mhJxwdGRX/I
CFN8mKiccNuk3oRlrgSBmnyt+ZIMUJqm7KXHdclVWlRop7T+Ibr2BCR3mKXI
TVCpE8d1G7dW847R7mYocMJubfjgT8eaVkrLT/QCbbBkQEd72y/KmxQfIb9n
sWdgvEgCRuFSBNf1hptnunm52a9qRVD1ghxEkazUDtDRWUQ1WEXUxa4HgkYZ
Oc6qFC/CKKMZ8Pt1kd8S89lq2HMPUTN+TizDyQkDPUAOnFyuuxhmiUetvUuj
GgBM7KZIootwqeG/IcaEarAJx9ZMQahY43jo+G05yUej2sHFtC/z9rrkijnF
EM+6TrDh+cjQGYH1mo9YCqqFlcN6Yd/olrI2yqAqw7w6bjkiaWU/pxH+Ahoq
VtKbGfR1ZAOSSlmDCUphIXiZM565wQp+YDzCKaV/zqyxZlSzuNqEBNVGqp5a
0VOrbTriF5b+uq6siy8OE2J9UuzMoTVgyr4Wl7bo5HfEypG0AmIBuFKtQBNc
zu55Wk8mae4rlSva9KMaz1+RawZEkH3Op6mhkLTMG9eFLimx5TKAy8uMeDiH
BfQbVt06jcmwuAz9gGKbmdOJYBhdFKqjoSyFQFinMZtlbkUWxOs3TfMU8cj6
qB2OKdhovsBSUwxf5+FtEApkw1pgjDVlpNNglMQqBmUYmAUeF2SNsTx2xJ9I
eakR0+jTsOJE1jw2+hukFyQdB2VljUCRYxWtoWWY5oeMolLYw+G2IIT3dVeo
d7F/XA6pDBMiq9KVTDNswJAqVA8Mg5J30ZfPtlksw8nr5BberhgnXFQQH2Dx
ICbKUHJSDscrTvfUkUuWCYJqXRgkK3fpkZJwmWDMlIxdIwusioy9zUoraCXM
J3DuSpvyo5rzj5RaxhvexghHU3DKklHIcmcdL6YhJvPLrdQR1GnMaIvYP9dy
RO13I70Bta6PxfON02YYoJLfzuzDP4Xw5rJXfyuCAcoIjhKO6ZAarnJdRG9I
V1dTgbGY639tLePI1bF2hUO585mWtI+f1zrGlBS7hTHWaJ56LTmpx0edHGA1
ZUe1xnoloklNGn5kGpIFZLKAu7zs+JOYrQoaDMiAJw8lk1k8zqArbwg9VCrg
k5soCIdFiz0DVlwxD+CCktzFfLwXoK++Zo66ETdjKC9jbJzy+bma7zW2/CU3
XSrYYsOItqgGV8oCxlh2lBbg25TqiZFMSCnD9rKkLU/KhGqlLbHNnN+n5w6T
rediExeWMpLW5cLDE8LpYS6plQva3oJFpfiIwHSOpHiwlX9jSBd85zT+XjJU
SK0oyJzU6l5xhm4mfkSt2ZksD3ZRN4I9Iaq2MiI8XZfFJ8mx6Mb2W0NUqVyF
97NsYhLPVPxI9i7VCmpIkLml0O4Mjt5hwvT9GHuKeAbxTjCCbhIVBeSw2u4e
cXXqd4m56uQa80OW1bjjfF1+LDRsHd6kgCmpAVRTa8ker3Jo7n4x4ciUyi45
OTtzuB7ozbJGmwR2RRqIVaf3jF8iGcnxWslK35bwF5zytHfG1HWb2m4gao8S
haahoCNi3kllmDb1HfBvBttoMHRRAxcoqJdBdJX2qqyy4cUPEfviinHXivrD
E6GiWXaKG6yoy2XQwfaH39yImRT/gAzYl3wnb8dl2bROhSOW7Aufs2JEsRU0
tkyPgp1ZlUuOAdERidPYFbJSZsSI6qgXixzaWQ6YYgwirRmp9wurh54jcIzO
zSHtmbUCLlDKcF1Zvi9kAS+7YGtwnGJEffdtqdtsKD+pIvloKwVdEfM1/FIg
7xl6Y0B0ibrqihV2e/jrXgoNCQfg74zefwzYnDuFkqMC5LOLKK9otSV6j5tI
uvrg6ofe1GCkdlEWPxVtyLGDRw8Ha3KiKIwoS/Fc4x9jn2GY/Q3GFw9u6WMP
MCXz+SGRc++KB696FrFhzQgbwZiXCMW+IgUyVNaPTCDkwgNc8y++w75LNHuN
LF1NikMhM8MTeRr1wLZfK9+VIiKspiBSMySVm+2NL50KX+eWNXm2Rp2+CVbL
Ef8yjQmej5NqmpS/TxUBTf21AkK6BGo6TqU+yC1OFEpc7XEqdrWeaxzpKkcU
z6Dc3S0a46j+bRvplAt7JjwJGXQcFb10YDrNTl5xrTL0/uIPGtTQj+2k6iV3
HFSjDO19ue64CfO0rt2xP5mk03kk6R4AEvFxQ/X8J1fivoDjIbD3tuJHW+xp
6iuBaa8DmUVKH5INCjJ5rdEq1hiZrYfxt8gKWWOrMTR6CCKWrzHYQT2oL12R
QoqctFrJUMhpYDWOfUWnhi3kbxm5JRw99AZnDVvyk7Ew5IYTMfn64C/gWE9V
Win3yjP0SSEHPPBbdzgYnTDkkv4PdxcPITrZRmfOh5/U2ApLLLLKsmt0T6dO
sYr5qsBIs4uLt9llWSDyly6lKHLBZLJpgTk2PHQwKnco3jRY1sB+lt08+4DH
yH5hl/hFgp2mqsoEUHkptViX7PDOowwhVT93F8RZA3Fbtaww32qc6xJTIqSQ
hksJc8yJSzebf1PRJ1FieAVCuCRZ2GS6sJ6jeTUMFB+jZc3eyLmPuHVuiAtZ
CXSIsMaMFUBeonEdZ3jyorylhAz20eNoI4rgkasmySC+IYPvVrnYZWPHguyX
g7bO+ERGiXxg1eR3pnmNLlhWiCYB1+RuYv92tDU5Dq1HHY9QL3e6OUkJUjHX
FkXXFfv22yKlEk1PGIeftRVkJlEYLvPWDxp5Jt3PRZHeNyQUkkvWS2tKPvjt
5gEVzl/swuA73OuFS8UmZ7LYxf1giNFuZHHM1smzxyzLeh7RdyU5xxqDyDg1
ooDxIObZOTIAqS0uL1GcWS03lD3iU9DANDeP6CGyvDrIneHo6iCF1M5V097j
FnKu1U+fUeJE4h36tkKXKihgfD/NJHYeeYy0EfB8Xd9NLZdLbim79jWuFVjk
bTp1ceyRenNsDRm9mYU2Jkw0x/ALVFh2paHLTirIaQuSmHNGWZAt1fCkPV7k
a+yziNLCEM9Rxz5Udd6qiHm3f/RIuWRWDOX2vyq7g75PLP+/VyM2DdXpa/T9
JH0Xn7L5mB/RxSBRakZWgQ65ZZF+ibh2s4uG8DUsuGBbeIntj+gCFHcOR4I/
DVYrgUlG3BYr7Cm5rdguwWACIsfjosZHkItTt/HqeGcQhSS2XairMT+Vd8Ay
pizRlhBKDz/Dx7mqiARqp2Jd58GxO9IZ+55EttpdDozaLB/LjcaonY2oEnxs
pjFXeD/N0OVzSZcovsACaqpkWcxT3dIsJuX8KFaQccy7FzeC9k0NEc6UJJtW
J5N+9YH/YFheF6AfjljLdo998lArgphLK2hG4CanWkYEiwBaDN6daIndaISB
8afP5mSOddvGXF2im6dV6BHCBCZ5zU14alYZKidanUs7vil7wQVGMe0BDTpH
RGxZiWEaHr2w0ebZt+l5xOw+vFPlrSk5uKFkreiCWkGuIcsczKRryqurQhAR
vSPHc8J6HkTNZae+Gia2R3FqIbxNed0vNUfgk+8/XGRnr199ePfu9fuT1ydU
4rYdEKveQ0z6lIsdH+oxWq7BTpERPhdRyAVxgfVQqQEanpa5nXFF+rG6Cj61
YVXcMg7jAnj/bV2uOCodOaATIqIMelmCNJAGQrSdtr90WCdr0lr6yfVkrIhx
iAptVPt7G/3N2Z9fvsCefgb7sxJpTj389OnN7GReFt3lbAFbMytuN9UMNaXZ
6nKGqGvOqpqrHyZKLZGO6RFRWWPETlDloJrBHrjRHrzSE4jTxLxnXItDJaBj
70oKc2FMvtBIIDW52d6E/Ib8Uv1QeXSBepnWrzUSV2ULCbYQROqJjgPMpVPu
Jj6CmxzhPhyVH9NTP33mf55tbISfEt9c1AZ6UjxfUyaqtUw20WmuVM0+j2EI
7xS35/qA+6QNYyFlVyO6xQHNgoabnepzVYPyk4SSp9zVWIRq3HcpHez6LsoS
ApV0IkteKlLoXDXlCynvBpVDw6SaLUeW92Z4HEXT1HTysa2ZndAeL8SdlosW
HC1Ve5NdLSX2u0bPeGZlk5XodO+tGgg3Y1DnVA7nkX8cm2akmmQuQRlbVDmN
nTDmIG2UkwC+ndO67dCYMU+80ox45DEeXLIZQoicupqNz4dKI5aUWsc3Pv84
VT0kORlKxO/YgFKzjTYLE7xJAsi6ySm+52PS6ycdunUiEkgSKLoQU4E/E/qP
X6o8r3IghTvE3mDO9GoUK8BAogQC4j3NKa7IF/r/zL+2S/AODg0nNs9PGN50
TxMzLBGLIsc8AFRQuCZWoKZNIp4KJOIG6oex0AEMV5dZve8Lr5Fq6nmpbm64
JwoVH4NmpCiwn81wDhFfcpHqYrQY3wYz8Vg73zle8a4dXVUs3Tdac08Tsue9
nR5GPDY5yijRhEi5Sup7WyYYggGu8wSi4JVF1+KuFq1qX6s7j34L1icy2QaR
cVx1LE/RUf00+MueqhscCKswI97XXKWI51jPzc614BPnoeBtgqRceLqeWLcQ
F5OezLNzv/B0wFj7rqeejzZVpXOO5RiGIRV8ACnYR172NxL5DTQcMVJARyOr
9S1ERUwyV3G6ouAB8tUqGHjIUpWoc5GjlF7nMq7PEwskSMMyOmLGc3PIMkXc
aTszdcMoZX4gjB4NjIn82G9XZqnFuF2CpGiXRR/Y4gsUJWjKkKCXuBpQ4pEy
wJ3WX4oJ8eg2xvwbtRRxesAsV/SHWVTUSEWi476nLsRGJBDnCPEYXtmbDKxq
jqi2ztvgbrktOAg0wLXSuIf1co6kMDnt8sMDpO4jCbdFDQ1jxJgYA4YEG9/m
JbGpfD6uXGK1YXIUW9lrV/jLX3jX+oahYTwxpyUexNDklHvoVNQ1+3CepW1L
08bD2IeZxmLfqvsm8lnchya/pG5utdjpPMznCQyI8FMrv25K12XLKeWzSER/
joWN+er3T9yomU++y9uPrmOk6yA/GJ7MzSQXKSlIvS4uO98GceAOKn60tHAT
s3byvKPUFHlcEeXieOo6jNYuZljf84ZjLTNloMJ7tHSBU75TxDFdLt14iute
1N5BLHPGKYuckwQnK4erE0q6lLja08Pj4Zo7tWbBjnxr0Os1sxxizecQ7L1m
zPlCgsz2gEMpV0/IoS36FhZXBujPoC/f6Yxv8o1klHDCDiMFHj0Mo9TU/mLH
x8Z36dTUyq9wzMjOo1dd2CV+c2bf/EmavBV9BonmazbpT1AH288dHd/rn0eQ
eD+zMnS/j+0Xdw1W1trG3h6mC7Z9VIcwyLRvuNTo1UvndYd06oOldL4B+x6m
7JhgfRnshoxJBON1mHCeL/vhMessprCBiGXh0hzyTcIMUI2Y9j6JkuVWqwML
LLPDdXCb6MqOrNr4tNu2kes/ZIDMC3KKPnPsnspmkEuRc0I933YiQOvoi1+X
C7CNE10UBz5prnd4wrrUTZwEMZDDuZX0MjR+6bXDveNOxaCHrXtagAsfZ0MH
pNPh9i7yhquAg1JZ4RE2heTevRJPLx8ttUPkE5ZtH2X0dOEGEYuAWgP1sFxR
6oyRXtm2VPu2kjQ5rw0wDJekAiLjokvcNVOKjmEr157GG4fuy+iz1vruiQpS
7HO/aLmkN33LRptwwRIY+4xee/bl66yDqycrJG7lG/wcZXfwxpEvpHGRJ/PL
l9rjYFv5GtOLBn04dXVV91AGUo2FMAQo8iimJPOiBDfL8pFZxzQNdic5d5q3
1076d5xZOCZZBC5UCiPrSgmN4vMlLG2YfDIs97XO3j3cJijOJfJrHIvjVJTq
y77mXrzL3G0EuVCumMuH/UVijFe8Sf329rn6jdAtIZKZ8zi0MiTdozKJzcTi
LDG5WGUzbIMr8GetXEZm5pEyblrmSZJAjgtwkHdyXaMA4Lhj9N9wwnFHufkd
J3UwBSU5Pwpq4xiM8o6PRbFp/RlipoDl9iIsARF0XLjCwgqtYkNxrTExy7Fh
YBz1ulyiJbsuVw6daAm4/eZkg0C26RT3cjw+trAv8KwvWAzvXun3PxqJ5mjz
PeHo3mz/ezFpC/r0Uhd6G6nR52w8+hz+/xF9lu2aacATmQ5dcXwJtnh0QFmD
2lTPfbDxM4nMoG8g7aLJyDRSl2uXXd8Gl9uWabs5qYnqddIBs+/fiyDY3UQM
oXeFkK54BdiZtd99QdJ6IYnl/paFvkHfUzP7IjTqz3x/YggnDJaxgLM5yvoA
Ntd/Q8i+/2LwuJaRt3vMc/Bdwx+8r33VaTUZjGi84mBZJDn7LHzwdlWE0oVE
kqhVySLptx9zHx3BdSF640Rmum+xZJ9SHQh/uAL4/fbk9PezL//t9C8g6vIV
XxeUvTioFFazmnmwa/08VErCV6t4JdrPbZkHZ7spO7XiQ/p84pFH9LJ5sq0r
xVHAqlT3rs7sqD3+JlYfcRh60i0Vhx2S5nDro/vMwUSi7ImfmrODc9drZ66Q
VY/ESwwESqakuqjGH2KVyclGGUty/+i6SskZQ0aTFK76PXUEWKN61TQqZSti
wYweUa3FJ3HE9Ntz6XfLsrhyc4hAVckgZSr1Xv2gwTedgvZPiw4x50KK+xIz
DcqYxlusAi6bQB6YViX9CHhq0/E5ihypHPkyEDL0QZulbwKhxygdexiTyomz
fBQhZUEHyNbSLvFW6z5vOVlAxj40WLelLoPUnoaIZB3BZMyjA31seRo5FhWf
ePEgKc4H64OUgY9uAkJtU+n+GNDplRjO9+BhRSclB4eQvDS9iq3jjSe4UyK3
l2VcaOEEr66hq3a2rrkJkl1KMpQEf2nLtXrpuhBrI+gFRyyH9/PrSgsHOElP
Qt03Iei1q5C6uFWdXAWLQ+/zkzncD+5oLV1TyfFLyez1essKbeMDygfwzmWJ
PYp7zRI89K1EC5gpWuIl6EjAtDhVhVwIW+hAar6wj0erYxqkg25iFssIIuTm
R1CY1rmErLV7mFYqK368BlbVETFz0wMegnzXWrBAq1u5SkNpkFChRjflj9ye
XoNwxjqYRWTIIe5KbA7Wa1HSD3xJB6bgGg/graVw9TAOZ1Mrq8h5uNs7GXJB
a/AMY2VJ12Wjypn4ibkfuJRVCxw76NcZKKrbEmzeGOmO2897yXV+KHWxqEIs
JSmZbgTU5pwjBhe1/WleYo9a90Wtq4UswxeubgbFfmgwUi1w9SS10kc0/9WN
zrXKOPfKu/vHkxyApg6KHzskhfXuMMHFWUGOgY+Sr5bk4ZSVV2p9Ga7r8rLj
SPFi26wKOq+eu3KVADJcvhPVaxbOyxNBh1Lowacd3yMa9okfvpcE92bQyi/a
NL2fbhQ6xvjvc/+5RdPBuHWzve1IqZ1qYwMsE+eKTgAps7uCLjAn0SovJZso
GvHTWEaDcpnzneLo7oQDRPWXKHGTQh7ILFCrFoktgaxgRe76irs6IJ/J2xJX
7keFVb2+JUvXSY9p9jMalLVf42ZuCeknagyzZsrVk03XhL15lgLR2LFqQiue
DmNB0X0WNO14anU3yqWyvnwNO1jlaQTSMT6PnqTUPpCgpspSkqAlNcNoWFWl
1fouQ+2u1+As6IBJ1qG5R30LLFtgCnzuKOGO0FjMcGCjvUpktwmZPIkfOOyS
CkjYHTaXqEea+IJqOkBSA2N84xR7ynlPkgEXYYlU4OFO8Xx7KEXUTRYmP0dQ
lMmDBQK2zYIl/b3SB8H+3jeRlAHPm4GaVPZPosKPJubdz81Q1cvcIVF7xrNF
3PkOkM7u2qvyhUmqEpSt33OUh1RUpbccUg4D62/qWY2u++gK9aPRCknasa0x
9VSR6MK0urLlC9puS01Foy3iDmTcREwa8RHvznCdqkToLmufF6n3gCsvuqQa
Dl7mSH4ap0CtMxqnFJokHkKDa4Jj4m9n3MxraQjFUHfy3Fa9gtkh7PXjtA6Q
sPklXUi4RhQw0fUu0AkYLDs2VNlY9VrYTmR7PJ1cXM+5BKW19HRN3VbmQQsa
UslSPmiRA7HcmURi+6FfrkbqrA9KCd7kZeN7CEg4U7q+MCYWtVVV9rnh4QMu
QnqUHae3oKtDtIXJkdT/O61I7Z77fMR7LCHOll5yNoQ+s0d1oEL7e6xiZGjG
LPtpfrJZJJFzgacjSmu9LqorrKzWyxtkP8YNnq4V9dq7AAsReknTDxdy6J1L
20lLOl/WmuIt8vUQP35V1FdNvrnWwnSbhrznGMIoO9dnpqQuN0UDCgvyXMy3
3GLxiXyNTY4W23K9kngY/FZYq1do5tnJlvZUi1cv8CdpMYrfoM9Ns3F5p4oT
YpO1sCC3GK46LnaZI/4perU8JhDFoock4FK4EIN8FjnUdXlF/VPasmF/OflY
HNfHGRDcbtu0GKRhLgLbgVnk8KFFuS7GKwSIzJ9yyXrukAYbPKsvZwsuRgJa
DFqt1O4EjBIuVEw+FUQATjUrgUsA4ITJTXFFaDSyjLRk6B1QyQz0xHwwE0wW
L7uogDapN1luGSdnIHoWbsvfva4kJhWYBuluckkTyUWV0X3uUov+cdfAqkyz
cXsFAJgWAubx8DqL8cnEBk1pibxY/eTuuoZfpNQdHHXL/njVhqO9rt0TaCWd
lRPDC02WPOhk+EF0W5pzp7caIkRXD4bTZaVDVbzBMS3s0cOH+z0fvDdcBTPV
PZjiRbw90CCE08EIxRXYXyj8x2Ga7mU7pDpa6zgMiVELeLshXFXO01BitiYC
YhSO6+BbKCkwFMf5Uww9SzR4WDYVbBqv6dCqpBJoPyqyN2g5YQNAqk8D1tlx
tVtirEhgjVpvwNVrp/aQbPTvoTpcA6YpBXNxlZuIk4zch0bCZdBwGigwQNNw
BZx4cOJpmVn4qagunz5bNO3HUrLbfmKZlnTFkdKDISS/7fW+HXQwdVGJitwV
yu/7VTPnQafisC5pF54kS6FkCKz1kFxEfYAVhZH6/NbrSXQ/GJbbZFBDeX9z
CCRSYYGpuin/nuayjswz2ZJkmlJXKd0X9DPdwF+mosWB4vBxxnyPKIx1Knk1
via9X/tPT22T3x3/pf9h/BQ1/Tw/mZ2fnWJmHn0zWFm99LxwW+A5zilqkq4X
EcmKTlhtkaOzxP5tJPWpnNgFAR/lb6lHtLGkJ5DZ54n7sle/M9rly9jhg6lH
HwrUIRuZTb4qa2yzeB3dy+I7FXefFjSPXdtLYFN3VTo93IiGXWWoG2Oij6w7
CmXVmpQQkgOX9EF/0/AM+HOyIQPdTsNJMuAwjWRsSBls0dR3Lakr6okftJGm
agygUIVtZf4dpZmaW6MWlByHXNY/QWYPVSUhy2GauRJupQK0CnP4W51f15Nk
u6gK8eSJNYSUPwct3eGGXI1QvHtYZhIzrmRlYrNzGZhYP0Y1djhDbjSSs8rU
YkhgPRNB5AtRkikmn5XiD4SBMCaTSYWisgsHsRRaPn5gh4ZA3Fe0FbSu4Snh
VyfMbI3zT7LTi7PULKGmcbEZCfF4AhGBfrjkrLVmJWh53pxYjVL5S3ZAJ4Ji
6XCauPoi70rZORXB1m0Xc5aMoF5liGmiutA+iXYOo+NeP5CWMeQEvoiSF83E
T59wcsDQ0wYMsXC2u2dH2aSXfm/hr3VOPfCCwZIImS2FxmJ6Lp2wobCIRW1B
0UKMpzwbC1izGdNxjQ4gkscPZ1gF56adTwJ2IERHpIQtfNJ4V2shXZXBOjJN
EjMpxdRu76QGqB0M1egJl+uaatjDCUoPbpFi+5sRMybePmibsG1aK3KYzTgn
mnC1FsCvO+OCovPb2FNvj7kSlvEqqkOl1axQvVFTDyQj+0GzqmurEIgr1yXK
9Q3Du5Deg4pJ2cAaYwnFvTHxkMBsWhexjrWAA1AMWwRW5BqFePH+nZ3JAGWb
zsGlFwDpkJYXxWtIxKtUSLKP5NSPRpMEYrRtxMAXIXBxT73raDv0HD8epK53
HLmANNTEddNpBhcAoYILS8wBEqOJazxHGOkKOxSvbE+mUiLfBoguJfLQYl3w
QCE0B7WBdbSaoIb7J4mT/bRK8ahb/0+jN7jA8or2rnGJerrAs5Ps4NPZ169e
Pvri+U8/AatjhKczHVDbmQ0UHX2ZlR3WusQMcAabQkFpaRpYv4HRcX5CB4S/
UwvCunxjkYNi+bFouhnQ6U0+A1ux3cxWVduuQBMLCYjThUD96uVCJVRiPqde
3yYCoXHsdpS6tGwy3Vpf1p5VmAXHniijiMAxXnZqPYcQ/il7zYfO+aNav93R
uC8KV8TfAz1gQjVaj+jUAX3lsruj4nCii6IPIUuhrW2+LjgN/0r8TOgKKCip
jN+ew4SOfYzBsSH7AvdKTXX8hXZE0QYi6D8n91rH4sDshDcnxe2bE7ybaq9i
vYzltoVpw4UjOflRoe+sfjg7mOIMGA0QxJGsyLZ2qv3JGV2+AL0N5/PgP87o
/63llo7Ca5EIDbMq90GtuCGb36eDoD5PYxemEdHX87726B0YqEd7uX+AHptt
hfWO17tDxEoShz9YbSm61RWHmfRKDFbRulf+BsWYr7ibriYRR6mOgDZbexTC
I1QlgU9tqf9Sg2U4KY06lsDlXVsTPkOwoNQYPtETW+fbuZmHx8DH73yHCv+F
VoboT1pVznaTLwuWm7rKouKWwe5id0lxv+SeCthuxJyLqKiU+YumCtIJROH4
oFZBr4iZJ7y9y3XeXhOmgdpHsMmDmD5ch/io00NR4DPx2cd9L1XyWVDg/vZ7
bSuqf6H+ol9mB48PJ9MwzJ7hxYKCeMyz+THDy9eHI7pMO84cBoPvVrTQS6A/
djGZtoIHcITcy6szcA732WQ6gMmc6dC4ivVxMNSQaQEVar+IcXiMhzc1tpM6
zK62VtTS5G3O+89YB3khyQg5hLnlzfIaxqa8+Hu3c84L1EHJqdf6HAUiR0Oi
E/V62mYhT0qjeFJ7C4ZZEEMwqDTXoWs6QQZQIMNZGmk2Ms3Kh0lSuofBxYeM
u86NCSoKEHpR1KX9Uc2SjfEhrewnhfaYbuF50c70yJC64JPeqPUMP4KXtQhT
dgAEM+Qt6IQAreM6X/VZAoyul0YTQ7pmS92GQBaD6Q0UzXoeCRv61p2ybhzm
oJjDrFnFx8ror479O4euzhJzYXfJUe7tP+g5TO21HDNJPd4+XTkVbsWZjHWk
ZdbFe0Ih2PV0D6loSlXnY/ixBGvS3HRZWCECp0HCFFfeK7TBtoT5DSaaMKoF
7j3YUnSz/0TPikPGIp+5ttKSHm5lVJG1INzo3ScEepZQXt7XM0wH0B6YjAWC
ubAHbA8nVnVL+LXr4Cn7L8Mlco0C6Vnf2+vJad7vQOVsRkbpSu2aYkX71fM3
sR6UflRmaLqHrsPvCsvmssHJbRc/oL1TxSvwnuh/DmwdNPRnj188BL6OOpTk
x+JC/vPZ44fn/uHh3MTjberO+6F3h6JCXOOfmI6YJjkVuqUGkdn965C+adnm
etdSmSh0NcUOmPF8TS1xI5IjkvZvIDAz0lpTrY5bGhAp7Wk1j7dneB1M++3r
xXNXZNTFntdouaj9SNIJnbdpNlZ2gOkC3ZiZSSmaW0IQN2X7kdtFoPp5+L+G
Z2Sx2ft0m0H7PRYo8HifCjRPD1h4rqAPBddb6L93SXCFxGe3rS+aUsJVWZRX
25xCftKYl7uIjCl4EVyBJN0nZWEnPh7TEVoW+G95XXNFxj32F2tayHOT7zFX
0JLOuDh/BVAP9Brn6NAsNEqpQq+uE/7VMfwHFe/j7OxMbcfXbAWpv2EAFEbb
XsOIie5rOldEoPRqYrGyny+ABMGu//TJN5WfyaDo/bum47n2dWEojKB9pVxf
CnZ3tiFBKnFvOb+PE1kVqEHhf8N/4PiyDCyEd/6hzXaxBilG49vlP6JH6X/w
jUfKiPdJ63n6/GN9Hok4K1doIpn7huglP5KHs+wr1EuO7AQy+8+H7A+66XPY
0WlKdn/IJqdvTo4Qib6e/R7++WV2/v7o9+fvv5y4MX4H427WeeVWpX84fw9j
8A3L3otWAsPAL0+Fib2RidNFii/ivD40VyBJ/s45Jsnan+ghmRvivLfg3ydX
u2i+nLtVxsHA6JI9yU63oPAi6OQDtfjgmwAfsPPSsdO9nBJOf32UPXzx6NlU
1nqU/fntyemrx48efXH88mX83JP5YOLc71Mn7rYbx8Pd9iP5RUzisE9tWPMn
mj/igO8Mx/6uI/+YUzjvUD/8O3VHJn3kImzIjagAOosv2BCkOFrd7oGTABkN
O3AQuLO6JecAv/u9DwXPv++WG55flr15jzOzc033529/6+/Q3/6mewT/gl2a
7xvZExTQ6Rl3sbj4zwu/h6N8L/xPzAT/A0s9P/tT9ih79NuX60f8H5kh7tBk
ku4eMXtt+0JG8dbVwLAUAxMTv3V+g8nQhy9X+ZOjL17mz48unxfF0UP4z9HR
w8fwv/TP50/pX/mjOOdn7tbLNWdW6m2jAafmtX5Nv6SA8LX4IpHsj9DnWLXt
tT16znrp0T0cdeyKT6aRDw6Y8ytkp/FdFjifjrLPxuRd1pXduvjD57pUWSOS
uYugf/6TVghhGPFIDz0Sq7Zjm5KE2nTotwuDumUU3m0ZT06q0Zy8Z1wUlnya
HBTowTHpqz8vQLODR/ND2i7y9ovfhE4FYaHoIhULlcz63LKLSJVOllozeAMr
qMJwC+TwrRSeQymF8wZRccwp2soINyoxqNulYABNk49YApoiL1TQ/W6ZPbHT
n5Xn5I9ltWST1IPHuwItnJLcpwJ8fZeoUSS4cBams8hw8rQuSyQz0Vn2Nxb7
+BaS3CTT1p6JVIfHQCnA0SYJMcO+PSHQzLquP4IOvfG+jv2KCy2dTiHOlfI1
4APkSCWuQmlgXcGldT3PjteNnQqW1aG7juNYlCPuoNToJcLH3aYxP0x1D3A6
tM7Uo8B7WAwke2K/ZQdP5tRvO/eWoCGZ1DZhLUPepP1JlsMrTQc2SuqrS96I
GTHuub/i4E1r2X61rhfMbTEWKoNNvAIydSWduaomC37bAbSgqfIfm/R0U6X7
gydMIJKnRCQdBz0L6lOERXpWHlNEMVkskFOKW0st42gVyNP4oTOFLZyxHp8d
nJ0dKneoQGUK4Rn29VlSXNFVf7Kwduwhyl4nsKTKG6nPuvB1aPR+Y7Rw23JD
+V4k8BqJXEg8xpBhIKlXQntDqJL2utykQSAD5H4sdtS6JbXetX8wBQw1PVBI
UpnSxdtz0v3aa/RpWGmWUpohaFXLogVVeZU6hOJVEeQH3TGsxE9JC3rk/Arc
Iy6wicMhy17ipN1IGsRPmDvfN7CADmMrNzKCzG9dtnZdW3WS8d96FK0T/OBc
Iu8tLEaXzYl4mi4OdSeV3Myd4Fta8u1/wDffswjj/56H4HC8ILjwthxCGw3W
RFdmRSixeJ85VQiHQZ4ppXHI72hVYJjg2R9DlLvp0uhe4ic0vCJl8GOufrEK
/3H24Ku8IbcQ8Lizr2cX+dVQ+mNFipzq/nMmHl8T+jiQqVXmCB7DCLPcoF11
jl/SjhQ8SOL5cuKZ/u08QOZ7Cq57ga//NPBk0N2rYY5VrKXkGtsG/2WN770+
fj979ATdZEtJ979QhAN1SsNCRR7ryQUtFLkQ9xc/baHY1JnKRxp89SUjGv2Q
q+6jgcmaKXMQF9h74uGAd/3w5xZBuRxpu4KL/n7i46QwGbZO9KFt0qg0dQOD
DBmejI3kLl2A1Zec6jsMa/DxLGY4OWCRo3V88e9pSMIED+HZqyv+hE0p4QLs
nRRjNPWF97kDjTINGHDWvlKi07Na0Y6xFFeZQnKdVPilik6KV/hw6CUwjc71
9imWgbg2FL4OScBtXbadh0CKwsSOPWIydOG5DEtsRJDqR0RBXEKM/QL6yTXI
pYL6SFWxW6NdR20aYGFOLW0kaUIt71vHFUU5z8XSAJ2LgWEcvDCO9niV++ta
OxZY1r2XnZbskFKd+ZRdQDNoOVcqP56oRnoOiWqjFKW/yz7ccWfw4F9lhClX
rTf9c9wzhST3A90XOZFwl+9ck+Ftm19J4p5QZX+AGXUPBEaZ6E4hv8JceuvZ
6yLUwgvOznxALRYVjaBUqTeSOmtQYE/YIzGBMYAScLAJu2PwN/gQ51fnazbA
2Pnds1q6OjgksVo+A4iqxRQjmTCftUzH3gx9FIa7MMT68h5oG4fIfHIvhyIU
TsiGrNqxsnFl6qKjwDnX851pg0X8SnR+CzvQXQuwR6m/fkQjn4gXg/eYPquE
ooW/p1bgz8GXqYMG3HHq6uH87x1lwqvH/c/F4hTul4rCuCIiKVpmH4FX1YqN
6l83y2QZ1JwIadBwj/+a2DRfeMJ8VaQ++LLHwWnKrluVJVqNfdtHqgxxxOtr
JQdiNN4iSj1zS51YQM69Efy/APFo2bh5iggHhQ215KTGw06CxlzCQisUxjQQ
y13BGa7XgsskCAknz8lJ+b1TjWRv9J7DYtkBVypmsajldPty7FDyoUkhVWYo
bpGRbzsNn/NX0fYiqB/XtE1gmCrZGALG9qPl+rL+EsOXk3+al7j3q8SXPc+O
hcaptAeiz6MjoHOXMcTLSEuZ/O33fxv6+pG9EEAFbFRvfZEO6lBpJsKZmeBo
g7GGs/0S3RofFiiT2VSWDYx7JrMue5dBfk3Nb9arJdq3zBJkMgKHGzsPcRUQ
4jUrLi+1sFtC07XC8yhaCJPEDKw/xZoy1j+NmzaC2kvQd+q6k16VMQw4sxTm
3FKo6FxH7KMAKFWnlKIujFOvyS7m7e9Ku76GZlVPQt/iJ6wWJ/7ARkWkliRv
IkfGZx1KeoC57KcTRRmjYZNRZ0EYZDLBln5VWBPhNI6oNWxQj0djoMZ6W/KB
qcQsXdbPIFteYPJX2xzUuK7A/GqYMrESydh3mHBtG/+hQg1vpWobTiyFi/OX
GWjDMSARJo1WbgnYBV6gxQraIul5V7t6CGNB1+EaXP6jdDzltGzfmEhRNWkZ
qexBL2erjW1+It1agp2r0ASLClQY1JbNKgamlJUq7l0dCVli7N7FAE3J9RAf
wgB5Hw50UExriSJnAHeJhRq51QXZcNZ54qDgBvbWhY8oHERGTIAT0LvbMrPf
aHtJ4UuLYh5Idtuhahikd2tJHILOV8EtBkQql4XOkX+scBd2afGcg3cXbw4z
Kfml5pJNepHegTvqLY/ZK2lVe9c8RujVCvi7km0u/c2tWT+dluXqV6SALQ+9
rBgrcCQ7m0Bak8ss5QnXjHAhqxsPGuR8+pgVkWV7g6M9pSsua2p1msX4gAqo
ccU8Phet7xZZ8jlLs9fKiz99Zts3Y0k3Uz79Uwj99xyq8s3x+2NLbYAFgI40
iyeBi6VG34w6zy1H7N+LHeMlQx6dy49Ui9iDU201TOocAtd4u5BHm1iBgSYf
i93EOzjwF394BOLTQHTMnxK/tgxecn+GWOL478ANM3a6k3LK+wNUQdlaZNZz
w2ypzw3/t3Y331WWYeAUFZ7D2ijHru6auSyIbW5USrFS0xSxEprYGAhI3amF
MJkI2lMuDFlE8OV0O3WHphI34t2hW+FqC7lScDw49xhjpK9mHl9azu7cU4fs
jAOzULF2dlW2WAOGPpGnvfZUpnDSWe9aoVfNilFycXcarz9N91FRX4VRDB/0
SiSVD3d7RPlrGpjaoRO51S6LVDIjVi0PL1HBbUAFwhAXVo2JZ4B2FOulclqO
7UjQiB05sEAsTM5yrwYNPcMSJ8DvxXMtJAmzbGtE0O2Y4PU+D5Ji8GC/QaMM
VeaWOs44MKpmwlmR8EHVFyRkUDo57a+Mrdd8q7BWK39yd6XW1WWzIpUHVoyT
C3EeUsDV28GepB25UCboKOiLEXIVIRUiYoLiEoml8+lTkt3/0yieIiji3VWi
yLhZFGKmqZNKP8qcpFbHMjuoDOI9kwJCMDMuzhN4LFDl0dLCxF/YRtSYnfKp
N/Io+5YyS7RIBNJuM6PCCaCwyMPwuxllgkxFjUIhVJGYbVJzlhGkeN9iAK7I
q5iMsS8VIymJU5NTYxqk5WFDaiG1DSmXH+dc/zsanH5zMH4gvfZuWFdo6i22
hbuu647AzHg/mQ9SH77koA/ILqIy6maus4NqPDWZKs5wn3OtZ8kODXQWY7lh
sGdilNZcFgKsTFmkYO/oaTrFtNB1L1k91hUA+iiiZ6C7BxIaLTQxaCxlLLo6
nJpnTQ2t+UBaGWSeDae3lmpuSZ/ZgftC0mFpUjONLdhX2lpCZknDWp/eNjjT
IGX0aIdr14XBlwtq0Thh63WN9WN2UiQTlaboTdLDivorMDOPg40jxqzNwoJ8
OJjkLh6QOvYHQZ1NE239Dz0t6VDKTsYP5L6LuHLRrbaTifMVb7pWNHXeNiEv
ZFrArLT1buziSAfOb8dEmJ1RgPCK7PgBIY7Oztq+DhzL0gUx0wqaKD6qW0wu
bj4gOXUcE+SKeazpCa1KNDyL3JmbcXMpmc//iZtWBTsykpPZ6LklHdv1LFFj
7m10nm4q820fYeOj0LY0fut9hlf0btOfirW1xU3PI3BloNTpSBn/fBZp+5qy
cjj8yFh4p4EzpxvJ+UnT/polPcLqYypPidUGiv6ZmF/2WNV9ow69Ct7sG784
+CRbaI5Cdbc5EjQkV8mxiuED2v0oBQzWneyTN04NcQWLiguqqYENl3ZiWH+M
pUh72JlUXeYomh8S3R2uvQI1qk2JSsERQgPmN2RHKbUuovK+PAFRa1K+XTtv
t2wMVfMgMqld/wzfniI2BEhOlRqOa/VIZRPSpkoTl01D0UvcgUyvfNlJnq3Q
sJfcPuWLYje+QmVTssebt8SV3DNRa3EpV6Yg+m7cjAb1L+cZA/rywOGQwXZr
qCaZERxgXvJs8nXRcPV+wrxk1nSHRQ52RGqyILkSWEYLWAGFobR3KzWYQdPq
3fGrKDqILCk8LzO64+Z1Wpo2ic77uW2psU1HQeg7LkTRrCTJOjhZhn4ha8GH
Z+g+z/VXW1Q0+Rp6pyDS2Ydv37By++b169c2TG8FZm/T06T96ZC8pvUumh+e
GHrxSNYFcikC+aa+yGLkoU4qs+raqNbhbdl0YBRY7Sv19q/rLQaMvZiW0gUw
PcL0aG8r2vcDznA8dJl7ZPMy5ItLPFGtzbfH1o3Ut9GTDHdjDoJ+QM237teW
jY9TfasUG0eqoT1wQ4VLKk0+J5ABXfaD5FpxSeqILGGHRkpGjCRyfae0QQNa
5bQlPF9hfl4o4c1admx68e/VuGBD3Wf2oHGRyrcq0RqdkDN7wOBwU0frCtio
PFYp6NnLX7FckzS1R7tvxre7bsb4aVpFnbyH18V600bVktpERd2RqpghgCYU
2C2UE6VS5omDRKDLqb/YLRiuZW7Vbug1qS3Sw37HInmutULi+r30PB4066/w
tmDx1Z4vMJZn4nKZPCoy1MkRB/D7n04tK2w/i0nEsNl4yfEe2pqyRY7S2isT
b7wcatNeJBzUaXdVB6RDliN1XJUsua/NbpAKJVa+fhp6WZpRzfVQtNJdiBvE
b3Efjbg8i2IOerNwhZEkFqIt7HCX6LQms0k0G6IvwtwE4lZLQDh1bC8ff3vA
muehc1IkWy66sbWv7bdUmmLmJBh+AoL69ImKTGOopxMcnc2JYwLRhaI9gELs
CrTffUGamQvfSqeFJL2UIM6gjLEpqpI3jDpiWNuzNqF6XuQa4dfpQrvWl2kF
nuw4bntARUn0TR/4ZChBYg5wgX/bfedhk9NJWBP7WeURDaNq7ZKmuC25gYDh
mld7Ph27nAsyu9Xae0pleAVRPuJrb05vnztGgb6m5lZsaQ0b8Yw22wbrwGBV
3VqKJWn+YVu4IZDKiT/73gaSe/eZ+n+0cuT3vUpPY0ktMZ0EU6AyTBqZPSvw
f548ejq/b4Rf8ejwY0hc2aPscfb02bNn/a/+A8ZH6ssm2EC5W7cT7PJ0M/sB
Nhj+ubzZTOAM1UM2HHe72jPuL9+lOMSveHTka7ZNz56/ePobt+neD/A+NbA7
S9wd3JdvzCAa/d5wDLL7sscPHz46OvnqxREmShwd4WtH+FpM06EyTJqfM3uk
GTquYqdELZz6FEt+JkXHHf/5nBtj6/X79Kn3GWSgXp0mKw9Ef8eYGk1v1jRB
Tr4gBSvCtpTxtXrDWHLAtrFVguQ10VY7EU9JIgsrtwtnJE6LBC8Fs5A+ZQAk
Sm07CnqW1evqrtGyiHyXuEoS7VJ4gOPIRvdTR/hT/yEUi7KTB9+enLJnPC7y
WiyVyFTVXiC0tmshoFxs6ohI6xP7Xe/3YqLGWFT1xPyYaP0tysrcHLypvFF8
dW0BjK8UM4e7air4w8fVpWgNkAJVIOgBCnJ8NtaoTifAkMneF+4a7tbqPybY
O4qp32Ipxqtcz4n9waapUQIW/EkDYskxzrORajscjiMLes11w7luAOfjY5vK
RNEN/QAxqa2oZd7XJokq78aea706zDpE8CocELpvgRXURbPnsBMb1S6feG3Q
XiI/8TWlsImnL0RZ7yiPQzSZhf2S/WBL9nPM3n81U0VWvCh9XXgaJmO8bTKN
11atIe+fHxb07leJOxtZpxaVgF3brp1J2HfCoXGhIZSBIRli+Blt21FDMYVb
0gJ0UwXB7aw3qsO2ttK6VMuC8zSSYknU04/6DGiruqRK155yKwIzCYN4VNLI
eqcFXLXODbom+MZNULhPMgSEbIGfoQybpIEYF0BKzYh5XxtyhmA0kffoRopz
q5urkEj8ql7GZ2f87pMvHj97skcv8QP9d94d15eSEf/h36Ik56g6pfrSL95O
VDt+4XYu+eVnT754vkd/2b/EX/fuYDu/ePbkyS/ezt/2LdrORMPq5C5gAeQo
Yn8DdQ4003S+KPtffvHk2a+m0V/x4rjOilv7CAb45aT63/okbTGpC6kCu//j
v06LffJknxb7eESLzXu66uiNUb2V+Ri2ut6rwj5mFVawVRIfEJH0/sMr8jvH
0pjdtWZpuPUSygAk4HajYcI0BiPp31ZYVCT7m44TUhNIWCDgtivlK0tXN4xo
rv7rMiHLu1TNutXZ9JFiF2OpBbIBshTq4LTneAV8Y94+AZ63qk6rl2T8ZFiy
Sk1iLI6FOFNBJ0t1tDtyyWlyBskzudO1PVtZtag6MWTkLS7aoxs/eVNfTAxG
b/lLKjW5/6HNYlCmDAV9iNNxLRLO3mHXPsKIXTqLIl2vliowfQLTc5IWCkQL
VOQBKZHNGcx9xPOPuxjdZ9KcVLNhUcHX3JWYb0yDmsuFlx0EubptqSdJjGak
JEIp+e7EJ73YR4zqkfLt6cRyrdHj1faCsrTByfNpkU6q3CfuoyxfLNB1pF4z
g9/hplCjNAR4GrLigAtvo1G2tH8h0zrkHBd8SxLVYnpkjFrNODFGg3QGARPs
XxJaCHSIPrCktZyxcGSxinugpSVaLco9TbBNeLXPzqbBsI6thKKpdfI9tU9V
uSUbC+F2CQkQ7woS7dU4sknCg/YwcSKeST4PlXvOPn1GRZ1/GgPhp4hyic8o
4Gwv3Jf9tg5orWB2eOoeQDpVpoytQu4FVrcevs5l3ql5rhVl3198firbnkQJ
KGdYE1korZUIV2KyCbacc1bAAMGCvJLrjVn0NIuffspiK3RSvK38HB0LrL2l
k2u3C2o8BlZ47PBDHECL1n/6dPzqNOkxgIRJlvXPD+pS4BDoOuvq2L6VundJ
M4DkBNVzwL1jZN/b/sb7vo3M4LTHQ5gcb7u6qm/gwr2XHiZvqkugLgo9AHOd
ZAfH798czrOTb9++FfpTmxC/6jrD+FrnwZoWG0biVXxxEInnZH3YIcToUeM1
jmv6lmOU7YKprjNsgRRrFqaNvGMjbgVnGrYaP+Jc1nVsbaVdCL1TgLwuRiNi
FpsTKmJtOYe/5C6lcq1ryhKGOz9zKFOVPryH9ogvXyFgKcwPqJsb/W0f9R2I
eIFyYNkJxps3W3wswj4GUHNY5vbGikuOAMU7pjaMB6UcNlmzK09MXNSSkG1h
rd3ORXSprAStLZBzlz2Tbpk2uxZhTF1gWcS4IE0/A+dP8fSY2btoTd8nKQI8
scWJpVA+gJFeEfuhRU8MgVtOBrEw7Z83sqjM7lPscoFImOv6jloh3mxyAdH4
rJ2IzDRQ/aW2CyAOjfgWdl8R2mWLBRsaoibOEJOOyzm3nO6BXTV/94Y6gtEg
tWA90Vloj12Vt4IQo5imw5yTbBKopvoc/vru+6/ffvgAK3j0+MlTrol3/fll
8eLhPf959Dk8Tk9w8au/snHy179Ojt9/j+HB7w1dCXzy6TR7jA7kyeQ7rZX1
1w/fY6Dp+7cfXh1ffDizElq/6MtvTk/PPlx8+P7i1SkM/vTpk+9g3F82A9Rd
/j+fRPMPn8S3JziJ5y+efvfdPXP4vvlh839mHs9hHvjyd+G7aIVyY4tBLIVv
hy9Ikmd9I9SZImdn74hrgpWA5uinT71hWT1wlUl5RP7KmMNYWgL5zpwG29We
cCRbqPB2P4ASGZb3bWIAhSMnQBgGtdXoxasPx6eURZWdXLw9P8Q3YeMCv4BB
M5xCB/IJ3eU3Wi5Y//xcirbA39Hvzg8wcJvB39E9Q6XgacJbKdfaF3QYs5hQ
xVRMqbrDBFfiJ502HRapSjOHreUOyNIc2wrArKQ0lSxQf9/LKw2KsRQUrrDF
ar3TIH8SnImxEcRPUSoMK8cg/NflJZl/K6eE3V3vZLGlYJ4VbKUe3bSfbSyF
7Pq0SsGMETRCmx2kJSayJ4euOTHmFguYhoBfEhbkNd4giuyqCOpWN5AON3za
uV5EKr1G27aoEiDcXAqAijouuJ1q+JyAqHut9riNhevV03pJE1aF9Xkh/0gU
kmBcMb5KknlLbeIlLd+EKNr96wgM/1KgFeGHtjfifcDMIK43BDQRU2QOrB+D
ZuqV+VUFArBcSptPeRJMU7R4u2tWx8S4lnoJfWVOroEtPFpgfK//kVKSheR+
4fDIS8g97PjXi6Znz55F0XT/x71w/Ed+/9kv/H7zD/4+SaNnJBXv+X6Uiv+T
c3j+HY96j0R8/PMS0TUe/+Ui8bHV0cZwcSN2pln19whF9znyc63KVVqSxnlk
0ZYfE8ZSwRJRiPIBM2qlhT2PLeX48DkCkVFeN6rCSc6Kj/Nyx5+x1VrLYEJr
X1y8RQYBOo/mlqPXY9Cm2doZu1X3Ptgg4J55HOXKcz0QNI/Qqpau1BUm7i3q
xvlNXZiTczNkSo/SjMvJxElsK72C2syVVpO6R0oHk9KsDLjUSQyApktx6kjZ
eqNKQqh1VDACKRh0vp4eai1ug9Xo0oS/eSal79gqcm+ZD8jKO4GYwWR00CvI
D8SJDq5ztDt9LO5gatFABdL6VVTvZUmtzNnUx7bmmCNSM0RQTbmhMgCn313j
ymot3qHpQkn8mPEm8aA04Ivcc54d85u2I3RnzG/h3T+kTvoGxCP642ADl9ZI
KEj5SH6DJfJiJ76J3myHw8BNA2O1pjSWVYGeYiomJDmLNnt/HsPVZtL4Ar2O
vV7ZmuIQ94FnbjshpXAoQw+vFA9I/ZAIZ7MgjCMsook5OHEB/1jj9ees1nvF
wW80FnXM/2Of9iYiGIlx554+fvLof2jn8Ez/4ZsHv/3uHin65Oel6NnP2JXM
aTTgJnGNQqOffYHzREOd8rwPYVhZR4WpRTIncRDYLosvi5eLdF8ffqBlMxOm
ezh1jyA9zcMxJkmIaI1MnDsCixc4hTg5AYgMrr9e0KIt2cH+xgPpEwzLTuWK
dcOybUNmE6Ta203RXKlB0bORMDWk8KLDikSQ0GgLCTfVd1UY4eE2R8vnofMp
JMMRM3goNNpqqtINMj6BU0rKeUwjZYwaRfyaJJE31lM1/+nIBlg4C2fNwSOe
Mm6DGbzeTuTVuwpJvkUXJm2GlCbx8RYWGmfWO11KeJe6dNJFCfZSSjTm0rD7
xw5LS6BLW0xD1SrWRVIWhMCVPZOJs3FgqhFoOmrrYaPPovjZRqcSL5PmrhIJ
+HCLIxZ3IUz+XCyyt6BkwYwmU+kT9fLFC2yGRGBSPFT2NGN2bXlVsjWqyZqk
IH1zcXEK9y5fUc0ezLdHrQ1EIf0h9gJDbasVnF/27dkb2Gj8/Jo/b7VCpOY1
1icNEghI4s+uxU+bTIS+h5WpKGWFa8np4oBrvqJEEvYnnL0+v0B15zWoMU1d
MY0dvKrPXh/SG9LdgLZE9g4dYNEGz0OcpYYrfAUcbRbu+rEOPB/zoC2CU6+P
u1vJ8nAqxxhXEy8B1Q2Rlti+EEoSfxr6WwxRQMcjnhIJF25LinpkB3ewdRSd
A1Xh0OJCreCSuZ65zp4SJWPBFnPeEz/mC6oOGSH6PnCb6yFZB+LcB0+18O1B
jLAdcjaF9fFGN59cdVVvyRdIF/gArMQnh6HXdlUb2UeYAkuy2MhdT5C1/vic
dGbfqHtNM/hhDnPNHfLJHlwqIr5/TaUBi8r3euC6dhEAywltshTbCkRmB9wO
V0go7oFSAvbjZr0OmdpN0UlWcecKElgre18wTj6n4AraQdzYugnmd+XNpBCv
9Xx2nGJi9eNO4DtLjM5OXO1M3GIjefUvGnIC5iVNobUxBsZwKX/TVxBzO2vh
ygOcIOZpnpweRqeubwOctptGzTc2Xgxxhgd6WZmCDzVqK/Xs/WHj9/CztE8a
oK2rSID+gwn56RYYj3C9DWttPs/YLqqnIVsqLTMaDupZUQ3FX2Foq3SMJ2Z4
2Wmv9FB0G9iq0amqSRhVLOpxy5cTtCCsaDC12cdChfo+FapKTzsZkitdOy7u
NqBaBTbkjbMzgUjN5GizgHR36U7s7ucdU6gGQYxT1ii6I/YhdIi1B5EhVD7B
QcMTxrWoTJb9VmaoYfWvgO9cNaCqrPBWLNWjH7EPzuI1jqnAO22+yRKEPPnq
20ilicX1Z+p+d34InKPhDAzp77PCUGQuiwoRZq0EG0CNlXe4SkJRoOdl5nwq
qjA1qGbowkIZ6yBggELLQJrTg+teY1kyAZDrgjQRW7zLlEWh7glUyOQOBdJh
o3uCiRZr+zTSBt7nSXr6fqCyrt/IxZIldUODwtklyUJhL5MDWsaht+kP5FBg
CYcCLXNNy3snSjpcYHTX/IfNxOpf2B0kWopdzg8mTfcH/eMM/zg57Cd/mgIy
6DFqLYjgfEDzXF8mLsLY5K/w0A8Xw9PslYjtC5PLy4ePj44uVxP11jhkCyfE
K/slX80xSMNXdb7J3mPKE/nXkEdPs1SlIY8iiIwvnrx8CIadOESIwlR8MGtH
AEzZFTP61CoK0Y0qCmSfXkjLm6MQzl7/x1H2x9cXQD/55ujBg7/CjL7HGX1P
MwLz+HsTkt/jcN89mMes8Qe4b/8CZ6BHhgOeH2WP5w+fwbooBIM29e9x9BaH
P1NJjiOLPPhepvnd0Q9AODOUPl/+LoNRIyWEIJCbsSnrnv83p4ZG/9HR8osX
R8WT5dOjZy/yh0f503z13dGLpy+effk7P5aZ+X3CUTtfKbvHseVaPiBnMqGM
+Hqzh3x5evbhP/+SqsqdwW+1LCyI4xqEJqeWx6sWyMDN2Z9u8rT/lPmnldMe
cCUNEmUol+O7rWgcx6fWXQI5IUpt/AM2g+kNduhMRZpIVdxNnUfUTWNGVWek
RACXV7fY46am0B2JHywLst5JGjtbH26UihIFteyeWzZ9k+8rlnQJDAOzJiDc
kqvDhzUcJ2+IlQUsBgRTy9or9iNIOZAQJsZoOCrJmYPOJB9ZdLlfLImeVDas
i0f1izGHrvJXHHga8XfZv53+xdS5X8HmHv9WNrefVHGvpGn1hG7WP/+w2UVG
zmZGYHM3KWXkNuz0L5O4GrEfyK5Q4W0tu8o2rUwSFmq8CmuZUmV0TSQT9++I
wdklpSgG1bgYw0DYSfYYq3aEsptUWM91YSDjmVZRkGvKSbtxmvRGQXDk7Inf
IhOpX+hlkUiSBFamesiBpTouPHqsrIIVS3ZKzeGcm6hj7P+qX9jNbYWV4yOu
qioD2m+ghqzXwZV3QI1Wm0do2iDFiCyaXwlaMDoFyNmhLhIkPJJzT16+eI4O
zHO5zk/mj7kSC1Zh50qUUQnQvg06gTyxX7YVEVWEBdBDbe/E75OM90qV3R6x
ooIFyf9Xyb107BGp9w+ZDmXnrBYvjkDELZaro6Nnj787+uL5kye9CeyTc49/
mZwTd8kIUzSGhThJ078/NzC6R15nn/TzSMg/9Ro/32sqWOXHxF1ywXVW0srh
qMYPAplr80cKjP1O8tz1q6KbmX7PJKzccQpvL4sNh9Ywi2Mlv+CaJmwddL3K
NYEMirxpsOivQKiMmXPbwgLzLayI1PFX778mdJbsyGPcAX/JCOrFoXC7XNnB
t2dvDqWsirVd5hY+sNcMO6fh48eN71pEzUSK/onU7N9ylf5pP+WyPEGytQtD
5AQndD3LF1Q7+cvf/U2xgTrkTAyag9/B2YsuGTHKUhf7AMySw/ju5u4Pk16x
28ngEtg2yB3QlTpqi9eB/AhpkQXFEabVepkCExC4M49ydPnOztTkZbJIfhWL
/gR6WJvQa8/3fSKuVzPYmsTgDqe1BrW2PYpBFDPatofFE5OJtsKpYIe5qLU/
JaCNb8/ezsxyb31BLfYRpeU2zVPHFbFo5maiu9yErg4MtXIwzehyZHwb3zFp
e2BQKsoeQVfQlJdMJhRtWdBijiIzok3OfsW0cxC6WUCsC+SSAtSomDStfd/a
sgVK+8eKzNImoMa6U2Vsf9lrwXe5pb526fe0P511wu64LCwVdNOOYk6XF6XM
3HtafMJSCe8I1IIVBW+R7XgoIufN4MlFakvbLDSETa+rK06jI7VCe1/u5Y5W
y0xYrMBGsJg3Utnee0LnEqV9qppzkkRSwj15IHCgKHkg8UxN3R3EuokJL5kI
ux8yPZJJSjFpqYVOa1REB+8FTpVCJQKQPDZ15k/UGnIS65JQTIEz26RxlJyB
DT7hBbzi0x+8G9M8hD5aROOE4yxZmlTK5/QOpdnJfJIdSDTQ1ZSkh9CRfTIq
9u2kyFOs4BjVU63z7rhN1U5cQU4NzJTk8P9hWzkUJvrtRDRk111HRrxjweTI
FNveIYvm4dy0kOGEtTPkPnNvp6X5Y6cruojCTcTOjIqW9tDB6nOUlpizKSbx
J73EtEaGltLzojdpVycKjlxI8pqf2FbLYVY1lq+vEPiE5szeKyez35fbV+60
6Yz5+pJq7OhBFKEkZqaDCrnmKLsRNqzyJRFyOCB7OKQiyoRkdSBbxzQvlnZy
cZFK/2uLupSIcEoOdWDpFoxMQT9TN+RiFXoqoPYOGEDScvl+ln7fJtwmWClq
ZuCDPinGPYbqlC1bK5r4J718iwJ7DrR8PhS10X6hKTei6f2/3V1rcxvHlf0+
v2IW/hByCwAlUZJtJptaWZITJZatJZV1qpJUaggMyYlAAIsBSDFm/vv2ua++
3TMASa2S1EZfJAGY6fft+zzHqrJ10pbXA4VmiXZR7LRpNNgMrNU4nmvNZQ7j
L9K9z2+0SEhbX4JzaaKlA6C6ipxKrFw++fIreBXIjSOtFq5VAZ5hRDxpRkt/
Sgn/xREsrznE1UrqfT2XnAhn9AMKn9S258+eHT4rHw2YiqNf/3BzUtEXFBpp
Ptps1PPpMthikSpB00K54iImpTqYqFKxr5i9xC7AuC/0rdSktx1Q9umSTscd
RDxSPT9ZfZa/RxyOPyqfPireVTezRTU9KspfqMz8wzbAsT8dASPllz8X3bj8
ovzD4z8Z4IM1vWpZwRagk1KBskrgnfzcfo81elw+QerVJzX9pKfpvywf3LS5
e7c3jeTsg1NtPDR9uH3Uw8/WyNPt49vRSGLQ9zb0/NmhNBQaedY3kvCKLc1s
tf+f5va/fNH2Wtzi3c5eYc5HdTTmj3kTiMXNuDSltPBFLyD2Drrr+mbExBYR
W62hHNIYQSWKGBxqiFuI+VplrgPcDUJ6rfeIBOycQ4CVD8aO1O4FXWm5SYwJ
9lN+XEfzuRh8MWD+pNDQglhImQeNcn3lzJd/DGdMY0euACdJg99SjqbCqS2Y
n96VWJJ47uD5ee9ENyjaSX6x2Y+54XxbenBXjnm16wQcTXBC2wx/b4B9ljzd
d1NVKRnQH8NxxARZCF99+xUzCPvcynUstDIKCAOARvKVkhVFWwcumeFWA7Yc
HJwOfAG69bwqPHmVynu+XeimiRcuy3omxZOUyLjSRaTPkbtVjETVyISWStYG
CpQv9lUkL3Yi1xHMGF/uzchCQ0ZSPdKbO+usy7kqwmAJXoMX64BAFj0NV5iL
ZOc+sZ3ri6PD+mFTS2xIK7hz0N4iYqFEytZ4nP4Y5OPWl4d27b1F9t6y773f
ciIeXvssPpvh+bRFxOF1tZdbIjux/B6+TQlwhNMUZPRmJhjKfLunRiDy6pCX
IiLvpy8UtUmSO4LojDJ2aeC10RlQnbJzQ5NBSI0V1c1Rqp4GPSy1HsQWSNyg
EpxvU+00kcQS3cvf1lLMOneLOrft3zgZn3xLjNHrHLXBvM0U4shfrAB+3Ji5
VFnrWkfaLqpihxcEpwT192diLlaMUmlZQpJjXPXkHfG8DUutMiyEqSjSx9lx
SShIW2Ku0itEykRPa7h8KDutUODAlZw6caqppOzFgzbNHzyxwFQfumV2KzJd
UF5L9JXZJI6M8xzoQEQ0CEYXCM/1mrHLLdlXBxZTLmGw/u74O5ViTuvXUCHj
SzGfGZW60rgxQuTR0kDT7WVZqueLxVRAxJmqxcT1Yk7LG9NUM21bAmZ8YV1h
SQ1FBgNfF26RJI3L4l/a7zYavshQvvGpNJGiJijgPvKq6X+RepS3hZigbj+Q
IMAGt34AoV0Tvtz9SVW2uqFibvNS0cPxvcNSDfvgLWsvvERKkOV/00oapnK8
RHq8YkYEgUJ6R/HIZuIi9lJp3MKp0WHIhFe4JnzJIsPPYUeRj1WeC6Ox4+E8
Da2dNWvv1HOiQ6xipZtZEy7S1GX9tmlST9FFqKVxUkQy+ozOIu8Vg8WAS5Yk
RJoN3bm3RZZdiGc1yjH+JTZQjHP8ncyuxDb4x5pdB6cHqytqfYvZtWrHEpG/
ArwQCha2/3lQu1ettttvc42lwT/jFt60d7QrA0n6fbXrGTHDfiE9SRre2Rib
Vrm15PZLbi/ZAVDDCTYS6f5sE10IpYXzT+BK49MTxRt5+wY6vwOla4lbmotz
EseB6HThQJACl+Il89FiziE+Tso2EutQlB4D05tsg0HBimKYvWSZBjhO1mk4
aERnm5akzWPI6niUrosARQ1QHO16UVCjV6qRhn+Hl58KsxZzqyaCZeAWXnrn
VnRAflnW3FLHqkx7/LHAUSyMzPNSeTOZACS6kjCp5uA9NSb6wkVS4ogg8pQ9
xKnvqR5F2rOyIzjRtfQgRQZNLMg7uKhEjTdBVpum/lRnP6i/TJ8UC7W4m4XH
5AN9lE76VctWrPG4zBl+PKyCMGVmd0cWBHJafWHRLdG0VUnRZFfkbsEzTkGy
Oad6BN2XwA8Z9lFcq2PQCzUzo1BxB0/eJYlkAvfdzJmlRlJXC1dwQhVeTsuL
ublWwM1+e3fjQ1GEfkiOb7YyhhwtZIc8jm5L4b+WQxmXl5QDQjfXtFpXhaTI
8DbIRiDG7gyUnOez5rw55WLWKUN2h2fXwuXJNh0/nHsdDU/UWeWpbnbGmcRY
XGsPacpRI5wyRKLL1JbvVBkXKp0oKzBankBcwFPZlMno5j6zTEyEVrVKRXDf
jkYYuk1MP9eFyCVqIXNi87RvsghSFqunWm1aWny0IUuLS12gYTZSMR8peVpy
FhDyVmLDGakKfAh6ojuBG9taRZJL7fLpMNlelTMeQ9S+zJrJuj0i/ZvxYvMM
+5bj15iq6YaLP+vExx2fg5oZLQuTPUX05cUSJjYa4XUXPZwkA3KZIRg0F+u0
LtRDIiQ0qXUngPS9sppeV8RwoOLRqSvAOery61CaL4B+Iznp9IIBgWkMKBUx
LdniCFInXlukWyMLqBIoYPm75RSRBFj1+m+MF5U9Xx4e5iiaG/mFJMuOXrym
wyPm57Px4xhniR5DciBarY9SLVekGoMKkNBUI7gc1NtIETQRk+FNtAwdRiCQ
3ioyPweGEz2C6pjb8K67RXoUjdubuT6Q+pnLftuUNLiXb99RrYr6t+wqcz6q
CB6qoPpph5IuFN05U1OjlapS7xxz/lTKvs8G3rTuI6kbL/aoTvQLCaDL/h3R
0fnbflwzYNjJZmKcd36uD19xX85Qhl3JXIoyE961VCShqNzwIT+iYFiQViZ8
2fB9CelH6Fvh+5b7a5tVzDBeCKpoJdFtTlSnu5500AJr6Drk0IB9vkjTGgwi
q3WUKBseDZeHIl+1gl3mp1zZKdNRmLoRz2mR1HZSgLyI3sJ8GUeUqa2TkSwU
NQegM59u4BK50Wl2IvT7/eJc9Fmlmk3lK7k4Z75/RxU2YSZ6jmMy5YG1mqU5
ZGes4Noj/FeL0qU68LtXZUzZeGvQuIzTuQXGxfGzDjtnhjA7FsCERfX1ovAg
nZEek3ofPqMUhek4F5mGsJ0JzbYjNcNvUMHLlMo05Wl+4sd1JgtVwD4fPx4D
2OZHPbCxQm+HfBk6VAYCkeErxpIj3Nq4MwGwhtObxGF/nGXEGuJI5dQxEfSa
oSzYLVoilk5BkvVaiDvpNz+cvGYUeja/zKUkQKCAWZqsu2CufrsFfTKhOmrz
k1duw40du601YaboQqWvxckUdzTeRNEnt30d6Na4RxcsyNIZIk5AYc+khy4+
plgB3zP9SbL4vCGVf3iLDMi3ltROFDYQw2bavnVCV+Ps7HiXqmKc8E8eSMwO
yiTYmBTsKOf5lnwxxcEtYgJyts8Z1VX5FaF4TggyBD99x2WB4sqF+XZTrFcb
KvuGBp1MDUS3ilRSrY1HyTIToTPZZIzvKQL8uX5i13Cx7VT/9JNcKNR3zoMi
4oH4e6KODWrtWkpJaGC9GeHS2qKt+3Ul6qEwa02nLTtW1bSl/NLN+TmcqWos
eFSLrv7TEZdBw3z+/OtHuYZJbVnYmVLAq+l6xnmWvg4SmPVIukHseVrhW8pO
hBSwbYoIu9HWVxk49U8/rdbhGBk+xouokafBrQ4hqyD3h+uPupaXKjEbcY+m
G0zterVWkBaf264b4cvx07I6W9caZCUiEMSEz1fV8kKUQd7pvod7q/V/7G/J
xOTES847axnxX3MjOdtWI0+tjcs0lSBo/uLwwlw1lnYpmRz4xNKOSaumYGoL
4mWSvGnVUvKs8zwUt/fHP2CzhJ3zp30O2qR6SqRuS3shzXz/w3sclYugEhCx
tBqgjgdVlIWgAnAwovYJUm5A8AS2mFmhqbopY9c4Hy/tmfRAbsWCygMbMYYd
jqs5TNP+216yHG5zg6RJsyqCbsI2CKs+oHyVmCx7XAPxpTT3TLKxrZHJgmIU
dEyUx+AVFXTTR68/BonKB4EUl5eLVQIzsQe38Sh+8J9NvT4DJ4cCKSzamNbA
vY837rv4HhtKsRdOarjubF/A+IDpSud9kkee8SkV4HDP4hv5lN8/eTm8iwVE
LqI8BEyUGR0pkWvMFChGl7QLReeIJA7bgVvl+x93TbwOR1ctB6IFoNfcF/4m
TlrMwu6LjLNkht6NpSAkfLoT+KZ0clhYaxmsmDVfxMVVP+hHnZC8bwuq/h9n
IYuGAet/tUZjNILb8pgyj7f/ubULnrr5Ll66t2w1PuDPbWiPM4FJIMvyD3B0
BrG9N6/ff6uHNu3JQ/9saU/2mb41rVc7FnMJ37zYss/DTIrYi/c0twZnMXun
ZIN3ZnN7aw8fHcJVcUElTDU4sd3I6td090ajQnEcUN5Zx25n0d5oB1zY19lu
LbZP3HwEJ31bfrNq6jNIzsmq4Vj4vcdTvuQ0eIj1Vbh0wyxi92nVCq/mKn3k
u11JGBAA3One5mijZZ/FC43aW+ZbUDOgnUrZl/fmIF60C/doT9cTWdQadRzI
tEeriDAFpc2DH7m9uChYLZVLVftBoudTBMhRHySq3JU5a5B+ngToq9Nw3Yik
oI6QEkqX3qCzBQbGFYLbn1/bTWZvvXIe0boktiBO/kzOpv5K0nsbsWfTl9km
5nNnMYMkgwCQBYX5zbIt0qkZUZIwepWkPslrpTAP0QEOAOTLvMflcOSjihne
g30pB+McHGmAZVNe9V1QDnqSaF5K+QvP8meqGPiXKBgglceb/k6F+ukL7yuw
G7HvgEhVH9VpaaZJOfDvZTYwY216pwBc7/C/77leXVseFHb77ml8//r6etxU
8wo64UEYUlAs6TI5SPwZVEg+4vL3XV+N1x/X+zgybJzAzvz30vldh2XmRZUE
6o5nlaweIeiZTjlxJ51O00OIflaDSUUpm1zE17Dc6qDJIZ+or+87jlWK0ccR
9HU49oWIcQ0ELY5BbzyqM20XRWm1hvftJwGJ5T19JRsfDugP9U2rFEpZn+8/
6ySEaRAkhDG1oa8WqdMRMbBJ11F6VAJ9Pu/VUfmLnhLpXwKKoXYKS/6bkbow
ENTqdc3RIWPf3w/GZ9Q5bIy+ueuU4RpKB4NL6UYM7aIc/Kqe18dB5kRKMmO2
iyduj3qy32c1hT1RnYPYendnITZu0y/tRo76xnZFpbg9GvX92fJx+pvi9sX3
fwZoxJ9tS4AwIOgCd2/RqCKkk626wh1rpLYIdAQs6Q47NFiBifG5ZTWrGF3V
oO32lw4KM98XizVGvlyyg/0ShsQJsb+Vv61vMgK6YKAJOJl/lzV8XZ9i1e8h
auWo2ks6H4w/XqwvZ/ty0e6YHmvcPP5tTbki3vZqlImA8dBRDcoQxFBUxuH8
UthFhGNMFeCKeZruOEaKYiWvHhYE107qD5A1xY1BGOxz9lUj5VwsUUtl0Vey
v4Yet3B/+kQ6fD96g0dj3TsmYUTCxqiQy2T2W5Ei0Rs/o+0WG0kxN9gVoxai
DL2etxsl22lQ8MKpxLwIPZHm1YZTAV6YeU4r4TuiZG5V19/m0oDZWX89u/Fh
lh4Ky6Iva8X7sMW/D9JZS+XZEVU5c/HxPFCIAl+2pdqDFAIlC0sYW9DHpnUh
4W1jGEboyyJt28GbSiyW0o0s2CepQ8k8SndM4ILxlO5VLMucjhafCBRb8WjE
c9jtmR+UrpuVmyDFKCikYQ/PwiGdlYQJmYZ6eUMz2xXnSUXCKcof7zY5FnO1
Z16LzuIMfcL/hQdhoLMOw5BRlVeIA6yqyYeshxQy5zCCHCgGx51xFt1cNGWn
D3adl0fFUfn+m1cuOJYeRny/5ewJoQW9AtpENFtxW2V+SvgFeiLV3pjHWrP/
qN16nWaf6n9hlksSSmZLq4oj/7XLWvbovX+uS3Wvn+uFbOMfOSEo13Jf2N7W
L01PUmeL4kHEZANzafdcxZKnVaWeP72RI7aEw5zYckXH++EfKbbPUOXAUYg7
5LbW5RyYALcoAKELMH811VgCmnaZAwykaXZaRuVnzVCFq7gIczUA/bUXPTLv
KQdOrWM1Ul5aemv+S4h25p+LVCns0mcpTMFWuVtmlCAanhn91Xowbc5R3/No
9PWwKC9RaUX+TXVO8CNse8DCZlbPx09KF/RCNWEuCEKLyAOzUWdYLZ1b8CKm
B2WYSXIp6qsic3YO3GW+jWEk1ZtqTgnjVnTzCazqmERhOFFzzsMaxq5HNwaT
JvQuGN16gqLFydUOnog3gaQfCEKzzwpxhDhqmLSEOxl9UVThOlucS5aYdUd9
TLoLwS9Q1DOCUJKUTQ7TG3FNWj+aVMVS+taJz1frS5DwYWxFoFhNGSK8fx8L
eulK2CY4vyX9qUaMaDsv5hOD7ABlOEEmrrvZHHRLaWXbroSU95AaZ+h31kHo
va3XVFygkzRgSlTCiZ/WIF6M2E/Ykt3+XDfG98smRxiBHEbOo6PNtAB9M1Wc
/zCn7OrrzsSJIy9mdkodO3V1pacs3uL54XNhtfzV9zqK0BovqyWm3+rctI4y
K1JwXAhaD9GTAUf52r1HNIGWyYYiZazu/FPmjdx3mLuFuhJJ+czH2rgtKYB6
4YGbem1RTxGylROxfRqRgp8m4v2fqCZ1gJygKOkURUUjn4/cMRF0p12q0318
E16X4jV1mg5xn5VXCuxZzxGLKW+9/uO1pUn2goc+nwj7Bz+v6lc2t6p52YWg
eyPZC4nGlXo9t+V4PlT3St76L6mAveaaG686QRFLfOdGb9ihs4lQGDM6g1pk
ICpDFHV9FoXknMSqc3FkU76bIFS5il/+2d5anfj7fGPH2Q8ni0u9IHQ0b1Ze
ytVSUvrdZw4WxTeeSV4uA08bfLaBNwv/M5XBEiiH+d36kpjf28KQISlARjn6
VLUmNC6SQi6/UiXyQRqkpiN9ogr5ijRYgWneMjnDToZm9DW1ZNGrMtVJodMs
jj6jPxHkizIvGeB6j2wnsl6jPMb+K1Zx6KZV/K4kbbUo6VFGA/zk0FBKbBT7
4tz/acIepW26HSqxBxux+Bc6Eywj7XMJ7x4qBU3cUD/RKT8oD8Kb+l3SiZTj
YRgF0raBIEenNwGQoqhC2x1avAvH8VOygWgkD8/DcYNMjFSyTPvQ74wB5j7m
C3adaOBFFc1PoNFdl3s96sY+cuFGzm9Jb093MsNrKBVdYfenUXxPyUbdplOy
wptsVxOoJAqrBKyJX3a+QT4hkuhOa+h3nS2wryvY64bj9FCDNX7x/Z8ZPEaR
fqr+g7BXfaiO0oM82E/S6Y0boci4krWcMCWWvaT75v3Ld+JVaHzmrU4N7cNI
PxlTCEul9Bu7Whgu700YFKymj/kgMksqQvvLZWhwCXIdirRwHJ7x3tS7imeK
Z0KXR1NMRdvjGaYq3qpwH1HJGmluMylRpIJKQ4IATjey3NWYj4eTFVqTbV6f
N0NXMVE5Wzpl83X1ypwIIsyc375shQTC/S4hpcopPLGyDoPI42bisoW3Y0Em
iXpwO6/n9BVmwooKWuREXrR5v+WNfsLlNjVthZWVoWMp4qT5RoRnTzhd7bVV
baQHkQ/KinfGZY5/U++YLXmnIcNSTryVV7nKiGQacWJs+9FXSpS3ivm9nNwc
64+TNNN8bJJduUrSg2Fk9aZ8/M3FSwRWNQtX8y/4BJallhrlCzXkurdO+Zbt
cCmeKbeGRxINOGz0/0+Wa+ZZgvnqxSekvRqxXbO2R3+/TW+KMosQqJVrtuKW
8Po9beDOh+kH2f/C2BTHMQ8cdCzmvojBLeMaJxGEX785GYkJe8vCRY1gLZj+
uzQVRdueHtv92Kqk2+xutSfgcluuJ8v0g9DgV19//azcNkCXGPNZm9o6QNMF
7pzWnhDRbXJR3zXATlLH52xq9wr2bNGOU6Z/3xAMadKN0asxKheEUNcpHiOt
S7yVe3HXtv07NM80K9xyecd8rLIJ+cd3CJfh7i3Y7dHOfQFFrdwhRNwzOzbj
Z2m0b/J7G5W0pr9LozTBu2RYt9VewbKZZoLlrvndJcw+S5t3SOs0j/AzjzTf
vL7w0j/a8dneU2rjOPFJ0mW7HMZ+3Hb9uYnGYQUOmc5xt2+337fmYuv8wcPd
u/0v/lfw89bhLROBAkl9vSsXH2Wgm95ZEJh9i4MHg7vNnDJ9Pgqu9k6JobL3
7ylJ4T3ehk4YTQo5X3itkTkwy+NstjHUh7SZN/+ziaCjnQfahFYme1kwBYpq
dl3dtBTCrZkO1JifepselmHtlFFG/MWxyJ5aElPRgTYWFxWTjysOS6eC3pyt
/OmOlUjATtjY5Nk2WJsF5fCfz5u/hq6tVmGFF5vWFYyGtmJTrWOE8d5x8wc9
zBmu67LLFU6/2ZJM4bzX6g1/NPpa6ypenc3Wg/JsVp27aoptqyubXJyTyhYw
iVsf/vX0mXEw2fzPWkPN9CZs7wL6KvMYHBV06SQWXcQUE07op5Q5PYOEHiN1
nFkZDEdsK5y8tWH/cCGGzN1CGYZBItxXXG9pqBMwjK85cT6fl55IPE8OL8Jx
ezXtLELlW6dmCEVscxaEYMNBeiKWv0LYYnoQ0yYtoaMRgphmHrNxWucl9fue
cVWVGcIY6U+ZnpA3G073tJkqUykJaKIWnwoOz+QDh5LsgchIor5AOd9pzB2o
D2TAG80WjghB+lwEg7817LR14itJ8ZI5Ot6/YzE2liGFf5WA4uelu7Qb6573
/COzEDUUB1/v7bdha7Tlbf/g8o+jIyJLPsz/sK+h7xv/I3VB9AbT/T/vUwlw
l7+i8yMkPgYRFfq6Wl3GjiNe7vUy/GNPzMf9YZK2uGVYznwxrsvyrb7Wxq6/
Xt7ZemY2mbLX151bBSXZ2rS0LmOfXLZ/sUclS6A79sPnXw3vMwdhg7w9GQlv
+29Ofvi+/G+xc/vHTii9O1vPxv6X61ZN525Hbgn2J2m+p4ux9cldrd9jtZOx
f/PDsUBPAX6IjypkUu/Mw3Fvj0paRmfmv3x0+OieM/+aXsE1D3AtSwFIjKSm
Y79c3t060PvQ+tdPvzq8o/XvkFwnlYoA3goC6AwopAelouZR67iPwq/bSb3c
2foDZx4ILkFIzerzaqJwsPmP7j7vYvrJrtvqs8lm4t7nXU/cll2Xtr7bbRS7
cO9dZ+vef96t9Yfu+c9y3j+19Xue9ztOXJx57PXHT78KqvrdHdETR5GY10FL
plNHFNi9Y9924tLWP/uJk7HvvGXU93Dvu8ZumdX9bpmdcv4TWr/nuou02XnH
fULr99zz2vpnHvtnvGU+ofVsz1Olt5bVA7Ltfns+bz3b+cN79Gb7AaC5QV+i
/0stRHF5bfFTPMDz5bxdztb5dIfXv4STqz+Zsevg0gSd3C5P8lvMycJeB/dr
8EJ5TxiX3U1TIEhPBNJN99FMn5hRQqmIlQMG6RSa6DPqNUHhSvQxZKn97JZZ
LutqtcWZlvOgqM+jv9EumiM7JticFp/KurmsPfssD+MHBtfsOEGSnO+y8T6s
IRn4MsD+DnGaYyFVAiYG9hyPWnRn+Q5pOfByFU726qbbr5iiGWa0ueK10YII
na2sU4X0irs8TOon8PhgNEgI6CNNKR6LGUZyLikNSwoIux20ygYypjfAa8GA
mBWNQQB4OmUDc9LUYCCFmJ33wflyWddr4xxIGhC2apmVVT2pkW4FzBRin1/O
hGLm+uKGoP/roAZXyIBaLuBCkBqBnvoKTvYQ75VDg/v973+veH+FuqsEVRk9
VeqcSml2tzjZwmEeGhUTe4s3xFC+XiwiBYR7jFpIa6bvPhPEfEy5VJbdkteH
KY5mKtG5XKlNIMb46CYOJIikzToIv79Gz5J3eanDOkf7FreyupK11MIDnBpn
UWFOrT14k/Bc2JfNVDdv0qF977Dkk8SiRUvko7eOUxf1VHNRLdzh0piefE58
7Jngf5ZPyjJn9h7vU0p658QMguoxev/dCQGVOyhz2cHd3xMwSOHgm2nU5MuW
CIGrNOyGexeW5qiU6Rx0ZSaUfqxouh8t51EvWjkIrTXXOGe/Bw4PneAoLBFb
k/AobvOB3fq8IPct61sn+Ubu/ZOmBTkNcmd+z5Zq4od75UJDYXUO3JKWtz4C
ewtjnRR40mRvfSLHlj+3lHJFU4kdFEfktFH+qL8h+tmtqKS7G+r9tLg1Aqre
hmCK0bc8oh0urnvowZ2kCvsNR5oMUcN2fgphACWe1yAdhA+D89TEHt8rreVB
UyOmQD41W4d29xqo5u+iMrnyf7fCL/6oH8EY9VvStH53/Aasfh+BorIgUb6Z
IzI22c8BfOV2FFoomuvB54JUEWbMyGQ12qwaISMK6xR+2kwgpMQwpLBjltqZ
FgG3i1k9izm1ntr9tXKk0NChJjGLkxbveJCSnajl9OsMGiNM9wUnlLe+523L
18/jcdk1qHheKV5TXVryPYNNCJCUIc4RmB3xfoXeM9FX+Ed5glDXx4HPLA+n
RVZBClTXDH9HwSl6a6eO4Cbc9h8PFNktUgPdvczZwuX/50WGyH+yewIiuhIP
UoRjOMsYqfwPgFWsSn41Phw/xmsPe16r5bCpSTeAGB0ISla6wXVuwiw0c7a5
eIw+rZ5D0X4PcZwRB4jUwV5GtvGgHPHakJbbtDH4GuOttMLh8g5Xh7zegd1m
yl7VWgDSHmOfMRNhBcPFsYaGXlKNhIIQyXa6rC8XrUuB4B1uhnpUI0GHtoJO
MVegRcNYvKhnS0Lzhi18WS2zzi6se818MVuc37iKtwWlygsWPGEXk4cfukaH
ObeVb0YpsjEcFDk4u1IBc147pRd4yO5XixOgClIpPiEpRnR3Cu2KxOCfACBZ
ud5ItK4Xkro+rWfVTUnIhoKdXbtwxZlxhUGqLJZs5wGbkmk/PUI+lQLIj9lZ
wNpy9MKPlJ+iw2mrQADVjVAzuWwH87hoiZz8ONJKM4RO1YqDwbOt6uiTgheb
WLCAtmZeBClR+FlVhrewX4IFSbnjr0mSkuVGNSvOapCunK6C8k1WBCfTEIda
aCN8PSy0YS5zV8uEljJYV1ewCsOchD0J/04kuWY+L7WwGRqRFo+QBzDMCQxo
QOS9fFf4VQHmDxTpka160IrbhnEp2X/kaMhTW2mI3JNg5FXsKnCvdcWaukxD
M7gq+IDOFzQFMvt+wc1c5Y23ZY+4QUjyBw9RrHztCEjQyYqpz29ssr47/h0V
4juiHHGYaf+0X4V1BssstSJB9CyWC7IrXUtI7NGV9XzmddwQ+NittuwqUFNm
ZNhGdSHkF6NrFIMRl69ohipJae2WFXKy1lwVc17h+iNHRjAwZuFqpFsm7mRY
77AUye+GhIaZbpjFWTGtY30SMQOSU0X8BNIbmm+6Y8GXtRCmJCRk1MTBSFh4
s/oKcjNciR/wFRMXFvJKAVVQxBewd9KbWwPKt51/1swEfUQ3PRXhYvrCAA64
lqU8PlaI0LZgaKuwTiavaN1BUAh1QGFfmV6Euesr6udQVJ1sMHO67dpmxdcR
TXNxFd6yQDKXpmAyjeJEeexcGWIPcUdCKJILnYK1s2YFEbo5qwj5b8UXdJ0t
Gfxfi2l1M1ThYsSCYfBX2DR6nRS6AcLUhucW0b3KgGS9wwAfOF2tw+wxCD6Y
5XQ86CZ22Cww0YnDIjyBTY3FY60iI0yJopou2/YChK0gX4LqMB3GjDNxpNGM
hdnpTOeEmF45cWd248819JjQ4pbRk4T+6acwdyevRifH78KrGF9wcRlnzuUr
if1/VLwTMQ1qSYInpTpgWbY3r+qrN69UZoYPwpvLYB+74Q9NqwYmMKVLrQq8
jOaFXU+qrCa7QLfbG10nKlal+anonf7XTGgTPp5cIA3PS5jW0AaSMjWsKzkO
OVeMVjZzPhW9W0X33/FxG70jtrbzEl2SiuYwGTxgXrZCwix0L0PYWiZXZ5nN
DvaNaRYpz3rhR0mMrk2iEjTrtp6dKe2PWHhyb16WxHLvPyVToojNjRlqtnFJ
YSn/DhiHNmur3Q0HQlG0c0yZApTj5xdUbjY3W6inrjeYq9tq6PY5b9KxltOm
reO5VeTosC8Ix4CbaVaO1nzImDnYKkEGry9uHGU983txNXjF7w2fFpu5nCug
I0Z+dDo7Mlm460hKO1Spob9a9dCukSK4TnQSWlMLTzNfBHeFrjVeQrPoqIzW
oL7Jy6caQeE6p0YCOeUqmaggLy+rZu4HgQD7LCpWFQTEi5fvEPXRp6ah8RWX
eQYhGXoB5C3S+YdlAuuBSYgPYTZ45wuq99Z5diS9DvP7tE5WifDFZRIueVXt
jc7rgCUTC8QG2fJRNAnH+50FHB1/jvA0fPoLXrKS7zySUEGMVs1KS6FjJgG0
I2Hapogi+Vv99UmUq2QBvZjAbMSppB4VxVsYDLBTBDlsRRFNWv0XYcCbVfnr
GhsnGMXr+uws9PLbldafC9UtpeifBTF6Suo5yJzDZTkvX1arJaI54dm3QeWq
gn5wjL9X0xayWD/77eKqWgdZOi6LE1batD9hXC8uEVQqv6lWUJXQQWhAZIsr
exP3mJHYhcEhbArwhMPd93rahOk7giSqqJr2ckFinnQNVmT/VBQ//qqcrsL1
WT76+ihoF5cQiTU9ie4E63vM3D6waJgJD6d+OcOM30ggawbUsrF/11fhXT+E
jXdRbaDPJb3mu5o+qqsVwbfSMGQIU0UPCXpnzTynhrSL+6GggO6HOoF9bYJB
FClfNy3fy4r+Ev094/I1LBcOQbDgJhLKYIJkbB1BkT4fHwWpzfHnAQEzjDDS
QfK7cmQ6ENHGxVrzunChFhwyaITU0JiAlxGuRPpZOHfhqWqzTnDFPtQ1AVVM
gkrdyjx7JgUk+6/tXoCt1lD4lGni1pHpbr1YRC2Nuoi9lIAcF6dJhYDg8I0o
Ti2p77A0OLgqMAEvmN/wGnL5QJipJRyqiCvlK6jASPaZ2eKHjX3WrEW7v042
xrh4t1mTbU0ny3ZpmBwCo6PfxoOH/cGXzWRGoXP6t6OFLxR4mTRxEbNsPtQ6
fl+cwZjERt7iODZfvPbgiMdvhTKTakKEoA5XWo5a3VD9vufdoBJ2AkaIt+24
pKm8rKa1OULJCKBeJJ0I6y92Iw+Wkt1p0iu4khDUfUvbKpLhdDmrdDrZCffB
TG0sB1pq+oCnh4Xi1M0Wiw9CzicAi+EEuHA5JTh4bzcaIXAKiG1EaMPqkApG
NtZC2XBaB69AoooN67Db2gRTaMBa+6Aw7Rv7yZx5XzqgJILnX8HkY/hGiJQI
OYyAwXjMAqtYJUn/dMFJYsmsEk5WiNT4s6G6aKg3QTgBehDPhp8VLD9xy23q
ON3ex02MJsuN8rntXQS1DXrRsg592qdoKAsIhjQER5dFfqV4IUYrBrjLptHj
57bO6mwC0sNYjcEIIc1f2a9O9zDVL/EThGZx/P4/HDjKij3IlVE4Kns4Q6HD
bLWD+lTpYu0e+PIIQV+2Sz2bpxFGkEGK3456gzd7Rp/CqqyJR7F5NO2jw40N
mcg20z5zBM5Y3IZF+i8+vtfsUoB5ICzSydPRbAgH1LP0nIRtB4bjoIlfNLqw
TQq7/gZ3ZfifIElx5Ohb0RNY3cx1ABU+OpcuXUPN0pXQh9JksEYgrMcLNTdS
VTDnjw09GwXpTDK7fDJ+jBt3NqsVSjuoR1xqQ6cSIepVfQFL9MqQkA4NsNVr
uhSDod2x2CiPNRfTJBPB97zoV6Ze+T5Vpy1p5+z1yjsRzvoehIR4niVFBFpS
2Jz7BsjTYwgZ83lo64SCUlyjFJ3nR6IfTYlKSfaZZGAN+Nog4xRKMhsFYE/j
r2laFfxUA03mgOCUqZxWIAzwZ2v6zc/KPUAPCM/CyKu0MtDwCVRX9h7Q60gO
xQuqKMVy0BtvMid5DAAgNQEJB5dlJJpjhUdWNS1HU8ajkWkp0w1B16yFJNXI
OFspIvx4o9u2ped4J895RbEl9pr5vin/nrfAW53hXYxdy9A22NvOgnAmyhSj
18EMEsNqYDMO5tzQgtTD0RENu5S69x1Qw6IPkga1YWUXsVpRwatwv8UrLWxt
hZStpv8GCe2k3PMj7HQ+5WiUtrns9rPtpx62TBhoehhIkts5IGaBeEjVD0u7
E7eF0O0yZmAiMuIRoChIEl29XKybKyxns/4Z+5ToxqH+JrZOGNfLoFzNSSlK
Yk1v3h28eXf1vBz9Uv75lP4PvLUX+NB7gorCQ2eFLx3G0xnzojLk70RSYSQa
aQrZJYchRBXNHPM8sVE34+SZcG+uFkts6xpDM5E3PrQDRqaBFe/xxoxnvzqf
L4L6QhoMdZz0EWiaYab3bO73+e3B/igPcftR1FV+JUi7q8XMnN/i7GYL0gCn
oG8YcUSQQJPLlgPQyDEZoGYYYU/28fJ9F/vJSYTtfkwvczqx3Bw+cYh98WYQ
EK8XREaslrSC16V4R+D/eXtC5YskA5HIbmtDm07cm3zYaV5JiGvITZtGMC2G
EhJmiax/kPvBzBNO5aBlVSsJpZGLkoTsHib8+T4ngYkS3KcAxMECgouswkOw
X3NgtprhrFPHgyEZ7hREEdStYa87MPq2MHC9KWaIq0RmYtqHh+Pw7vD2kROa
9AVMXYqX2mveXMJnHt5zOH4atuWpnWOl3zGud7lyz5pzTdFY0Z6LP4hrwHl6
5HFa18vR6c0Ifyc/gWStOsfomhRZcaFLWmu9hED/NsjFsHvJNXC6OW81p21p
PVOl5XD8jEaPrcKws0FsNDRORjZg8HiRrew+/iBA2HTfB0sJ0GZ7ZmGXL75/
JYIjrPTJGv5/OI2JRJ3nA0snitA8LFpYYWBCXizW4aL+YH5/L7y0u5EIuZUS
dpDEFiBtpY7LbEodBtI1ND3i8aCUi2HWfKjH5a8aGiBYD9jnEMytaozMxqPy
bXVzyqYWTAi2DQ6OT378lccbbGxU5MVy9ohe8mw3kgWpULFif9FpQD+cFKTS
6Ln4k8mIaf1LzZmJLvFNOC7fWHhBJBc1ViUPShhhHs8i3oCwjGAhXC/UNhhD
VV42U6QqXocBkuygH2nHvTmFLdOIKOLuShakdioafPaYjSCcHR5E9KN6dQsO
GOQTNExqhdmWpNtN6+e6qOY32Ibp7f7sCLfyjdHAlBHlHX1pm3CuKeJJBfwt
Z4NEskfnWB6nLzogJIVmEq0aVdijkIjdeHLw6PCIDiPdxWwNK4O2OubY2mWD
FYlBOBzLzTp50WPc6uDMDg3x2RRHcHlAIdxVc6nqe3zo0VFuoJzFsABWGgeT
QjZsJclUWQ4Xm1y664ySxx1AqFDTcIymUMWCzCUfD3UWWXjwbdXzi0q91v2/
fuQUMfkQGt9oRJm3YVX/F6ys8CEMGAIA

-->

</rfc>