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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC1035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2181 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml">
<!ENTITY RFC2308 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2308.xml">
<!ENTITY RFC2317 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2317.xml">
<!ENTITY RFC3597 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3597.xml">
<!ENTITY RFC4033 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC4035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY RFC7719 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7719.xml">
]>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>

<rfc ipr="trust200902" docName="draft-woodworth-npn-00" category="std" updates="2308, 4033, 4034, 4035">

  <front>
    <title abbrev="NPN">Numeric Pattern Normalization (NPN)</title>

    <author initials="J." surname="Woodworth" fullname="John Woodworth">
      <organization>CenturyLink, Inc.</organization>
      <address>
        <postal>
          <street>4250 N Fairfax Dr</street>
          <city>Arlington</city>
          <code>VA 22203</code>
          <country>USA</country>
        </postal>
        <email>John.Woodworth@CenturyLink.com</email>
      </address>
    </author>
    <author initials="D." surname="Ballew" fullname="Dean Ballew">
      <organization>CenturyLink, Inc.</organization>
      <address>
        <postal>
          <street>2355 Dulles Corner Blvd, Ste 200 300</street>
          <city>Herndon</city>
          <code>VA 20171</code>
          <country>USA</country>
        </postal>
        <email>Dean.Ballew@CenturyLink.com</email>
      </address>
    </author>
    <author initials="S." surname="Bindinganaveli Raghavan" fullname="Shashwath Bindinganaveli Raghavan">
      <organization>Hughes Network Systems</organization>
      <address>
        <postal>
          <street>11717 Exploration Lane</street>
          <city>Germantown</city>
          <code>MD 20876</code>
          <country>USA</country>
        </postal>
        <email>shashwath.bindinganaveliraghavan@hughes.com</email>
      </address>
    </author>
    <author initials="D.C." surname="Lawrence" fullname="David C Lawrence">
      <organization>Oracle</organization>
      <address>
        <email>tale@dd.org</email>
      </address>
    </author>

    <date year="2019" month="July"/>

    <area>Internet</area>
    <workgroup>DNSOP Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>The Numeric Pattern Normalization (NPN) resource record provides
pre-processing information to reduce the number of possible variants
which can be generated by pattern-based RR's into a single signable
record.</t>



    </abstract>


    <note title="Ed note">


<t>Text inside square brackets ([]) is additional background
information, answers to frequently asked questions, general musings,
etc.  They will be removed before publication.  This document is being
collaborated on in GitHub at
&lt;https://github.com/ioneyez/npn&gt;.  The most recent
version of the document, open issues, etc should all be available
here.  The authors gratefully accept pull requests.</t>


    </note>


  </front>

  <middle>


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

<t>The Numeric Pattern Normalization (NPN) resource record provides
methods to generate DNSSEC signatures for pattern-based "synthesized"
RR's, and validation of such signatures.  It does this by introducing
a pre-processing step of pattern substitution into both the signing
and validating processes.</t>

<section anchor="background-and-terminology" title="Background and Terminology">

<t>The reader is assumed to be familiar with the basic DNS and DNSSEC
concepts described in <xref target="RFC1034"/>, <xref target="RFC1035"/>, <xref target="RFC4033"/>,
<xref target="RFC4034"/>, and <xref target="RFC4035"/>; subsequent RFCs that update them in
<xref target="RFC2181"/> and <xref target="RFC2308"/>; and DNS terms in <xref target="RFC7719"/>.</t>

<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>
<section anchor="the-npn-resource-record" title="The NPN Resource Record">

<t>The Numeric Pattern Normalization (NPN) resource record provides
pre-processing information to reduce the number of possible variants
that can be generated by a pattern-based RR into one signable record.
By identifying parts of the dynamic resource record which should be
ignored or represented as a static value, one exemplar record and
signature is used to validate all other records that match the
pattern.</t>

<t>For example, a pattern replacement like pool-A-${1}-${2}.example.com
that generates PTR records for pool-A-0-0.example.com through
pool-A-255-255.example.com would have an NPN record that signals a
validating resolver to verify all pool-A-#-#.example.com names against
a record for pool-A-9-9.example.com.</t>

<t>Though it is conceivable that forged records could be validated as
legitimate, such forged records must meet strict criteria and match
patterns which define and are considered legitimate.  The added measure
is a notable improvement in security over being hosted in insecure zones.</t>

<t>The Type value for the NPN RR type is TBD.</t>

<t>The NPN RR is class independent and has no special TTL requirements.</t>

<section anchor="npn-rdata-wire-format" title="NPN RDATA Wire Format">

<t>The RDATA for an NPN RR consists of a 2 octet Match Type field, a 1
octet Flags field, a 1 octet Owner Ignore field, a 1 octet Left Ignore
field and a 1 octet Right Ignore field.</t>

<figure><artwork><![CDATA[
                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Match Type          |     Flags     |  Owner Ignore |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Left Ignore  |  Right Ignore |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>Match Type indicates the type of the RRset with which this record is
associated.</t>

<t>Flags defines additional processing parameters for data normalization.
This document defines only the Period-As-Number flag "." (position 5),
the Hyphen-As-Number "-" (position 6) and the hexadecimal flag "X"
(position 7).  All other flags are reserved for future use.</t>

<figure><artwork><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reserved |.|-|X|
+-+-+-+-+-+-+-+-+

Bits 0-4: Reserved for future

Bit    5: Period As Number (.) Flag
   If 0, periods are treated as non-digits.
   If 1, periods will be processed as digits.

Bit    6: Hyphen As Number (-) Flag
   If 0, hyphens are treated as non-digits.
   If 1, hyphens will be processed as digits.

Bit    7: Hexadecimal (X) Flag
   If 0, numeric digits include only 0-9.
   If 1, numeric digits include a-f in addition to 0-9.
]]></artwork></figure>

