draft-inadarei-api-health-check-01.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.7 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<rfc ipr="trust200902" docName="draft-inadarei-api-health-check-01" category="info">

  <front>
    <title>Health Check Response Format for HTTP APIs</title>

    <author initials="I." surname="Nadareishvili" fullname="Irakli Nadareishvili">
      <organization></organization>
      <address>
        <postal>
          <street>114 5th Avenue</street>
          <city>New York</city>
          <country>United States</country>
        </postal>
        <email>irakli@gmail.com</email>
        <uri>http://www.freshblurbs.com</uri>
      </address>
    </author>

    <date year="2018"/>

    <area>General</area>
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document proposes a service health check response format for HTTP APIs.</t>



    </abstract>


    <note title="Note to Readers">


<t><spanx style="strong">RFC EDITOR: please remove this section before publication</spanx></t>

<t>The issues list for this draft can be found at <eref target="https://github.com/inadarei/rfc-healthcheck/issues">https://github.com/inadarei/rfc-healthcheck/issues</eref>.</t>

<t>The most recent draft is at <eref target="https://inadarei.github.io/rfc-healthcheck/">https://inadarei.github.io/rfc-healthcheck/</eref>.</t>

<t>Recent changes are listed at <eref target="https://github.com/inadarei/rfc-healthcheck/commits/master">https://github.com/inadarei/rfc-healthcheck/commits/master</eref>.</t>

<t>See also the draft’s current status in the IETF datatracker, at
<eref target="https://datatracker.ietf.org/doc/draft-inadarei-api-health-check/">https://datatracker.ietf.org/doc/draft-inadarei-api-health-check/</eref>.</t>


    </note>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The vast majority of modern APIs driving data to web and mobile applications
use HTTP <xref target="RFC7230"/> as their protocol. The health and uptime of these
APIs determine availability of the applications themselves. In distributed
systems built with a number of APIs, understanding the health status of the APIs
and making corresponding decisions, for failover or circuit-breaking, are
essential for providing highly available solutions.</t>

<t>There exists a wide variety of operational software that relies on the ability
to read health check response of APIs. There is currently no standard for the
health check output response, however, so most applications either rely on the
basic level of information included in HTTP status codes <xref target="RFC7231"/> or use
task-specific formats.</t>

<t>Usage of task-specific or application-specific formats creates significant
challenges, disallowing any meaningful interoperability across different
implementations and between different tooling.</t>

<t>Standardizing a format for health checks can provide any of a number of
benefits, including:</t>

<t><list style="symbols">
  <t>Flexible deployment - since operational tooling and API clients can rely on
rich, uniform format, they can be safely combined and substituted as needed.</t>
  <t>Evolvability - new APIs, conforming to the standard, can safely be introduced
in any environment and ecosystem that also conforms to the same standard,
without costly coordination and testing requirements.</t>
</list></t>

<t>This document defines a “health check” format using the JSON format <xref target="RFC8259"/>
for APIs to use as a standard point for the health information they offer.
Having a well-defined format for this purpose promotes good practice and
tooling.</t>

</section>
<section anchor="notational-conventions" title="Notational Conventions">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be
interpreted as described in <xref target="RFC2119"/>.</t>

</section>
<section anchor="api-health-response" title="API Health Response">

<t>The API Health Response Format (or, interchangeably, “health check response
format”) uses the JSON format described in <xref target="RFC8259"/> and has the media type
“application/health+json”.</t>

<t>Its content consists of a single mandatory root field (“status”) and several
optional fields:</t>

<t><list style="symbols">
  <t>status: (required) indicates whether the service status is acceptable or not.
API publishers SHOULD use following values for the field:  <list style="symbols">
      <t>“pass”: healthy,</t>
      <t>“fail”: unhealthy, and</t>
      <t>“warn”: healthy, with some concerns.</t>
    </list>
The value of the status field is tightly related with the HTTP response code
returned by the health endpoint. For “pass” and “warn” statuses, HTTP response
code in the 2xx-3xx range MUST be used. For “fail” status, HTTP response code
in the 4xx-5xx range MUST be used. In case of the “warn” status, endpoints
SHOULD return HTTP status in the 2xx-3xx range, and additional information
SHOULD be provided, utilizing optional fields of the response.  <vspace blankLines='1'/>
A health endpoint is only meaningful in the context of the component it
indicates the health of. It has no other meaning or purpose. As such, its
health is a conduit to the health of the component. Clients SHOULD assume that
the HTTP response code returned by the health endpoint is applicable to the
entire component (e.g. a larger API or a microservice). This is compatible
with the behavior that current infrastructural tooling expects:
load-balancers, service discoveries and others, utilizing health-checks.</t>
  <t>version: (optional) public version of the service.</t>
  <t>releaseID: (optional) in well-designed APIs, backwards-compatible changes in
