draft-inadarei-api-health-check-00.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-00" 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, endpoint
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="RFC5988"/> 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">

<section anchor="media-type-registration" title="Media Type Registration">

<t>TODO: application/health+json is being submitted for registration per
<xref target="RFC6838"/></t>

</section>
</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="RFC5988" target='https://www.rfc-editor.org/info/rfc5988'>
<front>
<title>Web Linking</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<date year='2010' month='October' />
<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="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>


<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>


  </back>

<!-- ##markdown-source:
H4sIAHXFtloAA+1bbXMbOXL+Pr8CRX842+FQFPXOJFfR2d61LmvLseRcXa62
tsAZUMRqOGAGM6S4Lm3dD0n+3P2SPN0NDIcStb7U7abqLucPFjkDNBrdT78C
TNM0qW1dmLF6a3RRz9Srmclu1UfjF670Rn3lqrmu1dRV6u319Qd1/uHCJ3oy
qcxynOQuK/Ucc/NKT+vUljrXlbGpXth0xuTSjMilw2GS6xoDR8P90yTDxxtX
rcfKllOXJHZRjVVdNb4eDYdnw1ECInqsvjalqXSRrFx1e1O5ZjFObs0a3/Kx
uihrU5WmTl/Tyknia13m3+nClVhkbXyysGP1h9plfYX/bJmbsu4r76q6MlOP
T+t5+FBXNsOrzM0XOnyYYzBe2bKwpfk2SXRTz1w1TlSaKPyzpQcDA/Vedutn
S1tYfiPCuKj0bWF3vMZaxtRjtb9/qI4g6vOlKRvDrzJbQxzvzUr9HruVR64p
axLSp9LWJldXNcTm+ZWZa1tAerzQv9zQtwH45ndNhZ3P6nox3ttbrVaDaWX8
bFI01cTzmKRkjdqlwYbUx69ejfb3z8LHg7PTY/r4DJ+PRqPj8Pjo7PQ0fDwZ
HRyGj6ejI8xLSIXbBDFmGD4enx50Zu7HZQ4OaGaapkpPIBTIPUmuZ9YrAKoh
6atF5RbOG6+08qZa2swoAZRiQKkq4nO6A58DoV262nz3nv6r3Xcfjc5N5ZPk
5UtwoN68vri+/DhWi8JoUKnM3C2NqokHb7LaulJNDIgatWgmhQVi8ejlS2LT
KOt9A9YK62VhnsYmoDJNE/G0KXMFvv6JNOGhihtbz5oJaWAvmsleNc2CmfCm
9oTurweyytyBfGUyEocQxypdkpHOINC27hFFovVRSGQzXd6QQLEn4tz87/kj
07C135trTK+I9pUxShfeQQRGmPyVV1lTVbQibLJuPMyF3168uf5KwQlo0vet
qfpYPmmX77wYWFNPB6662QMa9r7gWXiHpOy5zfPCJMkzcg2VyxtWokhyCX7V
XH/vKliZclOIFlgoGSvg2i5tecOswVeolZko+BKMmdgCu1ssovp90gAqjLLP
nwPO7++V9rQ/WxFm4WtcMVC0aIArkWoWtZ0bWhgDvUlkXQMZzuFglF7CfjVW
C9yRtLrL0oO5N8XS+AF2p3JLTmvSQIWJX0MVc68mjS1qtbK0oiqb+cRURIpW
6itgEdAnD0kbrTfMBQ2FNcW109b1LQ3MXCVmxtNyk1lP7PQZ81PwDJPBKhWc
V5U1tk4RFHhmn0CWGO+BAqsLHg/hLC0TmtmbWbGOu4aIvSsa3qgAH/g0d9gi
2f7K5qS+CpBg0bgFIgKNBVXvpvWK0FzPNBlKYYFuJ2AL0kygT/CUP+E7goBY
XxWZdYQu2CudYonpKg82bpItKq6pF03dEuurmVuZJeEa5sC2u6VDA9VAWmBz
HZhMJtrbTBWYVBArrSPFa1tmRZPDRGE8DLigqQzA9S369oE+sAZUJrX2t6lf
QEdT0BRCJM9PXt8I8rYGYFaHu0cTVQapIdgob29KeqHLOoEDKQpDPqRPEMQX
tyJ96nKt5kaX+DxtCnAMXLOeAqJ1VjkPvNvp1JBwEzuH1yUvH0RDkJuYemVM
uRkFU3QIvzfkZIIe7A+8XNfldzXi2fkKzgxzhW13jCGZIJ+YWonsJF5QQxR6
qb4qgDcCYm4WhVtz/Emx9RJBpwu4wBHzC9yoDIgra1k26BXxDenEjEzOEpuB
1z7pex2Dg9dTGg1vOoH550zPNwiEtm7YLXtVGgPtD4i7N0tXLKMsEdSQIohV
Z44BwyYtDjgCts8rhWWwoA0eEf6CsheWjSmXtnIlb5YYMJkTXyLmxE49rOBb
+khvNouAFvkb2AEG+pp3hNwMrpohTEQBoZr4q8x/NrZinYuRd0N9DqWUHOl7
XXX2op4bH73Wb68u38enbAOUgtzfJ4QE9qngk1y05rQhWu/CYf/RhiNiusbG
unGEu0HyVi8FZCtTFKmwlncRx7F+0VSUnRDY5o7s5MY5LESJDGUqWDjZwPeZ
Qg4SMfTKlUvyihRNODYho1WU0nrVe/fp6rrXl7/q/SV//vjm3z5dfHzzmj5f
vT3/5pv2Qxxx9fby0zd4n4RPm5mvLt+9e/P+tUx+d/57/CGl9C4/XF9cvj//
piehuasLdqcOmEnYjBeVCYCE28kQc8Qjsewpbby/5/2RMYTqIdYNsrkdL2JB
8dxVffEVkpggEqz72whofWsi8u+9IO36R1B4zJvggnc7k/AMD5VbxPf1wiS9
juvbkwX/4Xvvyh42c0H27MAWZUxYm+MQ+xFCIXzEnFBVo3hRlXOAhDVFrp73
xD+DQzZmigMoXNwiaJ1HeXY2MnCsngebyF+A65y4wc5WM8NRgo0tpL0xiwKm
s8wsag6ZACKy2wFMkETMKarHRK8CBhrOjKOHXuqC8tVoAswNmFFwJ72F9r43
Dmax7stDCu542JTxMUOaXyHilp3xknJ4B8cAcWXIqsjAlZK0C8vG5CJsQ+SF
zdTIAshnwHFqwhjToYEc7toQTQGPnKqpm4oscbLuWrEpc7buAaFK/emP/0W7
+dMf/5u1gK/ELH2VxSGCLeKJYvIxQR3d3aUHd3eqIjgqNkL4TkzLW/Iklw29
3awGaoegdvQENeRwmfataB4x2m83BnpBoyKBrWRgJ9+0c53nNiCv4+c2tCYm
hkmECqRehUTWB3CN7MUNsl7PH4qedOnK4kEKwBPZju7qSIcqbJTnNKVmOUXU
dxTqppBOzUaLBMyxMQTChPngdwfqHKlJQ3EW4Ry0olMnv49VcySjMWa1hLd5
GKhXIXoHmQA4cIEc/EBwNxC/BENmQHwLGalwAGrk8KuuAJ6bwc0AvBa6ujEc
uzgjQxFDuZIY/gtKSy0bPvcmakpRQszlxSdmhmDFNg0nGIsuKLxCuVOh/mmq
TtJi7pDj1Z4q8MLpPJ3oQpO9UgskeBokdRml9JRHE4xY/L6LkG7l5Tk7wXAq
CuDPInpehIo5vmodgKwywCTYPFXdF6+3pgE1IehS1mnykOZMUBTCPHKfbsTQ
FrO2DMpqvSXyETgYOEdUXdRyglQjI5IJDiRVaHyDDHYdKEkFB1rbYynykUDh
qqUqwHcA0BMP1FiCGRlamd0b8cUBbappm0q9lYJAbee7HE249kQsadefA82o
GoCSzWpwrjMkk6gQdE4oD4gGOVfVmrPTqZpJwuLNQle03V4QbthBj4DVawXe
E7BYIrdJtadIY5j0bs2BVdIatVP8lsZ0VWnOsvkVq3WpOXXf6gEInwwdkJG6
aYtOpVfKVBU4lZeUGLQeUoIRb4Njj5D0Yh3YhkSUjWdzc1vXkrOF6CYzaAuo
uUHswSawz8n3sA3wz+osOWXdlMZIzdPWdKNXxMIRcuAVCvNEb6A+xH7SlMK4
KKxHwfC1LK0uea1e22UiNknv7BFbX03MwmxvH7Hailx4lmRFW3aQNEHiaVtW
ffp4QTLipIiae0iKaEF4ZURqeAdeQzCBBDESEyB2U2Q9oTRf9r3tUTch+AN2
vDKTlGgGCXICHupVaiJSTvaAzZldbAJTKJInhv34fI78rDI31KxCooQww4kP
FzQSO3JJ9bFLtka9dJbSFGrDojrTSImAE3VB6VvPm2Lak8Upg2/jn5Wth+BM
nj3WdbWjDIEz0bDnJVLIx2GhT1zMJasnliZwouwcA0Ie+DmUhsCLstSSRm0t
jZqOD+vH+NlJUwluGWpRATGlu0xui+6sQW6aTuG+yxyuqjPskQtGzv4Yk5Ky
94KN9KJVkHDgZMxWXynsAcULdQNIMQwrTd7K3YDpItk2m4G64nqah2y9Yi8I
6ZOfF/mH9BlehZodFO+Spa7WmwDU5nNcV3MJxRjkAnCHkWxlXDqRTD4l8g9Y
QVGi7FS8evCvwoT1HFKih3vR35Ax4tvDoiH+RDSF4oMzYembhaIC5NeDTQUY
wLCW9oKKNAMQgiY2tHVUADUCMYVkhFDITdig0+BfOJ1qVVivELJ0hTRA9T63
234Pc7kff54bOgrhLz3CYCLRh+UmFVTIwwRMTKfjd7UPFYfUOVvUd+CU2nIc
MtlYY2nSyc84ZSahc5oufom8QuHK1kJobj90avgNKSoKXseg6Coym832trjh
5cOWZEjwh52ixVJso6ArYYVie8vdX8paqKxCa4hd3JSStJfqQ2XaBoSUUiFO
0xkFkrnB4xE+Ng7HfBT0MqRu0YXQk+i5ru3chEfYQilo8XEaN6yZi/PgiKWw
jT0Val0LO6FTclu6VYk6sKkoCaNkBtv0cJ5zTa38vro4f3/O1CneUZrb9ihl
FfjwkJu0dQGiVEWSAlxqUgtxAL+dGc8doaopTCd2TWQ70bGTI9G0W2EpKFQq
CkPJragcyw44SqrcsT7FTlwklxsO5eQNNCd9ocvLPeM190u+b6jXywr3C03+
m1tf2xaj2/NBHqNenb/vlmHMbUkdNGoPWXaLmOxDpRAK/OAdEEz7TO5qpW+o
fmjbN1xElHDx8P+LipJRUHbu9gVczWW5cUUKKXbewh75JiOkL965t/GHD2NB
DEzk6pLWqwhopbXQ9hzCDDi3B/7gIv9yNNTUAfdtjqtVbFBTHOx67L3cLAwd
7mah2xtDnHrXFLVdFKZNlNq6ibqY7FMiQ68ZP4i2Rldxi2HnfQoHddQ0A36T
NnNoGHT3dr1ebHuXbsHNqSXR23KNkozwO2CK2lNqV7EaPf/P7SDaNcJ3OgXz
teSj9F16wn/3BH87noCGt+Hw3wkUW4jN2hwDTAAzNpdea0hhgkLHIfPoh5yQ
uBBD68fsq0KuXVMetwm+dJHhy+bR4WzLOKIN0FIdK/g5YSnC7IKyL5Lc1DKt
hCMNqa0ODrgZ/ncE/1/EspeK0pOxOGqIN6WvnHldXF2eHg/322M3iEqyWGlk
6nyTwGLVLtJWmpK8zFV07iadN2kJdtJBcbIhVcsQK8PhnVCL5Ov1ggogKsGc
8eWvSA+ILRTSaEyhhFs+FDcVc1rKoRHwqONFABAM3U4OMTu6JvFkw9xpKg4o
lkQlhTe1W6RyvNyT+T1qRkpt0VeTZnMqthVUdzcffsHlUI6+udPUJVOXPDFJ
fvzxR0z++s21Cic0XHfv7Q/2ubHmIQojU8h6qTHNhyNj9cTZDvWuIwU1Gg7V
5b/iySs56Uklbj81FeNI1ymNrlwxRsV6l+ob888Hx8OhUAn581hlhaPDr894
HM+ExqENRTjvhdYaPdyXJ5veHD0bjAYjec49NTz7Q6/3LT8IMsUoGdB2F+jR
dHhgjkajabo/PTxMD4fHo/RscnSUnh2dnkzP9rOz7DCs1+kL0MRNN4duuf0Q
E6g4VvK/sfrMRtpDMegB1EqPu3UEccnvVRgnYzcZHy2UT/PjbDqapPuTY5Me
Hu6PUj2cnKbT4+nJydmJPh7msvOH00k5TCCmJt1RHRPGmNHR8NE7Cjo0fe67
83boJrypZUM9uqmYDvfT/ZPr4cH44Hh8ePof3XEddYSH9/z32/5DUXXqq19E
UvWfL6CTo50y4MbqXyaDzlP2HS1m4mLUfiO8yc1EvbCDaMB05yyfUDa9F7ce
7K/XUrjfKWOpU78g1IgfSWWfls3+aHgGgx6MDo+eBNHPgaHdaFk0406x/mfh
5HiaH+4fm2F6ejYapof7w2l6lp3Asx6enA2Hw+nJaHTS5YokTPv8KSP7kpBO
n5YNghldNNwtoZ8BYVFu/V9KMKO/csFsAWpu5nTD+q8CU4OnZfe1/c3/U0Ad
HQ2fDmbvnhLLzx7NkiCgB169xydCP+HQ+f0e5xRhne7IO76sbIq9ekbX012R
g3RY+NG4DqnueOIsuedMEQnklckavt77ihrsebi155MknvPTlToqhswdzNHS
0Q0VPKuZKUNzt3O+0D2JU+9QBGfWNT5B4usqH0rkxof74t1zMkpwXYVkkW61
M0Vd15oOy+kIQq7J6HCHafs6aTxH83weEpmlOhz7pt5YOO8qc26N8VVBhWzU
pBMQzBO6HOTlOBBPOaemivaROJ49U+/4KhThUH3k0zV5mSTXl68vn0yDqRaf
GD7YayadM9aqQ4IKmoQLYrr4f3+fyN1sOtrhe2IZVeGFyW/kKiCdf2g+gHRK
vbO3Rp3PmzJHud9Xbyp7q35nCzpe+21D1wjVb5CFO3pMQvhIBXlRtH/BSiLX
sH2DQtJvzkCnkCVxMFDnJQv1na5u6U4e6Wem+Y6mmsDouMpkQvKDD9ortoLi
XXtbrFmmr+hibLwEekW5Mj4/uOKGff2OYBWuUaNc3KnpzQ1oPsaqDFfgGvyu
CFjlDcvl1phFQkeytsy5kdrewGnPILvXTybYuSpcAAvV8hwI+KSFWJZeSbFO
6SgCFsRHp7GVEYqBHqhkmvBt6Uo5hDszxUJRBpfGOyLxQurmuJSqxre7bu/5
WDEDHJ5qSftDvFIVHEZfrV0TzErnoF5bvp21abVSV4N7EXuYtXkM+co9pe0z
ZTkMnkKTeefasWoPdoOt0KDNTaktHT04in9iX3PqlvDRV7ixohX/2qYk6oWd
Gr72z20PdqE/UUb2Xij+FQXd5OlcK978SGDmVtCrXISl5oBIi5sQ/PuAzQG4
Iv0U6/YiCQBVZ7OI2aakVkpJfZrXry+vUmmIJFu3aGjLr7A3N98WLF+f9Hzc
TT21WPdzy4mMiC7qE9LoTpGcVdLVFTlHj32djZ+EifEBeim3leg+ERkYvjfz
jlVt/x6t49DndIOQ3fDOS6N8P053fzyw0mtahH4RtOnp7P5lAN8kQ8gj8+61
vP9juC8R78skuyfH+7sBGpgafbn0Uydm7UJXrYVL0sIlNPN2kmbRw4y4lUG/
tNGiWPo9S9H+LOCQr+Wee+kZNgX9qC3IzDUkM7qfE4HzhACey0JJh+aLDsRa
SNk6/k6KOolruQCl5WrLc2m9rQgJCXcrVxR3J0a1d1/B5zfw+/S8T0eozCYc
Gv/2zVRyFftweKieQ2twGYgOL+jnE7q9yMFjK5gRy9hN6DA2CXYIcC3WXxAo
bQk6ij8jsexFm0VauzTnW0P/A1UN1jsiOQAA

-->

</rfc>