<t>Owner Ignore defines the number of octets in the owner name, as
counted from the left, which MUST be ignored by the normalization
process.  This field offers additional security to pattern based
signatures which may not be immediately apparent.  By restricting the
leftmost characters defined by this value, ultimately the length of
the generated portion of the accompanying synthesized RR will be confined
accordingly.</t>

<t>Left Ignore defines the number of octets of the generated RDATA, as
counted from the left, which MUST be ignored by the normalization
process.</t>

<t>Right Ignore defines the number of octets of the generated RDATA, as
counted from the right, which MUST be ignored by the normalization
process.</t>

</section>
<section anchor="the-npn-rr-presentation-format" title="The NPN RR Presentation Format">

<t>Match Type is represented as an RR type mnemonic or with <xref target="RFC3597"/>'s
generic TYPE mechanism.</t>

<t>Flags is a string of characters indicating the status of each bit as
per the following table.  The characters can appear in any order.</t>

<figure><artwork><![CDATA[
+------------------+-----------+-----------+
|       Flag       |   Unset   |    Set    |
+------------------+-----------+-----------+
| Period As Number |           |     .     |
+------------------+-----------+-----------+
| Hyphen As Number |           |     -     |
+------------------+-----------+-----------+
|   Hexadecimal    |     9     |     f     |
+------------------+-----------+-----------+
]]></artwork></figure>

<t>Owner Ignore, Left Ignore, and Right Ignore are displayed as unsigned
decimal integers, ranging from 0 through 255.</t>

</section>
<section anchor="use-and-normalization-processing-of-npn-rrs" title="Use and Normalization Processing of NPN RRs">

<t>This document provides a minor yet significant modification to DNSSEC
regarding how RRsets will be signed or verified.  Specifically the
Signature Field of <xref target="RFC4034"/>, Section 3.1.8.  Prior to processing into
canonical form, signed zones may contain associated RRs where; owner,
class and type of a non NPN RR directly corresponds with an NPN RR
matching owner, class and Match Type.  If this condition exists the
NPN RR's RDATA defines details for processing the associated RDATA
into a "Normalized" format.  Normalized data is based on pre-canonical
formatting and zero padded for "A" and "AAAA" RR types for acceptable
precision during the process.  This concept will become clearer in the
NPN pseudocode and examples provided in the sections to follow.</t>

<t>The rules for this transformation are simple:</t>

<t><list style="symbols">
  <t>For RR's Owner field, characters from the beginning to the index of
the Owner Ignore value or the final string of characters belonging to
the zone's ORIGIN MUST NOT be modified by this algorithm.  This value
is intended to provide additional limitations on the query portion
further minimizing the risk of spoofed RR's matching NPN-based signatures.</t>
  <t>For RR's RDATA field, character from beginning to the index of Left
Ignore value or characters with index of Right Ignore value to the end
MUST NOT be modified by this algorithm.</t>
  <t>In the remaining portion of both Owner and RDATA strings of numeric
data, defined as character "0" through "f" or "0" through "9"
depending on whether or not the Hexadecimal flag is set or not, MUST
be consolidated to a single character and set to the highest value
defined by the Hexadecimal flag.  Examples may be found in the
following section.  If period-as-number or hyphen-as-number flags are
set whichever are used ("." or "-") would be treated as part of the
number and consolidated where appropriate.</t>
</list></t>

<t>Once the normalization has been performed the signature will continue
processing into canonical form using the normalized RRs in the place
of original ones.</t>

<t>If multiple NPN RR's resolve to the same owner and type, it MUST be
assumed either multiple overlapping pattern-based generation RR's
coexist for the same owner.  In this scenario, the validation
algorithm SHOULD be attempted against all NPN RR's until a successful
validation is found or no NPN's for this owner and type remain.  While
multiple overlapping pattern-based generation SHOULD be discouraged,
future pattern-based RR's may necessitate this condition so it must
be accounted for.</t>

<t>NPN RRs MAY be included in the "Additional" section to provide a hint
of the NPN processing required for the verification path.</t>

<t>It is important to note, properly sizing the Ignore fields is critical
to minimizing the risk of spoofed signatures.  Never intentionally set
all Ignore values to zero in order to make validation easier as it
places the validity of zone data at risk. Only accompany RRs which are
pattern derived (such as BULK) with NPN records as doing so may
unnecessarily reduce the confidence level of generated signatures.</t>

<section anchor="pseudocode-for-npn-normalization-processing" title="Pseudocode for NPN Normalization Processing">

<t>This section provides a simple demonstration of process flow for NPN
rdata normalization and DNSSEC signatures.</t>

<t>The pseudocode provided below assumes all associated RRs are valid
members of a DNSSEC-compatible RRset, including pattern-generated ones.</t>