the service should not update a version number. APIs usually change their
version number as infrequently as possible, to preserve stable interface.
However implementation of an API may change much more frequently, which leads
to the importance of having separate “release number” or “releaseID” that is
different from the public version of the API.</t>
  <t>notes: (optional) array of notes relevant to current state of health</t>
  <t>output: (optional) raw error output, in case of “fail” or “warn” states. This
field SHOULD be omitted for “pass” state.</t>
  <t>details: (optional) an object representing status of sub-components of the
service in question. Please refer to the “The Details Object” section for more
information.</t>
  <t>links: (optional) an array of objects containing link relations and URIs
<xref target="RFC3986"/> for external links that MAY contain more information about the
health of the endpoint. Per web-linking standards <xref target="RFC8288"/> a link relationship
SHOULD either be a common/registered one or be indicated as a URI, to avoid
name clashes.  If a “self” link is provided, it MAY be used by clients to
check health via HTTP response code, as mentioned above.</t>
  <t>serviceID: (optional) unique identifier of the service, in the application
scope.</t>
  <t>description: (optional) human-friendly description of the service.</t>
</list></t>

</section>
<section anchor="the-details-object" title="The Details Object">

<t>The “details” object MAY have a number of unique keyes, one for each logical
sub-components. Since each sub-component may be backed by several nodes with
varying health statuses, the key points to an array of objects. In case of a
single-node sub-component (or if presence of nodes is not relevant), a
single-element array should be used as the value, for consistency.</t>

<t>The key identifying an element in the object should be a unique string within
the details section. It MAY have two parts: “{componentName}:{metricName}”, in
which case the meaning of the parts SHOULD be as follows:</t>

<t><list style="symbols">
  <t>componentName: (optional) human-readable name for the component. MUST not 
contain a colon, in the name, since colon is used as a separator.</t>
  <t>metricName: (optional) name of the metrics that the status is reported for.
MUST not contain a colon, in the name, since colon is used as a separator and
can be one of:
  <list style="symbols">
      <t>Pre-defined value from this spec. Pre-defined values include:
      <list style="symbols">
          <t>utilization</t>
          <t>responseTime</t>
          <t>connections</t>
          <t>uptime</t>
        </list></t>
      <t>A common and standard term from a well-known source such as schema.org, IANA
or microformats.</t>
      <t>A URI that indicates extra semantics and processing rules that MAY be
provided by a resource at the other end of the URI. URIs do not have to be
dereferenceable, however. They are just a namespace, and the meaning of a
namespace CAN be provided by any convenient means (e.g. publishing an RFC,
Swagger document or a nicely printed book).</t>
    </list></t>
</list></t>

<t>On the value eside of the equation, each “component details” object in the array
MAY have one of the following object keys:</t>

<t><list style="symbols">
  <t>componentId: (optional) unique identifier of an instance of a specific
sub-component/dependency of a service. Multiple objects with the same
componentID MAY appear in the details, if they are from different nodes.</t>
  <t>componentType: (optional) SHOULD be present if componentName is present. Type
of the component. Could be one of:
  <list style="symbols">
      <t>Pre-defined value from this spec. Pre-defined values include:
      <list style="symbols">
          <t>component</t>
          <t>datastore</t>
          <t>system</t>
        </list></t>
      <t>A common and standard term from a well-known source such as schema.org, IANA
or microformats.</t>
      <t>A URI that indicates extra semantics and processing rules that MAY be
provided by a resource at the other end of the URI. URIs do not have to be
dereferenceable, however. They are just a namespace, and the meaning of a
namespace CAN be provided by any convenient means (e.g. publishing an RFC,
Swagger document or a nicely printed book).</t>
    </list></t>
  <t>metricValue: (optional) could be any valid JSON value, such as: string, number,
object, array or literal.</t>
  <t>metricUnit: (optional) SHOULD be present if metricValue is present. Could be
one of:
  <list style="symbols">
      <t>A common and standard term from a well-known source such as schema.org, IANA,
microformats, or a standards document such as <xref target="RFC3339"/>.</t>
      <t>A URI that indicates extra semantics and processing rules that MAY be
provided by a resource at the other end of the URI. URIs do not have to be
dereferenceable, however. They are just a namespace, and the meaning of a
namespace CAN be provided by any convenient means (e.g. publishing an RFC,
Swagger document or a nicely printed book).</t>
    </list></t>
  <t>time: the date-time, in ISO8601 format, at which the reading of the
metricValue was recorded. This assumes that the value can be cached and the
reading typically doesn’t happen in real time, for performance and scalability
purposes.</t>
  <t>output: (optional) has the exact same meaning as the top-level “output”
