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

<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 Hyper+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="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>



  </back>

<!-- ##markdown-source:
H4sIALbMtloAA+1bbXPbyJH+jl8xxf0Q2yEoinrnvdQpsrxWzpZ8lpxcLrW1
NQSGJFYghsEApJgtb+WH3P25/JJ7unsGACVqnavsXlXush/WFDDT09Pz9Os0
4jiOqqzKzVi9NTqv5upibpJ79dG4pS2cUW9sudCVmtpSvb27+6DOP1y5SE8m
pVmNo9QmhV5gblrqaRVnhU51abJYL7N4zuTihMjFw/0o1RUGjob7p1GCnzNb
bsYqK6Y2irJlOVZVWbtqNByeDUcRiOix+toUptR5tLbl/ay09XIc3ZsN/krH
6qqoTFmYKn5NK0eRq3SRfqtzW2CRjXHRMhur31c26Sv8LytSU1R95WxZlWbq
8Guz8D+qMkvwKrGLpfY/FhiMV1mRZ4X5Jop0Xc1tOY5UHCn8lxUODAzUtezW
zVdZnvEbEcZVqe/zbMdrrGVMNVb7+4fqCKI+X5miNvwqySqI49qs1e+wW3lk
66IiIX0qssqk6raC2By/Mgud5ZAeL/QvM/prAL75XV1i5/OqWo739tbr9WBa
Gjef5HU5cTwmKvhEs5XBhtTHNxej/f0z//Pg7PSYfn6F30ej0bF/fHR2eup/
nowODv3P09ER5kV0hNsEMWbofx6fHnRm7odlDg5oZhzHSk8gFMg9iu7mmVMA
VE3SV8vSLq0zTmnlTLnKEqMEUIoBpcqAz+kOfA6EdmEr8+01/a+y3340OjWl
i6JXr8CBunx9dXfzcayWudGgUpqFXRlVEQ/OJFVmCzUxIGrUsp7kGRCLR69e
EZtGZc7VYC3PnCzM01gFVKJpIp7WRarA1z/SSTgcxSyr5vWETmAvqMleOU28
mvCm9oTuPw9klYUF+dIkJA4hjlW6JAOdgaed2ScUidZHIZHMdTEjgWJPxLn5
n/NHqpFVbm+hMb0k2rfGKJ07CxEYYfIXTiV1WdKK0MmqdlAXfnt1efdGwQho
Ou97U/axfNQs33kxyEw1Hdhytgc07H3BsvAO6bAXWZrmJoq+ItNQ2rTmQxRJ
rsCvWujvbAktU3YK0QILBWMFXGerrJgxa7AVam0mCrYEYyZZjt0tl+H4XVQD
Koyy77/3OP/8WWlH+8tKwixsjc0Hihb1cCVS9bLKFoYWxkBnIlnXQIYLGBil
V9BfjdU8dySt7rL0YOFMvjJugN2pNCOjNalxhJHb4CgWTk3qLK/UOqMVVVEv
JqYkUrRSXwGLgD5ZSNpo1TLnT8ivKaadtq7vaWBiS1EznpaaJHPETp8xPwXP
UBmsUsJ4lUmdVTGcAs/sE8gi4xxQkOmcx0M4q4wJzbPZPN+EXUPEzuY1b1SA
D3yaB2yRdH+dpXR8JSDBorFLeAQaC6rOTqs1obmaa1KUPAO6rYDNSzPCeYKn
9Bnb4QXE51WSWgfogr3CKpaYLlOv4ybaomLrallXDbG+mtu1WRGuoQ6su1tn
aHA0kBbY3Hgmo4l2WaJyTMqJlcaQ4nVWJHmdQkWhPAw4f1IJgOsa9O0DfWAN
qIwq7e5jt8QZTUFTCJE8Pzk9E+RtDcCsDndPJqoEUoOzUS6bFfRCF1UEA5Ln
hmxInyCIP+yazlMXG7UwusDvaZ2DY+Caz8kjWieldcB7Np0aEm6ULWB1ycp7
0RDkJqZaG1O0o6CKFu53RkbGn0P2R16ua/K7J+LY+ArODHOFbXeUIZognphm
4tlJvKAGL/RKvcmBNwJiapa53bD/ibH1Ak6nCzjPEfML3KgEiCsqWdafK/wb
wok5qVxGbHpe+3Tem+AcnJ7SaFjTCdQ/ZXquhiPMqprNslOFMTj9AXF3ubL5
KsgSTg0hgmh1YhkwrNJigANg+7ySXwYLZt4iwl5Q9MKyMcUqK23BmyUGTGLF
log6sVH3K7iGPsKbdhHQInsDPcBAV/GOEJvBVDOEiSggVBF/pflDnZV85qLk
XVef4lAK9vS97nH2wjnXLlitX9/eXIenrAMUgnz+HBES2KaCTzLRmsOGoL1L
i/0HHQ6I6Sobn40l3A2it3olIFubPI+FtbSLOPb1y7qk6ITAtrCkJzNrsRAF
MhSpYOGohe9XCjFIwNCFLVZkFcmbsG9CRKsopHWq9/7T7V2vL/+q6xv+/fHy
3z5dfbx8Tb9v356/e9f8CCNu3958eof3kf/Vzry4ef/+8vq1TH5//jv8Q4fS
u/lwd3Vzff6uJ665exZsTi0wE7EaL0vjAQmzk8DniEVi2VPY+Pkz74+UwWcP
IW+Qze14ERKKF7bsi62QwASeYNPfRkBjWyORf+8lna57AoWnvAkueLdzcc+w
UGkG/75ZmqjXMX17suAvv3O26GEzV6TPFmxRxIS12Q+xHSEUwkYsCFUVkhdV
WgtIZCZP1Yue2GdwyMpMfgCJi136U+dRjo2NDByrF14n0pfgOiVusLP13LCX
YGXzYW+IooDpJDHLil0mgIjodgAVJBFziOow0SmPgZoj42ChVzqneDWoAHMD
ZhTMSW+pneuNvVps+vKQnDse1kV4zJDmV/C4RWe8hBzOwjBAXAmiKlJwpSTs
wrIhuPDbEHlhMxWiALIZMJyaMMZ0aCC7u8ZFk8Mjo2qquiRNnGy6WmyKlLV7
QKhSf/7Tf9Ju/vyn/+JTwJ/ELP0pi0MEW8QjxeRDgDp6eIgPHh5USXBUrISw
nZiWNuRJLi293ax6aoegdvQMNcRwiXaNaJ4w2m82Bnr+REUCW8HATr5p5zpN
M4+8jp1raU1McJNwFQi9cvGsj+Aa2Asb5HM9fyx6Oktb5I9CAJ7IevRQBTqU
YSM9pykVyymgvnOgdgrpVKy0CMAsK4MnTJj3dnegzhGa1ORn4c5BKxh1svtY
NUUwGnxWQ3ibh4G68N7bywTAgQlk5weCu4H4JRgyA2JbSEmFA1Ajg192BfDC
DGYD8JrrcmbYd3FEhiSGYiVR/JcUlmas+FybqChE8T6XF5+YOZwV6zSMYEi6
cOAl0p0S+U9ddoIW84AYr3KUgedWp/FE55r0lUog3tIgqEsopKc4mmDE4ndd
hHQzL8fRCYZTUgB7FtDz0mfM4VVjAGSVASZB5ynrvnq9NQ2o8U6Xok6T+jBn
gqQQ6pG6uBVDk8xmhT+sxloiHoGBgXFE1kUlJ0g1MCKR4EBChdrViGA3npJk
cKC1PZY8HwkUplqyAvwNADrigQpLUCNDK7N5I77YoU01bVOpt5IQqO14l70J
557wJc36C6AZWQNQ0q4G4zpHMIkMQaeEco9okLNlpTk6naq5BCzOLHVJ2+15
4fod9AhYvUbgPQFLRuTaUHuKMIZJ7z45sEqnRuUUt3Viuiw1R9n8io91pTl0
36oBCJ8MHZCRvGmLTqnXypQlOJWXFBg0FlKcEW+DfY+QdKId2IZ4lNay2UVW
VRKzee8mM2gLyLlB7NEmsM/Jd9AN8M/HWXDI2qbGCM3jRnWDVcTCAXLgFQfm
iN5AfQj1pCm5cTmwHjnD17K0uuG1ek2Vidikc2eL2NhqYhZqe/+E1UbkwrME
KzpjA0kTxJ82adWnj1ckIw6KqLiHoIgWhFWGp4Z14DUEEwgQAzEBYjdE1hMK
82Xf2xa1dcEfsOO1mcRE00uQA3Cfr1IRkWKyR2zOs2XrmHySPDFsxxcLxGel
mVGxCoES3AwHPpzQiO9IJdTHLlkb9cpmFKZQGRbZmUZIBJyoKwrfes7k054s
ThF84/8y2bp3zmTZQ15XWYoQOBL1e14hhHzqFvrExUKiemJpAiPKxtEj5JGd
Q2oIvKiMStLIraVQ07Fh/eA/O2EqwS1BLiogpnCXyW3RndeITeMpzHeRwlR1
hj0xwYjZn2JSQvae15Fe0AoSDoyM2aor+T0geaFqAB0Mw0qTtbIzMJ1H22oz
ULecT/OQrVdsBSF9svMifx8+w6pQsYP8XbTS5aZ1QE08x3k1p1CMQU4AdyjJ
VsSlI4nkYyL/iBUkJSqbilX39lWYyBy7lGDhXvZbMkZsu1/U+5+AJp98cCQs
dTOfVID8ZtBmgB4MGykvqEDTA8GfREtbhwOgQiCmkIzgCrkI68/U2xcOp5oj
rNZwWbpEGKB63zfbvoa6fB5/vzB0FcJ/9AiDkXgflptkUD4OEzAxnY7d1c5n
HJLnbFHfgVMqy7HLZGUNqUknPuOQmYTOYbrYJbIKuS0aDaG5fV+p4Td0UEHw
OjhFW5LatNvb4oaX91uSId4edpKWjHwbOV1xK+TbG+7+WtZ8ZuVLQ2ziphSk
vVIfStMUICSV8n6a7igQzA2ejnChcDjmq6BXPnQLJoSeBMt1ly2Mf4QtFIIW
F6ZxwZq5OPeGWBLbUFOh0rWw4ysl94VdF8gD65KCMApmsE0H47nQVMrvq6vz
63OmTv6OwtymRimrwIb72KTJC+ClSpIU4FLRsRAHsNuJcVwRKuvcdHzXRLYT
DDsZEk27FZb8gUpGYSi4lSPHsgP2kiq1fJ6iJzaQSw27crIGmoM+X+XlmvGG
6yXf1VTr5QN3S032m0tf2xqjm/tBHqMuzq+7aRhzW1AFjcpDGZtFTHY+U/AJ
vrcOcKZ9Jne71jPKH5ryDScRBUw87P+ypGAUlK29fwlTc1O0pkghxE4b2CPe
ZIT0xTr3Wnv42BcEx0SmLmqsioBWSgtNzcHPgHF7ZA+u0i97Q00VcNfEuFqF
AjX5wa7F3kvN0tDlbuKrvcHFqfd1XmXL3DSBUpM3URWTbUpg6DXjB97W6DJs
0e+8T+6gCifNgG/DZnYNg+7e7jbLbevSTbg5tCR6W6ZRghF+B0xReUrtSlaD
5f+pDUSzhv+bbsFcJfEo/S014b9bgv87loCGN+7wNwSKLcQmTYwBJoCZLJVa
qw9h/IGOfeTR9zEhcSGK1g/RV4lYu6I4rnW+1MjwZfXocLalHEEHaKmOFvyU
sBRhdkHZF0m2uUwj4UBDcquDAy6G/x3B/xu+7JWi8GQshhrijelPjryubm9O
j4f7zbUbRCVRrBQyddoGsFi1i7S1piAvsSXdu0nlTUqCnXBQjKwP1RL4Sn95
J9QC+WqzpASIUjBrXPELOgf4FnJpNCZXwi1fipuSOS3k0gh41KERAAR9tZNd
zI6qSbjZMA+akgPyJeGQ/JvKLmO5Xu7J/B4VIyW36KtJ3d6KbTnV3cWHn3E5
pKOXD5qqZOqGJ0bRDz/8gMlfX94pf0PDeffe/mCfC2sOojAyhbSXCtN8OTJW
z9ztUO06UFCj4VDd/CueXMhNTyx++7mpGEdnHdPo0uZjZKwPsZ6Zfzo4Hg6F
io+fxyrJLV1+fY/H4U5o7MtQhPOeL63Rw3150tbm6NlgNBjJc66p4dnve71v
+IGXKUbJgKa6QI+mwwNzNBpN4/3p4WF8ODwexWeTo6P47Oj0ZHq2n5wlh369
Tl2AJrbVHOpy+2MIoMJYif/G6ntW0h6SQQeglnrczSOIS36v/DgZ20Z8tFA6
TY+T6WgS70+OTXx4uD+K9XByGk+PpycnZyf6eJjKzh9Pp8NhAiE06Y7qqDDG
jI6GT96R06HpC9edt+Ns/JtKNtSjTsV4uB/vn9wND8YHx+PD0//ojusch3/4
mf/9pv9YVJ386meRVPWXC+jkaKcMuLD618mg85RtR4OZsBiV3whv0pmol9kg
KDD1nKUTiqb3wta9/vUaCp93yljy1C8INeBHQtnnZbM/Gp5BoQejw6NnQfRT
YGg3Wpb1uJOs/0U4OZ6mh/vHZhifno2G8eH+cBqfJSewrIcnZ8PhcHoyGp10
uSIJ0z5/TMm+JKTT52UDZ0aNhrsl9BMgLMit/3MJZvQ3LpgtQC3Mgjqs/yYw
NXhedl9nv/p/Cqijo+Hzzuz9c2L5yb1Z5AX0yKr3+EboRww6v9/jmMKv0x35
wM3KJt+r5tSebvMUpP3CT8Z1SHXHE2fRZ44UEUDemqTm9t4LKrCnvmvPRVG4
56eWOkqGzAPUMaOrG0p41nNT+OJu536hexOn3iMJTjJbuwiBry2dT5Fr5/vF
u/dkFODaEsEidbUzRV1Vmi7L6QpC2mS072HabicN92iO70MCs5SHY99UG/P3
XUXKpTFuFVSIRk08AcE0ouYgJ9eBeMoxNWW0T8Rxt9UL9aSJsr3ZansZHgfE
fLf1vqUhXz10b6vCa8T5nRHdmPqV+uj7n+giAa+RsCPfKPY0Xt2ERpSnry6L
xKbSnNzd11hNskKXG4xogPB4hDSi/ZKrGW6Ow+dLEhnrO/p9JYFukfKc6x6M
ydAQRnuhmyxjKG9V1GVGy/HJf7U/YmHu7r3h3hm1xQL3z7puhZ6C8E++b/Rj
SPavmsIoEmhK7qXFTEsDDFP94maoHlFTI3DLO10Gt7yfMJ0vsi9XeG8hhVL2
QKkw1KjcPGnUpli0L4DnxnoCte94o2x+pZNNqAFSaj9jxn3u4e/2m6KvCIeS
aa5qUEGI+/24ytCpDKumk9yLqJO+U3MaNTOqx83H6wwnLYdgvMj68i0Sd8sq
wnVpKf9zTcnn7t3tHiWTt311cw71HClTJZQ1Xz3ufX6MwWu4AIz74Bv20u09
jsWg0PnwZw8Yed7tIZdSRmN4WI3H6jeQOlmnV+pNqWdyb9hW039MC/x9HX+o
cyZVk1Y+ULKIgNMQDUj059GW2qxUCLe1hDVcPq5i3jGDIdjI4Hwn0sQJ7A/U
a2rG8DYvz6gfjOpNbQtuxSk7GQWaMCIzPcsSX4584V627w4G6g19yUFNDwUl
3/x24FN7pQ5pbgIUWjdXUxrJNotu9sfq7vLf73jU0cBfk3c1Mlgl/6UajK18
OzamM8Z7UT++Ikyk+jGtSy7b7dry9Y9/PYY9Xj7z3Zcgr6DimxfyBSOZxMzf
ru1dSJuRdw+5KZ9ZiLp5E6qV5iadScM2+QzNbSJWqffZvVHni7pInYGiXJbZ
vfptllMTxK9ravZWv4KuWHpMOviRMAIFC/9i05F8LOPq2UyaZqQYOoXHoxaA
gTovGFPvdXlPndMExLnmTno1QWjEtUAmJJ/lkTMAgJ0y2mX5hj3fBX2+EFr1
b8mq4PejRmTs67fk/P3HLrBkO/1x+50KNxuUhuukGvyuCYjFjOVyb8wyosaZ
rEj5uqvpk2z8abdJcIKdq9x6eFPFlcN1vg8nlsUO5ZuYLoxx+NzgEqyPL9n0
QCXRZAyySqzY3ORLRXl2HDr5ghlqm1pIL9/u8vcu1DWXjFtN9tA3vvqwrq82
tvbBj05Bvcq4h7a9ECP3xBXjPcxqH0O+0k263fkjLTtTnGTa+ThENe03PqKh
Qa2p2DqjRw1Tz+xrQTVtblDwfYVa8TeRBVHPs6nhj7O4OM2B7o8U+3ovFX/r
Rg6l8/FH+ynX3K5xrvK5Ajk4kRaXivkrrrZNSdH55Jum3Q+AqpJ5wGxdZEGh
X7++uY2lbB1t9TrSli+wN7vYFqwYYG5KopuPUJ3liwFSIvLShDTq/JSOEmow
lG6nUH1vo1moGLc5FdJTSl2fpGD4u150tGr7q+FO2L2gPm/2WTvDTO5i1t3I
Ya03tAh9t9lW3p8PUSkxIfXuNbz/g+9qC12N0e7J4SsLDw1MDRG33HpNzMb6
u48GLlEDF3/lspM0ix5qxAVn+h5Sy8HSV4d58/HWIX88ce7kZqfO6dNjLzNb
k8zIcwTgPCOAF7JQ1KH5sgOxBlJZFb5mpfuejbSpagn+XkhUsSYkRHyntKbs
aGJU84UC+HwHu0/P+9TowmzCoPEXyqaUD2YOh4fqBU4NJgPe4SU5fN202/FY
BBIiYzuhlpnI6yHAtdx8QaC0JZxR+NgvYytaL+PKxin3dv43vt/U18g+AAA=

-->

</rfc>