<figure><artwork><![CDATA[
   for rr in rrset
       if (has_NPN<rr.owner, rr.class, rr.type>)
           rr.rdata_normal = NPN_normalize<rr.rdata>
           add_to_sigrrset<NPN.owner, rr.class, rr.type,
               rr.rdata_normal>
           next
       else
           add_to_sigrrset<rr.owner, rr.class, rr.type, rr.rdata>
           next

   process_canonical_form<sigrrset>

   dnssec_sign<sigrrset>
]]></artwork></figure>

<t>Similar logic MUST be used for determining DNSSEC validity of RRsets
in validating nameservers for signatures generated based on NPN
normalization.</t>

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

<t>The NPN RR is intended to be used only with the offline-signing of
pattern-based RR's where there is an expected minimal security
impact.  Use of NPN RR's for other purposes is strongly discouraged
and falls outside the scope of this document.</t>

<section anchor="normalized-npn-based-signatures" title="Normalized (NPN-Based) Signatures">

<t>This solution provides a flexible solution as nameservers without
on-the-fly signing capabilities can still support signatures
for pattern-based records.  The down side to this solution is it
requires NPN resolver support for validation.</t>

<t>It has been pointed out that due to this limitation, creation of
DNSSEC-signed pattern-based RRs requiring NPN support SHOULD be
formally discouraged until such time a respectable percentage (&gt;80%) of
validating resolvers in-the-wild possess NPN processing capabilities.
Until that time, on-the-fly signing and unsigned records offer the
intended capabilities for pattern-based RR's, while requiring zero
new features to support their resolution.  Given enough time, enough
nameservers will be patched and upgraded for unrelated reasons and
by means of simple attrition can supply a level of inertia and
eventually widespread adoption can be assumed.</t>

</section>
</section>
<section anchor="privacy-considerations" title="Privacy Considerations">

<t>NPN records do not introduce any new privacy concerns to DNS data.</t>

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

<t>IANA is requested to assign numbers for the NPN DNS resource record
type identified in this document.</t>

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

<t>This document was created as an extension to the DNS
infrastructure. As such, many people over the years have contributed
to its creation and the authors are appreciative to each of them even
if not thanked or identified individually.</t>

<t>A special thanks is extended for the kindness, wisdom and technical
advice of Robert Whelton (CenturyLink, Inc.) and Gary O'Brien
(Secure64).</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC1034;
&RFC1035;
&RFC2119;
&RFC2181;
&RFC2308;
&RFC2317;
&RFC3597;
&RFC4033;
&RFC4034;
&RFC4035;


    </references>

    <references title='Informative References'>

&RFC7719;


    </references>


<section anchor="npn-examples" title="NPN Examples">

<section anchor="example-1" title="EXAMPLE 1">

<figure><artwork><![CDATA[
2.10.in-addr.arpa. 86400 IN BULK PTR (
                                 [0-255].[0-10].2.10.in-addr.arpa.
                                 pool-A-${1}-${2}.example.com.
                            )
2.10.in-addr.arpa. 86400 IN NPN  PTR 9 0 7 13
]]></artwork></figure>

<t>For the BULK RR used in this example, a query for the PTR of address
10.2.3.44 would match the for the query name 44.3.2.10.in-addr.arpa,
resulting in the generation of a PTR to pool-A-3-44.example.com as
the response.</t>

<t>By protecting the "Ignore" characters from the generated RR's RDATA
the focus for normalization becomes "3-44" as illustrated below.</t>

<figure><artwork><![CDATA[
  0 1 2 3 4 5 6 7
                v---------
    p o o l - A - 3 - 4 4 . e x a m p l e . c o m .
                 ---------^
                          1 1 1 1                  
                          3 2 1 0 9 8 7 6 5 4 3 2 1 0
]]></artwork></figure>

<t>Everything to the left of "3-44" will remain intact, as will
everything to its right.  The remaining characters will be processed
for digits between 0 and 9 as indicated by the NPN record's
hexadecimal flag 9, and each run of digits replaced by the single character
"9".  The final Normalized RDATA for *.2.10.in-addr.arpa would
therefore become pool-A-9-9.example.com., and its signature would be
based on this value to cover all possible permutations of the
pool-A-${1}-${2}.example.com replacement pattern.</t>

<t>Since the validating nameserver would use the identical
NPN record for processing and comparison, all RRs generated by the
BULK record can now be verified with a single signature.</t>

</section>
<section anchor="example-2" title="EXAMPLE 2">

<t>This example contains a classless IPv4 delegation on the /22 CIDR
boundary as defined by <xref target="RFC2317"/>.  The network for this example is
"10.2.0/22" delegated to a nameserver "ns1.sub.example.com.".  RRs for
this example are defined as:</t>

<figure><artwork><![CDATA[
$ORIGIN 2.10.in-addr.arpa.
0-3 86400 IN      NS    ns1.sub.example.com.
    86400 IN BULK CNAME [0-255].[0-3] ${*|.}.0-3
    86400 IN NPN  CNAME 9 0 0 23
]]></artwork></figure>

<t>For this example, a query of "10.2.2.65" would enter the nameserver as
"65.2.2.10.in-addr.arpa." and a "CNAME" RR with the RDATA of
"65.2.0-3.2.10.in-addr.arpa." would be generated.</t>

<t>By protecting the "Ignore" characters from the generated RR's RDATA
the focus for normalization becomes "65.2" as illustrated below.</t>

<figure><artwork><![CDATA[
       0
       v---------
         6 5 . 2 . 0 - 3 . 2 . 1 0 . i n - a d d r . a r p a .
        ---------^
                 2 2 2 2 1 1 1 1 1 1 1 1 1 1                  
                 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
]]></artwork></figure>