element, but for the sub-component.</t>
  <t>links: (optional) has the exact same meaning as the top-level “output”
element, but for the sub-component.</t>
</list></t>

</section>
<section anchor="example-output" title="Example Output">

<figure><artwork><![CDATA[
  GET /health HTTP/1.1
  Host: example.org
  Accept: application/health+json

  HTTP/1.1 200 OK
  Content-Type: application/health+json
  Cache-Control: max-age=3600
  Connection: close

{
  "status": "pass",
  "version": "1",
  "releaseID": "1.2.2",
  "notes": [""],
  "output": "",
  "serviceID": "f03e522f-1f44-4062-9b55-9587f91c9c41",
  "description": "health of authz service",
  "details": {
    "cassandra:responseTime": [
      {
        "componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d2",
        "componentType": "datastore",
        "metricValue": 250,
        "metricUnit": "ms",
        "status": "pass",
        "time": "2018-01-17T03:36:48Z",
        "output": ""
      }
    ],
    "cassandra:connections": [
      {
        "componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d2",
        "type": "datastore",
        "metricValue": 75,
        "status": "warn",
        "time": "2018-01-17T03:36:48Z",
        "output": "",
        "links": {
          "self": "http://api.example.com/dbnode/dfd6cf2b/health"
        }
      }
    ],
    "uptime": [
      {
        "componentType": "system",
        "metricValue": 1209600.245,
        "metricUnit": "s",
        "status": "pass",
        "time": "2018-01-17T03:36:48Z"
      }
    ],
    "cpu:utilization": [
      {
        "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227",
        "node": 1,
        "componentType": "system",
        "metricValue": 85,
        "metricUnit": "percent",
        "status": "warn",
        "time": "2018-01-17T03:36:48Z",
        "output": ""
      },
      {
        "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227",
        "node": 2,
        "componentType": "system",
        "metricValue": 85,
        "metricUnit": "percent",
        "status": "warn",
        "time": "2018-01-17T03:36:48Z",
        "output": ""
      }
    ],
    "memory:utilization": [
      {
        "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227",
        "node": 1,
        "componentType": "system",
        "metricValue": 8.5,
        "metricUnit": "GiB",
        "status": "warn",
        "time": "2018-01-17T03:36:48Z",
        "output": ""
      },
      {
        "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227",
        "node": 2,
        "componentType": "system",
        "metricValue": 5500,
        "metricUnit": "MiB",
        "status": "pass",
        "time": "2018-01-17T03:36:48Z",
        "output": ""
      }
    ]
  },
  "links": {
    "about": "http://api.example.com/about/authz",
    "http://api.x.io/rel/thresholds":
      "http://api.x.io/about/authz/thresholds"
  }
}
]]></artwork></figure>

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

<t>Clients need to exercise care when reporting health information. Malicious
actors could use this information for orchestrating attacks. In some cases the
health check endpoints may need to be authenticated and institute role-based
access control.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>The media type for health check response is application/health+json.</t>

<t><list style="symbols">
  <t>Media type name: application</t>
  <t>Media subtype name: health+json</t>
  <t>Required parameters: n/a</t>
  <t>Optional parameters: n/a</t>
  <t>Encoding considerations: binary</t>
  <t>Security considerations: Health+JSON shares security issues common to all JSON
  content types. See RFC 8259 Section #12 for additional information.  <vspace blankLines='1'/>
Health+JSON allows utilization of Uniform Resource Identifiers (URIs) and as such
  shares security issues common to URI usage. See RFC 3986 Section #7
  for additional information.  <vspace blankLines='1'/>
Since health+json can carry wide variety of data, some data may require privacy
  or integrity services. This specification does not prescribe any specific
  solution and assumes that concrete implementations will utilize common, trusted
  approaches such as TLS/HTTPS, OAuth2 etc.</t>
  <t>Interoperability considerations: None</t>
  <t>Published specification: this RFC draft</t>
  <t>Applications which use this media: Various</t>
  <t>Fragment identifier considerations: Health+JSON follows RFC6901 for implementing
URI Fragment Identification standard to JSON content types.</t>
  <t>Restrictions on usage: None</t>
  <t>Additional information:
  <list style="numbers">
      <t>Deprecated alias names for this type: n/a</t>
      <t>Magic number(s): n/a</t>
      <t>File extension(s): .json</t>
      <t>Macintosh file type code: TEXT</t>
      <t>Object Identifiers: n/a</t>
    </list></t>
  <t>General Comments:</t>
  <t>Person to contact for further information:
  <list style="numbers">
      <t>Name: Irakli Nadareishvili</t>
      <t>Email: irakli@gmail.com</t>
    </list></t>
  <t>Intended usage: Common</t>
  <t>Author/Change controller: Irakli Nadareishvili</t>
</list></t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>Thanks to  Mike Amundsen, Erik Wilde, Justin Bachorik and Randall Randall for
their suggestions and feedback. And to Mark Nottingham for blueprint for
authoring RFCs easily.</t>

</section>
<section anchor="creating-and-serving-health-responses" title="Creating and Serving Health Responses">

<t>When making an health check endpoint available, there are a few things to keep
in mind:</t>

<t><list style="symbols">
  <t>A health response endpoint is best located at a memorable and commonly-used
URI, such as “health” because it will help self-discoverability by clients.</t>
  <t>Health check responses can be personalized. For example, you could advertise
different URIs, and/or different kinds of link relations, to afford different
clients access to additional health check information.</t>
  <t>Health check responses must be assigned a freshness lifetime (e.g.,
“Cache-Control: max-age=3600”) so that clients can determine how long they
could cache them, to avoid overly frequent fetching and unintended DDOS-ing of
the service.</t>
  <t>Custom link relation types, as well as the URIs for variables, should lead to
documentation for those constructs.</t>
</list></t>

</section>
<section anchor="consuming-health-check-responses" title="Consuming Health Check Responses">

<t>Clients might use health check responses in a variety of ways.</t>

<t>Note that the health check response is a “living” document; links from the
health check response MUST NOT be assumed to be valid beyond the freshness
lifetime of the health check response, as per HTTP’s caching model <xref target="RFC7234"/>.</t>

<t>As a result, clients ought to cache the health check response (as per
<xref target="RFC7234"/>), to avoid fetching it before every interaction (which would
otherwise be required).</t>

<t>Likewise, a client encountering a 404 (Not Found) on a link is encouraged to obtain
a fresh copy of the health check response, to assure that it is up-to-date.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<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="RFC3986" target='https://www.rfc-editor.org/info/rfc3986'>
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
<date year='2005' month='January' />
<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="RFC8288" target='https://www.rfc-editor.org/info/rfc8288'>
<front>
<title>Web Linking</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<date year='2017' month='October' />
<abstract><t>This specification defines a model for the relationships between resources on the Web (&quot;links&quot;) and the type of those relationships (&quot;link relation types&quot;).</t><t>It also defines the serialisation of such links in HTTP headers with the Link header field.</t></abstract>
</front>
<seriesInfo name='RFC' value='8288'/>
<seriesInfo name='DOI' value='10.17487/RFC8288'/>
</reference>



<reference  anchor="RFC7234" target='https://www.rfc-editor.org/info/rfc7234'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</t></abstract>
</front>
<seriesInfo name='RFC' value='7234'/>
<seriesInfo name='DOI' value='10.17487/RFC7234'/>
</reference>



<reference  anchor="RFC8259" target='https://www.rfc-editor.org/info/rfc8259'>
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author initials='T.' surname='Bray' fullname='T. Bray' role='editor'><organization /></author>
<date year='2017' month='December' />
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.</t><t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t></abstract>
</front>
<seriesInfo name='STD' value='90'/>
<seriesInfo name='RFC' value='8259'/>
<seriesInfo name='DOI' value='10.17487/RFC8259'/>
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor="RFC7230" target='https://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the &quot;http&quot; and &quot;https&quot; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>



<reference  anchor="RFC6838" target='https://www.rfc-editor.org/info/rfc6838'>
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author initials='N.' surname='Freed' fullname='N. Freed'><organization /></author>
<author initials='J.' surname='Klensin' fullname='J. Klensin'><organization /></author>
<author initials='T.' surname='Hansen' fullname='T. Hansen'><organization /></author>
<date year='2013' month='January' />
<abstract><t>This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols.  This memo documents an Internet Best Current Practice.</t></abstract>
</front>
<seriesInfo name='BCP' value='13'/>
<seriesInfo name='RFC' value='6838'/>
<seriesInfo name='DOI' value='10.17487/RFC6838'/>
</reference>



<reference  anchor="RFC7231" target='https://www.rfc-editor.org/info/rfc7231'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t></abstract>
</front>
<seriesInfo name='RFC' value='7231'/>
<seriesInfo name='DOI' value='10.17487/RFC7231'/>
</reference>



<reference  anchor="RFC3339" target='https://www.rfc-editor.org/info/rfc3339'>
<front>
<title>Date and Time on the Internet: Timestamps</title>
<author initials='G.' surname='Klyne' fullname='G. Klyne'><organization /></author>
<author initials='C.' surname='Newman' fullname='C. Newman'><organization /></author>
<date year='2002' month='July' />
</front>
<seriesInfo name='RFC' value='3339'/>
<seriesInfo name='DOI' value='10.17487/RFC3339'/>
</reference>




    </references>



  </back>