<t>Everything to the left of "65.2" will remain intact as will everything
to its right.  The remaining characters will be processed for digits
from 0 through 9 as indicated by the NPN record's hexadecimal flag
"9", with each run replaced by the single character "9".  The final
normalized RDATA would therefore become 9.9.0-3.2.10.in-addr.arpa
and its signature would be based on this normalized RDATA field.
This new normalized string would be used as an RDATA for the
wildcard label of 2.10.in-addr.arpa now encompassing all
possible permutations of the ${*|.}.0-3.2.10.in-addr.arpa. pattern.</t>

<t>As in example 1, the validatating resolver would use the same NPN
record for comparison.</t>

</section>
<section anchor="example-3" title="EXAMPLE 3">

<t>This example provides reverse logic for example 1 by providing an IPv4
address record for a requested hostname.  For this example the query is
defined as an A record for pool-A-3-44.example.com, with an origin
of example.com.  RRs for this example are defined as:</t>

<figure><artwork><![CDATA[
example.com. 86400 IN BULK A (
                                   pool-A-[0-10]-[0-255]
                                   10.2.${*}
                                  )
example.com. 86400 IN NPN  A 9 0 8 0
]]></artwork></figure>

<t>By protecting the "Ignore" characters from the generated RR's RDATA
the focus for normalization becomes "003.044" as illustrated below.</t>

<figure><artwork><![CDATA[
                0 1 2 3 4 5 6 7 8
                                v--------------
                  0 1 0 . 0 0 2 . 0 0 3 . 0 4 4
                                 ---------------^
                                                0
]]></artwork></figure>

<t>This example illustrates a key point about NPN records; since they are
pre-canonical they MUST operate on a strict subset of WIRE formatted
data.  For A and AAAA records this means the "Ignore" fields are based
on zero padded data.  In this example our generated record MUST be
converted into "010.002.003.044" (shown above) prior to processing.
After processing, wire format would become "0x0A02032C" (shown in
hexadecimal).  This format would be too imprecise for normalization so
padded decimal is used.</t>

<t>Everything to the left of "003.044" will remain intact as will
everything to its right.  The remaining characters will be processed
for digits between 0 and 9 as indicated by the NPN record's
hexadecimal flag "9" and each run replaced by the single character
"9".  The final Normalized RDATA would therefore become 10.2.9.9 and
its signature would be based on this normalized RDATA field. This
new normalized A RR would be used as an RDATA for the wildcard
label of "*.example.com." now encompassing all possible permutations
of the 10.2.${*} pattern.</t>

</section>
<section anchor="example-4" title="EXAMPLE 4">

<t>This example provides similar logic for an IPv6 AAAA record.  For this
example the query is defined as an AAAA record for
pool-A-ff-aa.example.com with an origin of example.com..  RRs for this
example are defined as:</t>

<figure><artwork><![CDATA[
example.com. 86400 IN BULK AAAA (
                                   pool-A-[0-ffff]-[0-ffff]
                                   fc00::${1}:${2}
                                )
example.com. 86400 IN NPN  AAAA X 0 30 0
]]></artwork></figure>

<t>By protecting the "Ignore" characters from the generated RR's RDATA
the focus for normalization becomes "00ff:00aa" as illustrated below.</t>

<figure><artwork><![CDATA[
                      1 1 1 1 1 1 1 1 1 1 2 2
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    f c 0 0 : 0 0 0 0 : 0 0 0 0 : 0 0 0 0 : -/-/

  4 3 3 3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 2 2 1
  0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9
   /-/-/- . . . . . . . . . . . . . . . . . . . . . . . . -/-/-/
                          2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 4
                          1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
                                            v------------------
                     /-/- 0 0 0 0 : 0 0 0 0 : 0 0 f f : 0 0 a a
                                             -------------------^
                        2 1 1 1 1 1 1 1 1 1 1 
                        0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
]]></artwork></figure>

<t>This example reinforces the point on pre-canonical processing of NPN
records; they MUST operate on a strict subset of WIRE formatted
data. For A and AAAA records this means the "Ignore" fields are
based on zero padded data.  In this example our generated record MUST
be converted into "fc00:0000:0000:0000:0000:0000:00ff:00aa" (shown
above) prior to processing.  After processing, wire format would
become "0xFC000000000000000000000000FF00AA" (shown in
hexadecimal). This format is slightly misleading as it is truly only
16 bytes of WIRE data and would be too imprecise for normalization so
padded hexadecimal is used.</t>

<t>Everything to the left of "00ff:00aa" will remain intact as will
everything to its right.  The remaining characters will be processed
for numbers between "0" and "f" as indicated by the NPN record's
hexadecimal flag "X" and each run replaced by the single character
"f".  The final Normalized RDATA would therefore become "fc00::f:f"
and its signature would be based on this "normalized" RDATA
field. This new "normalized" "AAAA" RR would be used as an RDATA for
the wildcard label of *.example.com now encompassing all possible
permutations of the "fc00::${1}:${2}" pattern.</t>

</section>
</section>


  </back>