<!-- ##markdown-source:
H4sIANTj5FoAA+1bbXMbuZH+Pr8Cxf0Q2+FQFPXOe6lTZHmtnC35LDm5XGpr
C5wBSayGA2YwI4rZ8lZ+yN2fyy+5p7uB4VAv61xl96pyl/2wpmaARqPRL083
etI0TWpbF2as3hpd1HN1NjfZrfpo/NKV3qg3rlroWk1dpd7e3HxQpx8ufKIn
k8rcjZPcZaVeYG5e6Wmd2lLnujI21UubzplcmhG5dLib5LrGwNFw9zjJ8HPm
qvVY2XLqksQuq7Gqq8bXo+HwZDhKQESP1demNJUukpWrbmeVa5bj5Nas8Vc+
VhdlbarS1OlrWjlJfK3L/FtduBKLrI1Plnasfl+7rK/wP1vmpqz7yruqrszU
49d6EX7Ulc3wKnOLpQ4/FhiMV7YsbGm+SRLd1HNXjROVJgr/2dKDgYG6lN36
+Z0tLL8RYVxU+rawT7zGWsbUY7W7u68OIOrTO1M2hl9ltoY4Ls1K/Q67lUeu
KWsS0qfS1iZX1zXE5vmVWWhbQHq80L/M6K8B+OZ3TYWdz+t6Od7ZWa1Wg2ll
/HxSNNXE85ik5BO1dwYbUh/fnI12d0/Cz72T40P6+RV+H4xGh+Hx8ej4OPw8
Gu3tt08PMC+hI9wmiDHD8PPweK8zczcus7dHM9M0VXoCoUDuSXIzt15BoRqS
vlpWbum88Uorb6o7mxklCqVYoVQV9XP6hH4OhHbpavPtJf2vdt9+NDo3lU+S
V6/AgTp/fXFz9XGsloXRoFKZhbszqiYevMlq60o1MSBq1LKZFBYai0evXhGb
RlnvG7BWWC8L8zQ2AZVpmoinTZkr8PWPdBIeRzGz9byZ0AnsRDPZqaZZMBPe
1I7Q/eeBrLJwIF+ZjMQhxLFKl2SkMwi0rXtEkWh9FBLZXJczEij2RJyb/zl/
ZBq29jsLjekV0b42RunCO4jACJO/8CprqopWhE3WjYe58NuL85s3Ck5A03nf
mqqP5ZN2+c6LgTX1dOCq2Q60YecLnoV3SIe9sHlemCT5ilxD5fKGD1EkeQd+
1UJ/5ypYmXJTiBa6ULKugGt7Z8sZswZfoVZmouBLMGZiC+xuuYzH75MGqsJa
9v33Qc8/f1ba0/5sRToLX+OKgaJFg7oSqWZZ24WhhTHQm0TWNZDhAg5G6TvY
r8ZqgTuSVndZerDwprgzfoDdqdyS05o0OMLEr3EUC68mjS1qtbK0oiqbxcRU
RIpW6ivoIlSfPCRttN4wF04orCmunbaub2lg5ioxM56Wm8x6YqfPOj8FzzAZ
rFLBeVVZY+sUQYFn9knJEuM9tMDqgsdDOHeWCc3tbF6s464hYu+Khjcqig/9
NPfYItn+yuZ0fBVUgkXjlogINBZUvZvWK9Lmeq7JUAoL7XaibEGaCc4TPOXP
+I4gID6visw6qi7YK51iiekqDzZuki0qrqmXTd0S66u5W5k70muYA9vu1hka
HA2kBTbXgclkor3NVIFJBbHSOlK8tmVWNDlMFMbDChdOKoPi+lb7dqF9YA1a
mdTa36Z+iTOagqYQInl+8nommrc1ALM63D2aqDJIDcFGeTsr6YUu6wQOpCgM
+ZA+qSD+cCs6T12u1cLoEr+nTQGOodd8TkGjdVY5D32306kh4SZ2Aa9LXj6I
hlRuYuqVMeVmFEzRIfzOyMmEc7B/5OW6Lr97Ip6dr+iZYa6w7Y4xJBPgiamV
yE7iBTVEoVfqTQF9I0XMzbJwa44/KbZeIuh0FS5wxPxCb1QGjStrWTacK+Ib
4MScTM4Sm4HXPp33OgYHr6c0Gt50AvPPmZ5vEAht3bBb9qo0Bqc/IO7O71xx
F2WJoAaIIFadOVYYNmlxwFFh+7xSWAYL2uAR4S8IvbBsTHlnK1fyZokBkznx
JWJO7NTDCr6lD3izWQS0yN/ADjDQ17wjYDO4alZhIgoVqom/yvyhsRWfuRh5
N9TnOJSSI32ve5y9eM6Nj17r19dXl/Ep2wBBkM+fE9IE9qngk1y0ZtgQrXfp
sP9ow1FjusbGZ+NI7wbJW30nSrYyRZEKa3lX4zjWL5uK0Akp28KRncycw0IE
ZAipYOFko75fKWCQqENnrrwjr0jRhGMTEK0iSOtV7/2n65teX/5Vl1f8++P5
v326+Hj+mn5fvz199679EUdcv7369A7vk/BrM/Ps6v3788vXMvn96e/wDx1K
7+rDzcXV5em7noTm7lmwO3XQmYTNeFmZoJBwOxlijngklj3Bxs+feX9kDCF7
iHmDbO6JFzGheOGqvvgKASaIBOv+tga0vjUR+fde0un6R6rwmDfRC97tXMIz
PFRuEd/XS5P0Oq5vRxb85XfelT1s5oLs2YEtQkxYm+MQ+xHSQviIBWlVjeRF
Vc5BJawpcvWiJ/4ZHLIxUxxA4uKW4dR5lGdnIwPH6kWwifwluM6JG+xsNTcc
JdjYAuyNKAo6nWVmWXPIhCIC3Q5ggiRihqgeE70KOtAwMo4e+k4XhFejCTA3
YEbBnfSW2vveOJjFui8PKbjjYVPGx6zS/AoRt+yMF8jhHRwDxJUBVZGBKyWw
C8tGcBG2IfLCZmqgAPIZcJyadIzp0EAOd22IpoBHTtXUTUWWOFl3rdiUOVv3
gLRK/flP/0m7+fOf/otPAX8Ss/SnLE6Ba4t6oph+RKij+/t07/5eVaSPiq0Q
zhPz8pY+CWZDsP80s4HcPsgdPEMOKC7TvhXOI1b77dYo4QuHKkLYwgNPcS5W
rvPcBu3r+LoNsYmJoRLhAvCrkOj6QGUjg3GLfLanD8VP5+nK4gEM4IlsS/d1
pENZNlJ0mlKzpKLmdw7VTSGfmg0XIMyxQQTCpPfB9w7UKeBJQ7HWspCiYyff
j1VzANIYt1rC2zwM1FmI4EEmUB64QQ6AIPi0Mn5JFZkB8S9kqMIBqJHTr7oC
eGEGswF4LXQ1Mxy/GJUhkSG8JMb/kqCpZePn+kRNMCXEXV58YuYIWGzXcIQx
8cKBV0h5KuRATdUBLuYeOK/2lIUXTufpRBeabJbKIMHbANhlBOsJS5Masfh9
V0O62ZdnhILhlBjAp0XteRmy5viqdQKyygCTYPeUeV+83poGrQmBl5CnyQPU
mSAxhIHkPt2IoU1obRkOq/WYwCRwMnCQyLyo7ASpRkYEDQ4ELjS+AYpdB0qS
xYHW9liKfiRQuGvJDPA3FNATD1RcghkZWpldHPHFQW2qaZtKvZWkQG1jXo4o
nH8inrTrL6DNyBygJZvV4GDnAJTIEnROWh40GuRcVWtGqFM1F9DizVJXtN1e
EG7YQY8Uq9cKvCfKYoncBm5PAWWY9NMnB1bp1Kik4rdOTFeVZqTNr/hY7zTD
9606gPDJqgMykjtt0an0SpmqAqfyksBB6yMlIPE2OP4ISS/WgW1IVNl4Nrew
dS24LUQ4mUFbQN4NYg82gX1OvoNtgH8+zpJh6yY9BjxPW9ONXhELR5UDrzgw
T/QG6kOsKU0plMuB9Sggvpal1RWv1WsrTcQmnTt7xNZXE7Mw29tHrLYiF54F
sGjLDpImSExtU6tPHy9IRgyMqMAHYEQLwisjWsM78BqiEwCJkZgoYhcm6wlB
fdn3tkfdhOEP2PHKTFKiGSTIINxHXHZ8TLjsAZtzu9wEppAoTwz78cUCGK0y
MypYASwhzDD44aRGYkcucB+7ZGvUd84SVKFSLDI0DVgEPVEXBOF63hTTnixO
KL6Nf1a2HsIzefaY29WOQAKj0bDnO8DIx2GhT1wsBNkTSxM4UXaOQUMe+Dmk
h9AXZaksjfxaijUdH9aP8bMDVUndMuSjosQEeZncFt15A3yaTuG+yxyuqjPs
kQsGbn+skwLbe8FGetEqSDhwMmarthT2gASGgBUdDKuVJm/lZmC6SLbNZqCu
OafmIVuv2AtC+uTnRf4BQsOrUMGD4l1yp6v1JgB1MF0d0ijBS6wEj41kC3Pp
RNB8SuQfsILERNmpePXgX4UJ6zmkRA/3sr8hY8S3h0VD/InaFBIQRsNSOwuJ
BcivB5ssMCjDWkoMKtIMihBOYkNbxwOgYiCmkIwQCrkQG840+BeGU+0R1iuE
LF0BBqje9+22L2Eun8ffLwxdh/AfPdLBRKIPy02yqIDDRJmYTsfvah+yDsl1
tqg/oadUmuOQycYa05MOPmPQTEJnpC5+ibxC4crWQmhuP1Rr+A0dVBS8jkHR
VWQ2m+1tccPLhy3JkOAPO4mLpdhGQVfCCsX2lru/lrWQXYXyELu4KYG0V+pD
ZdoihKRTIU7TPQXA3ODxCB+Lh2O+DnoVoFt0IfQkeq4buzDhEbZQirb4OI2L
1szFaXDEktzGugqVr4WdUC25Ld2qRC7YVATCCMxgmx7Oc6GpnN9XF6eXp0yd
4h3B3LZOKavAhwds0uYFiFIVSQrqUtOxEAfw25nxXBWqmsJ0YtdEthMdOzkS
TbsVlsKBSkZhCNzKkWPZAUdJlTs+T7ETF8nlhkM5eQPNoC9UerluvOaayXcN
1Xv5wP1SZyEHe2Axur0j5DHq7PSym4YxtyVV0ahEZNktYrIPmUJI8oN3QDDt
M7nrlZ5R/tCWcDiJKOHi4f+XFYFRUHbu9iVczVW5cUUKEDtv1R54kzWkL965
t/GHD2NBDEzk6pLWq4jSSnmhrTuEGXBuD/zBRf7laKipCu5bjKtVLFJTHOx6
7J3cLA1d8Gah4htDnHrfFLVdFqYFSm3eRJVM9imRodesP4i2Rldxi2HnfQoH
dTxpVvgNbObQMOju7Wa93PYu3YSboSXR23KNAkb4HXSKSlTqqWQ1ev6f2kG0
a4S/6SbM14JH6W+pC//dE/zf8QQ0vA2HvyGl2NLYrMUYYAI6Y3OptwYIEw50
HJBHP2BC4kIMrR/RVwWsXROO2wRfamb4snl0ONsyjmgDtFTHCn5KtRRhdpWy
L5Lc5DKthCMNya329rgg/ncN/t+IZa8UwZOxOGqIN6U/GXldXF8dHw5326s3
iEpQrBQydb4BsFi1q2krTSAvcxXdvUnlTUqCHTgoTjZAtQyxMlzgCbVIvl4v
KQGiFMwZX/6CzgGxhUIajSmUcMsX46ZiTku5OII+6tgMAIKh2skh5omqSbzd
MPeakgOKJfGQwpvaLVO5Yu7J/B4VIyW36KtJs7kZ2wqqTxcffsblkI6e32uq
kqkrnpgkP/zwAyZ/fX6jwi0N5907u4NdLqx5iMLIFLJeKkzzBclYPXO/Q7Xr
SEGNhkN19a94cia3PanE7eemYhyddUqjK1eMkbHep3pm/mnvcDgUKgE/j1VW
OLoA+x6P473QOJShSM97obRGD3flyaY2R88Go8FInnNNDc9+3+t9ww+CTDFK
BrTVBXo0He6Zg9Fomu5O9/fT/eHhKD2ZHBykJwfHR9OT3ewk2w/rdeoCNHFT
zaFOtz9GABXHCv4bq+/ZSHtIBj0UtdLjbh5BXPJ7FcbJ2A3io4XyaX6YTUeT
dHdyaNL9/d1RqoeT43R6OD06OjnSh8Ncdv5wOh0OE4jQpDuqY8IYMzoYPnpH
QYemL3x33hNnE97UsqEedSumw9109+hmuDfeOxzvH/9Hd1znOMLDz/zvN/2H
ourkVz+LpOq/XEBHB0/KgAurf50MOk/Zd7Q6Exej8hvpm3Qn6qUdRAOmvrN8
Qmh6J2492F+vpfD5SRlLnvoFoUb9ESj7vGx2R8MTGPRgtH/wrBL9FDr0tLYs
m3EnWf+L9ORwmu/vHpphenwyGqb7u8NpepIdwbPuH50Mh8Pp0Wh01OWKJEz7
/DEj+5KQjp+XDYIZNRs+LaGfQMOi3Po/l2BGf+OC2VKohVlQl/XfhE4Nnpfd
1/ZX/08V6uBg+Hwwe/+cWH7yaJYEAT3w6j2+EfoRh87vdxhThHW6I++5YdkU
O/WcWtRdkYN0WPjRuA6p7njiLPnMSBEA8tpkDbf4nlGBPQ+dez5J4j0/tdVR
MmTuYY6Wrm4o4VnNTRmKu537he5NnHqPJDizrvEJgK+rfEiRGx96xrv3ZARw
XQWwSJ3tTFHXtabLcrqCkFYZHfqYtltK254Pvg+JzFIejn1TbSzcd5U5l8a4
XVABjZp0AoJ5Qg1CXq4D8ZQxNWW0j8Rxs9UP9aiRcnOztelleAiI+W7r/YaG
fPnQva2Kr4HzOyO6mPqV+hh6oOgiAa+RsCPfKHc0Xl3FRpTHr87LzOXSoNzd
11hNbKmrNUa0ivBwhDSj/ZKrGX6Ow+dLEhkbuvpDJYFukYqC6x6sk7EpjPZC
N1nGUN6qqNOMluOT/2p3xMJ8uveGe2fUFgvcQ+u7FXoC4Z9C7+jHmOxftIVR
JNCU3EubmZYGGKb6xc1QPaKhZuAN73QZvOH9iOl8kX25wuscI+fCsKNq/ahb
m8BoXzSeu+tJq0PbG6XzdzpbxyIg5fYz5jwkH+Fyv636inQom+ayBlWEuOmP
ywyd0rBq28mDjDr5O3WoUUejetiBvLI4ajkFE2TWlw+SuGVWkWJXjhJA39Z8
bt5d71A2ed1XV6ewz5EydUZp88XDBuiHSniJGIBxH0LXXr69x7F4FDog/vYB
I0+7jeRSy2g9D9vxWP0GUif39Eq9qfRMLg435fQfM4NwYcdf65xI2WQjH1hZ
QprTEo2qGM5jU2tzUiLcNhM2cfnCinnHDNbBVganT6qaRIHdgXpN3RjB6RWW
GsKo4LTpw605ZyevQBNG5KdnNgv1yBf+5ebd3kC9oc85qOuhpOyb3w5Cbq/U
Ps3NoIXOz9WURrLToqv9sbo5//cbHnUwCPfkXZOMbil8rgZvKx+QjemM8V7s
j+8IMyl/TJuK63ZPbfnyxz8hwx7Pn/n4SzSvpOpbEPIZazKJmT9g2zmTPqMQ
HwpTPbMQtfRmVCwtTD6Trm0KGpr7RJxS7+2tUaeLpsy9gaGcV/ZW/dYW1AXx
64Y6vtWvYCuOHpMNfiQdgYHFf7HpRL6Y8c1sJl0zUg2dIuRRD8BAnZasU+91
dUvt06SIc83t9GoCbMTFQCYk3+ZRNIACe2W0t8WaQ98ZfcMQ+/Wvyavg94Nu
ZOzrtxT9wxcv8GRPBuTNxyrcbVAZLpRq8LsiRSxnLJdbY5YJdc7YMuf7rrZR
sg2o3S7BCXauChfUm0qujNf5QpxYFj9UrFO6Mcbhc4dL9D6hZtMDlUyTM7C1
eLG5KZaKEu00tvJFN7TpaiG7fPtUwPexsLlkvdXkD0Pza8B1fbV2TUA/Ogf1
2nIf7eZGjOITl4x3MGvzGPKVdtLt1h/p2ZniJPPOFyKq7b8JkIYGbVzF1hk9
6Jh6Zl8LKmpzh0JoLNSKP4wsiXphp4a/0OLqNCPdH6n29V4q/uCNAkrnC5DN
91xzt8K5yjcLFOBEWlwr5k+5Nn1Kis6nWLf9flCoOptHnW1KGw369eur61Tq
1slWsyNt+Qx7c4ttwYoD5q4kuvqI5Vm+GSAjoihNmkatn9JSQh2G0u4Uy+8b
OAsT4z6nUppKqe2TDAx/N4uOVW1/OtzB3Qtq9uaY9STO5D5m3UUOK72mRejj
zU3p/XmMSpkJmXev5f0fQltbbGtMnp4cP7UIqoGpEXLLtdfErF24/GjVJWnV
Jdy5PEmaRQ8z4oozfRSp5WDp08Oi/YJrn7+gOPVytdMU9P1xkJlrSGYUOaLi
PCOAF7JQ0qH5sqNirUrZOn7SShc+a+lT1YL+XgiqWJEmJHyptKL0aGJU+5kC
+HwHv0/P+9TpwmzCofFnyqaSr2b2h/vqBU4NLgPR4SUFfN322/FYAAmRsZtQ
z0wS7BDKtVx/QaC0JZxR/OLPshdtlmnt0pybO/8bc/NvIc0+AAA=

-->

</rfc>