<!-- ##markdown-source:
H4sIAAQZLF0AA81cf3PcNpL9H58CNd6rWNmZMfXLtrS51I5tOdGeLesk+5Kt
dc6FIUENSxxyliAlT2LdZ7/XDYAEZ0ay7KT2blSRKRIEGo3ufq8bmIxGI1Fn
da4P5Ukz11UWy1NV17oq5ElZzVWe/arqrCzkw5PTky2hptNKX6Ht6YlIyrhQ
c7yYVCqtR9dlmVyXVT0bFYtiFEUiUTUe7kTbB6PoiRDZojqUddWYeieKDqId
oSqtDuVxQYPpWlxfHMoXJ+dvTuVPZXWZFRfyh6psFuLyums0ekFDiVjVh9LU
iWgWNIjBKLvR06Hci3Z3+fce/94XIi4T9HQoGzNSJs4yscgOhZQjWZcx/2uW
80qnxl5Dev5DqKaelRW3xH9SZgXG+NsYkrk58l07+7+Vs2LlQVlhyOe6qJtq
+SorLoeYQDzmRwYjaEi/t7MfyRP5UmVVqj7KFxU/jbN6eSgnVQ6h67Kw98oE
o/zXRO7s7ES77lZT1BVavjuf8A09V1luRRm3ovw1kGAcl3PRn86LsXym8lxf
B3N5oVUR3r3HRHZ29/fliwavGPm8xCJV8ll+lQzlea2x+JHchSl0c/sR65is
zSzafrJ958xIsLEV7DPTOse0soJWXRXqSueZPFMXM3WlimCe5zNlZteqnt3Z
lmf/Y3Mxw9ROdA2lXsrzpan13PRUsA3pn8ijj4u8rKyzvFKFDib9g4YnFXV5
Hc779QvM++mTx3fO23hBx9OeoJWT868zFm/j8j4fQ47rShexDpdYXWWJfN5/
xDN9U6k41+Hotcr1X5NkjMdCFBQO6uxKk1tUabwNN+su993lzvb2QXv5dNtf
wj3by+0n7nJ3/8Bfkud2l3vdJfoVWZGujP3kCY0iRqORVFMsg4prId7O9H1i
mKy0KZsq1riIyyqRi6qESrQRi0qP8EesjaHw0w6LN+sSrZMGL9UYpWjmU9h5
mcpFibbTXMsrVWVYYiOuZ1k8kzH8aKrlhYY/IEIlcrqUCyvTaKoMbpydfWMw
BDpWkoZDHya7KBQ6E1Yw9jOeY1HW+sNR8oH+xTz1x5rWGDJL888GYVROoYFL
XRv58P0/3v+yJTMjVZJkJLrK5RQPLxBLi0QEcxpKVZhrXRmaXFrpfzbwq3wp
lbmEePjLUCszdJPI5bwhOc1Q6DoeSwl1L+V1luc00UrPyyuapkb/Wi6aaZ7F
PAy3hDxAC6xNUZNsU42OEJvzXE1Lqx/oOCvkD1n9YzOVqhbvv5vV9cIcPnp0
kdWzZkoW/gjd6aX+9REA5v33VgQ5L01NK4muxRVmQ6uFhaFl8kMOZbnQ6N8Y
TGooIT78qmzyRCorPTwpy1nzM11p17HFACMvSMAUAQ6qiWO9qDE7vMYKM7UZ
WzOcZ0mC98UDwqqqhKnQ5P8Ao5xriJHwInlrIpg8P3pu7QWhEOEJWl+xr4FZ
FlCCyX7VyUCQtdGCJzDUPEvsyFCTaWCsXT+Y+nENvaHHmhYNVpu56dCKKbni
IoiFC3YDNzPTwBuzuuHu2binJYIsLQYNwn0EMqAH1xkNDeU9APh4W2Vp3yJy
ZkWZlxdLq0twhgSuRwaO5ZxjojSIlqmaZ3mmKlikGxBqgM6hKu7Iqgw2V9AS
why1iatsivdhdr/9dvbyOcWzm5th+8d++wcFJ/wh/B/cjDr1N9D0Lzx360QS
d0mBqpaWoJA8cwxke6C4eHPTdUDBkTpwYkpocm5asSjU3dyM7ewvyeVgHkYO
Xr87fzsY2n/lyRu+Pjv6z3fHZ0cv6Pr8x8mrV+2FbSHwx5t3r9xzuurefP7m
9eujkxf25deTvw/sFAdvTt8evzmZvBqQRGQUovVkijxW+xnxM9gGebLapFyC
BZ7FA/YtmLw88xZ/xhb//yV+87JtCt9qLYBbC0dMaiO39JH7GRwngY6ydMlW
rirYnA9LSyAx5rg6D4scLjJNtUCfiKUIjRVaYG4G/Vn9AjFqzCsmR2r0kEXQ
H/V8kavK94bFE61jk780xjqLcz7NwQ/eqf0rzmShsZg9SLj5YtVeQgb9UWEA
jNYqgsTKVazZGPLsEnG/LPPRZPSn37Zv8GvnZuxeYn7CvXuVGnn69qwdmMOX
fTcaReFbEATR4GIm3OOd/X36r9fkmjUGPoQ5FWxbTgc8Iishh9JEEHZI9zng
ghUCi0uXrA43yIPRg94AxJzQwYUC6taIgq77QOqD0UH4BrsriS0zBjwOO9kV
mwgLhVcvsBx+/rFb83ZxaJlFroF9GdYDSudAvfIWABnLBQpKTDSLYbZVhnXJ
FHsur6NfQ+OsK9FpVmh+Tt4LuYhGkJV1g3n8SxLcnmtlYECCAi7xEJ5CNief
s+sODzc6bjDyUpakUQZ3OQMsW/+Hzui5lr/CTI0LZG+XC22tl7VY+5hwJmt6
gtHePnvh2roHpMYcQR8dJhp4nnAIKmjhDSSTZqHjDDTl7dtXDM5ZxQLSiMAV
7uTF5O1E/oQH8iVHBtu/vU1iOOvBYKwYY31WyR1ZxjXU/Jpdg2VPM50n5Avb
wj57masLE9x2r7y5pozomF15/ekrndbuoeCHdmXa52fZxazuvY3Z/A8+zNLX
PtsbfnY2/OxK5JERP9yVe3JfPpZP5FN58CX3xJ9Hv/NHfApED1Tbfuxzq1j3
d0+dn/4YGYJF4DF6Sr/HGHZBRDADStViDnJk2GzRLvafnRksK3MU65BMs1w8
AbbCvktYMVyHoi7P3Lpsj9AHIAdkQXCqicaTBSN2kJsGoDkWffrtuysLEFoS
6RQRo0xGEzM6sbCYYlg5GA/kQ6AjDyn3t4aC2v64XMx0EbQdjMJmj7fYfqnl
DNEwgUNCENfhzwPRtXyyhSgzaQEo5ZlSRCKYqyiToNmkDYMXkKs1+xVrXF8d
8enMd/Fp/Gn06ecNKyjEswy+HY32DuXZ+oD8mAxu/9BpR06MdDN+ON5ikyQP
PE5lNJQLbmLFr8FPHUgXZTFKMgRVM3Ztt7u2Pm/y9NfSJtfaD//40Ck8HH60
OvyMm9xveN/2XsM/oWpNt4oPf14duXBkzb4Iq4/zBjkpW1YEQOzGvaWlGqWE
EN6yCYz5PetQPV/3ZtunbxwljWWmGJhfILAeEnxyTYUWtmIaoQFxKXJB63dM
m4m5OpI1tc7Qcx3h1ONTWBuhyzQlbwvcscU/yO+pEXNEEWRodti5WhKK8shz
ZC/k6pRYLuDH8E6MBOaI5ozn5N/Ew0huTnPjmaJSBw1v9eHkhmyOCTa5xXDn
27kuLhBqypS9t6Ozi7Kqg0QZeW05X6iCuWqQNxISelMBIvKIghpXVIrKl7CV
MHjeuUZuqE4Ght0/eKGE6AXvP0yginr9SokeBCnPmTy1PN5mJZ6FhNBh1sh+
0dKieaHnZQE/Kl2ey7kVldFubr4xgqeCp2//fnoE4gZrKTIzb4Eks4lDRYuM
yQfG5PDK2RsnFw0rSCvINUU4gFIW2vK0tMzz8prbEhl0bDHojZInGLRGLkLO
XYAXVuCYPoT/ebT2+fNt1y1FoBkErOBdQTDqGMI5XzJSf1HPa6E95CP2eiy/
que1qL3e8+jrepa9kNz2dhD0nH5Nz+sRdxjyIlsL6PkWwU2SGSSAS2unTUHR
DgHCS0dFgQsYxFBWqrggg2F/inxKJymPY/94Z2xK0s/2TzuWA1O0/mPECp3x
yT9MmwpFlVxqm/JlKUwaDeZlwpceYFwhqNIXiqMYMpVrS8s6WLQTIS/j3DAD
G4OZUX5BPeU2uIrzNrt+6YBB9ipE55prgHJ3vD1+ig5OYW6ccPZqFHUpICd5
NTElKGDoh+d8iREDsbdW5EstOySJEY6Quf3Fwt5Q2OSI+ZcjnMQE24wmQdoT
U30X0RvhZVEWTEMQRNqsR3DKyPrmLmXXZRehxozpjDkQywG3/sjJEmnFdvWN
cWmVD8GJxgxyl+l382f0CWZF7whXFR94c9DJQNpSDgbvblqyS1VKrsdADCoA
tcoU9hWOajSFX3VF8MxZLUkxmAxshWuCz8DHWCuhLfRyRRh9xhlXlZOm8iKv
EANXVfT2AzBFQMwRAHXluAmrZWF0A8MtE2vtrl5gvA0nnscYazi2MM/R1mXC
VZM7AVn/NfzKdDUu8kiTUZeHQnxL4GIXwnq1yz2DON2i2xSpf1Hw3Eq+QRn2
R88aejTMpuwuY8fKEvvZhChTnZfW52Hf1JaMmWQ5O/7h+ET6oiU5m3XQgMqo
/KIEnZrNvXp5UKpAUEQpElvGckoLeViezTOLrJTesIj/bHS19HRHpE3F6QYi
BZr+6lezyswlF8MXZZn6rZnWF7ByruIX1Ml7CnYFhBUFW/3eqlsOr2JVrYEK
2Tfb1r3Ya5u7DqERcU99ktTHVjEVbfGxXAEX5GK9XW+O9zwvu75MBxyNp519
NWwpKGJ/N+lBNGjj+yAd0Jx6tw4GwlZv2GYKimG8JGhHvJiTzNXUEXMguLdN
hmw8wjJSU/pyWbiP1klDs6BXnapmGW2W1s6gehR6fVhY35H3UArCtMnA+xLO
ozse5PzVRkab4Y2UGXnGWbm0K7jX5ruCywFEKzXVzpTNdhP5kPLvkvPrLVff
nPbSO6ooOworXKc02Z5OGB+IilXloqIACwN4U/gaeA9rqYY21eAsEJ8iik7a
TRsLcRzaCIeyotFiBcFkH8Fk08b2oovWhFguwHHVWBAVB7HmIOJKg9DfnFIY
KF22QOJqtX4RDfI7l+p5sBtSmdXRcuH3hXRmfd33R8XJHMqwVZOwku9SANID
DQj6z3jWVia7EWmJ7S6INLEuFJZ6yE26XTXRupt0Wyy0wYjh5gteOltE5mpz
O0NkG1lO9tvEpNa0yUWwTUeZJxseOwC99U0AAn1NOL+GnD/NMqDXl82+ExjM
DklQpS50MhSuDLNh/5rTWc2mUNt9rh4tMCUtDJWpyV8pcXR5VUnZgGN08vXk
73YPiYsCLQoOJm1kH3gX6wV+uHNRC5fGMb52VukKwEm7hpbIORq4oAMVsDau
zQMxEQGJKqJz2mEfUkfwA3Al04FEWITlXIqK7cwz8NpnAKW3wXrCns5QZmdH
4+hakEWE8Z3hn0kLFMIZFN2Yq8vQ2pChmYzWHyLVgv3KdAbJNfmUsdeSJVWz
bGP5prDb2Tbtd2ySkluKSb6GgSEzqow95M0HDPHs3av/2LLA1O2yGK4dlRwI
Sb6laAprE3CPfBnuu3ENIaFTJ0jxr3ROwnX5dw9eHyAtOO34Ei0jDXlbhuDS
Am8mQVZgGRHmgsyZTop4rHPGglAM/u+6F9V6/TTYPe5LSIQsYHQtiSPqc+12
pw37+QptV5VbHjHXFLjdJoMdY8RLUvOeJGclQ+cYoeN2OnNx028J0Dwq5pxV
RTblUs4slQ8R4T9git9V1dixe1wxwecrCh7fb4XbCrjJ6vhg1SH/nTT0oQ3o
3/nn34cvgY19qMsPUBQL8B1euXW44eomxsqIvY4L/bGdjs6NvmvQO6Y4lBvF
5t7phrOKDy2gfSBA+853/T03SgoDQ6PxiuCJTaHPEQdoFzYvL7K4LRUxpnN9
nkr1c0u8nFGFnmrzUCRA4REJ3n2kGrWr8QdFxWCD2udAZMYrGwDiAeWitkT5
3O34WZq8usEWEmwvNpdz21MVZZrmYE0jd5yDkoQNuGCZR82/My5h6Y9In0lQ
DpVB0VTAP0HWEBipCtAm+g7i7PbAoqkWpdEcduHDJdUeQ4jiQyUpXA2u1NR8
MIpxOy79zktQMnD7gR0xoVMFo2ck/JZsc3pfaAD1aFZDSpqDH5CDtg+p3h6s
EmkLgoiyGEGOUcpIYvUVq4WaZjmgQ9tKmamJWZlmQSgUrK1YP9Lj4q2ruCWw
cWnnWjpK4sXJGA0cBhoXq92Gtx+Juu9wxKJhxwLLjIEak7D71UnTDdOlWch2
iJHaiCpcAHPVi1WrMA6TXUrVytFyDpuv5/2VddSIAajO5oT6VLyAKfFGNFCa
Dn6hpXz4/dPo37ZIjg3b/GTZvBSgsQkf+qDQv8IZwqUZi3c8ME+eBqZDFmuL
SWbny14tGvL+APPy1pt6i76+rvZw1jURtkBJBP2i0AAn7bwdC+C1hu6zyk6v
cbnHD8Bq+FnBeZYV2f4h+qbpdn4ovdV2v7lZXFTKl0WaotI5hxQsraFUmk6S
IEeaa1UwVDlExRQqS/PYjCEYUYoO2BElkFjyWQSBe0Xd8OJekxMt6BgX4na5
aDuYan+iiwPWKaiHitfjVcg7EuZr7Qk1zbVm0tjCvcx1mcoWUuhkFcV97v14
cjJZ65pvZsaf7HNJpaHldbsHpndYgXpcOcMj7OkFe/In81x2JfjISXxZlNe5
Ti74gMJqSfOaEuou0+PgCUMyjv/S8BiajnJWCtGwick6xlRtJjcZgoJBDQtd
etrPbyy1gvh8RoayuCqbNuifuCttyLVu7Ldv/eFH5RJIOlpB529JAN4UsLR7
LmllBfiFTd5VcWnrpj0VJBkiJ68+pj9pD2pwc47pPL8kYOuXeAnMhrwiM0k5
t3LpeGYreyq5ymKO7GcllqVGsqPzmg6IrZ1VtzvSP6hqKd9886zKIO1DBkP9
eG/Lnd2k87G0LrSoPuVnkDj6efL69NWR3HYMa2e8HY0RSUA4qrGqFmosnz7e
iyJ5fMLcmM80Pdx8NiP8/COiM0y/jPHvdvTLeL3bz3dx10mru1/funMapAOe
Bh3yeCK3dx2veelWhqcJssDUwFt3cDTMFtz8OlJHRG4xEFZTYNid8e54b8+V
NNqjZu0L9nUKWHJvD03XRB0C1gwltVx6CHfwHK9XPCjliVZDuyN0FB7mUkbY
AhjVwPlkwbMlwUCt2x1XObCJ2GBjuTTYMWyrf8JOIm5siOhnELYibOSAZBlw
rpbnDScjPl/oOPzqAYfV5btqd2340UKW+MnlSE7w3y7+28PPWGr5kbZE8DzH
9VjGaDWXGyyj7e6/77Aaf5ho7XPHO7uYxjamcyCfwpAeYzp7/p6zqSMEp2U9
C4qjtPFLi+g0xWBlKxoU5bEQtD3LtwlSgpcpiPEmrSNHXXmzV1FdOfXAHMud
SZjq+pqoT8QB44BXyR3jaUuEHfh8Y8TaCZcDu0vG4bFq2Bhd3+6cZNvPap1S
DA4GTnBbUw/YaXc67dt1b7B+JJho88F7t/lwy6lEKyBJFBT2/HHTNoPozhOQ
ZmOGEHs40p2VBeuaN22h3dYg74pHvXOi3aHS88zXIjcmO04yBBpbN2dEoegf
HPBc2U2yFVDkE1Vm+AsOkJqYZ+8cL0nLUcz1QeQDcMynL91un9sX630vg0G2
hwo7DrjdTP0uHWUInHTmxDGPT6/2kPXl+sJFKBuzHu3syOfHL87ElCp7hE6q
d6bDHQzffnJz4wyjcF9Aagt/ftjMiAEH1gidDvxYviQe6HNQmO2xaaY9kyC7
IxWhW9HrVrXnJ4iFHLr49Ce3gbMBsqLRbgcj/AE/wmfTqBw2+tD5/GTy+ihE
xt1f5J9++/bT+GaM6/4LDFL2BYKpSO70YWoTJFFUYTXtjB/vD5xx0SELCzyB
ngAQg8f73HJ1kgN3PnPAgw/s+RiXGVtHRf5hX4bQGztoi/mtUf4rEYhE+xwC
8SfyFyt4wx8K5mOE8jFUT6BjrynYj2UmC9xTMsFPhb+RsAGEVAA9dyGOP6G6
6STrPcDnDsz5Ohyy+lrHIQ9DsoMh8dUwJDsYEitHJD6PQ2snLQlMhtYsWyj6
HADJFQASxSoAWbNdA5qD8cFmSxe3I43sI83aUO6cM8dWyuaCBm6vue2pMd0Z
qRYnKcBTnh8rRPdcTW06uo6dFPR1wXjh4AO04i6QQzx67wPSBt8OoG3CW10+
lG739ohWvoDQRzneauJKdAdwHaL18Wd3BX/aClVFRokObQ0y7b67AZufLl07
i5eMT8Lx8xBVVZAG01l+io+wkNX4GpB2+mZQtyOMricbviexysaH7REUuxVI
2zkhULTgJO8BTr0X++gyuU9a1mZVNi8bOTC6z4uMLICrm3s03rpFUEa1CSPa
0zY2/cuQIYp2x9Hn05P+Z+27AZ+dfgcnK5jS6zNiaIkcxEQMMRFlNp9X78qR
t7uyms0fr/meb3UaIXpHX8PjEqlUUyqRBkWpv1BstbR2aTfTwjNJ9jbvCtAO
I22ZUtHFf3+Hv0LIwPPT8dmRO/NEZRouXFnvmzAFoTNLwde2IKktz/UMxO1V
8heE+TgyxgpPQblej/tZvCybKrAj58N+dx0kF8HFfrUHgDeIYPlRBLrjzeeh
mVFhGoq50ltUiVs98zYWk5Qgp7tDQaDSbrptcGd8GUQfo0m0E+3uPG+7RpQI
MG+rPZ3dfx2DlvxFJTq+pTdYvimF14M/sGi/JDe+kxG0E72dFPw/zE2B7/3k
9PenpLcwAo6EoAVc9/09BIBXVawQgAlT7s/Bv/TwL1r4H7z/tp/3bIT/zTmu
P2Pggvz7b28CqA8Aee82QDa9TUH3TTMg7+PQjwN0FZvQVa6ga/cmJ28OutJ0
pFT/25E9gJUrALuCsOLrEZbk+UKQTfH5pb24z7tpHEWHh1RlOKQqw2dfuRtr
SeSfCV6i/wu8TdPDKFLqyxDXfm75ot96+fDOb/Bx56mMGWIP+fftV6NHo0f0
BiVP6z+bvmW4zeLcMxWTByTNIxplBLD/sh9+69EdxrDxK5BrP3exi3tq9YvY
xgoXuoUPObXcujwpfuyVkurL2M76+Hfwpc1J+a3NvzQJ70XOSvOX9/1hJsu1
Vg94h5U/e25AtCTsd/Gsr6ZZXQ3199Asd7a1R7M47kXRrb/aWGI5kriDfiHu
fZ5/iY5/vXwe3fJ5+TKK6Oj8bbwspGV0PCEnEpQv5TwzuVY2AzXuG/J11eAJ
nTUR249BSoho+/WxR9ewHF/B7UImdE9+1+ryX8Hw/Mayp3h0WJq/lZAOvobm
/fzFNC/9OppnLfIwPUwH9y/1DDomN3BYGXA9Lvb0mnRfzbiT8omQ8nUVn2/7
/w+Hu+ie2FTtGayQjUHA+sT/AihtAy84TwAA

-->

</rfc>

